[aerogear-dev] Pipes on Android

Thu Feb 14 09:04:34 EST 2013

Ah,

in that case... I think.... just document, how a "real" cancel is done
(e.g. using jQuery), instead of blowing up your current work.

-M

On Thu, Feb 14, 2013 at 2:46 PM, Kris Borchers <kris at redhat.com> wrote:
>
> On Feb 14, 2013, at 7:38 AM, Matthias Wessendorf <matzew at apache.org> wrote:
>
> On Thu, Feb 14, 2013 at 2:27 PM, Kris Borchers <kris at redhat.com> wrote:
>
>
> On Feb 14, 2013, at 2:37 AM, Christos Vasilakis <cvasilak at gmail.com> wrote:
>
> Hi,
>
> as a follow up to my previous email, I want just to pinpoint that the issue
> that exists in Android where the Activity is killed during (e.g orientation
> changes of the device) doesn't exist in the iOS land. That is,  there is no
> need to reattach our view (and callback) to the running pending request.
>
> In cases where a request is pending, and the application goes in the
> background (e.g. by clicking the home button), the View is not killed, when
> the data arrives the view is updated normally (even if it's not in the
> foreground).
>
> In the case where the system decides to kill us immediately after clicking
> the home button, we can't do much, clicking the application again will
> restart the app altogether
>
>
> I believe JS is similar though I'm not sure about actually continuing to
> update the view (I don't think it does) but if the browser is killed, there
> is not much we can do.
>
>
> having a cancel on the pipe 'interface' does hurt, right ?
> Think Cordova, once the WebView goes away, there is a hook, and you
> could cancel that request(s). Shouldn't be too hard to offer that
> wrapper (instead of leaving the user mixing our pipe and the
> jQuery.ajax API)
>
>
> Well, I'm just not quite sure how I would implement it. The Pipe has no idea
> of the state of a read or save or remove action. Once that method is called,
> everything is passed off to the Promise which is immediately returned by a
> call to one of those methods. Any cancel would have to happen on that object
> and not as a method on the Pipe which then it becomes to I call cancel or
> abort. See this gist for an example of what I'm talking about.
>
> https://gist.github.com/kborchers/040710a345941c0abcd4
>
>
> -M
>
>
>
> Thanks,
> Christos
>
>
> On Feb 14, 2013, at 9:31 AM, Christos Vasilakis <cvasilak at gmail.com> wrote:
>
> Hi Summers,
>
> +1 for option #1 using the loader api and support library
>
> As you suggest, android support library is commonly used nowadays, so won't
> have big impact targeting old versions of Android
>
> Thanks,
> Christos
>
> On Feb 14, 2013, at 12:47 AM, Summers Pittman <supittma at redhat.com> wrote:
>
> Currently, Pipes on Android are implemented using an AsyncTask and the
> callbacks are fired on the UI thread.  In the case where the Activity
> which made the request which launched the task is killed, an application
> using Aerogear will crash.  This is bad. Additionally the internal
> mechanisms of the request itself aren't easily reachable by the
> developer.  This means we can't get status information (is the request
> completed, is there data, cancel the request, etc) easily.
>
> Last week at the F2F I chatted up Matzew and a few other guys and put
> together a Pipe proposal (http://bit.ly/12MzeOx).  I've implemented it
> and ported some example code and it works.  However, it requires a lot
> of boilerplate code to manage the Activity life cycle correctly.  We can
> abstract the boilerplate if we write our own extensions to the base
> Android activity classes and our users extend those classes.  However
> there are about 12 common classes in multiple libraries which can be
> used and it is pain to maintain.
>
> In Android 3.0+ Google provides a Loader API which handles this
> boilerplate on its own.  Even better, they've extended their base
> classes for us.  After doing more research today, I've come to the
> conclusion that Pipe and friends can lean on Loader to do what we want
> with minimal if any API changes.  However, this means on Android 2.3 our
> users will have to include the Android support library.  This is usually
> used by most projects anyway, but it will be something to point out in
> the docs.
>
> So my questions to the list is, which should be done?
>
> In order of my preference:
> 1. Use the Loader API and require that users targeting older versions
> of Android include the support libs (which they are probably doing already)
> 2. Use the boilerplate heavy API proposal and pass the coding onto the
> user
> 3. Make our library 3.0+ only
> 4. Extend all the base classes and manage the boilerplate
>
> 3 & 4 aren't really good options, but I am including them for completeness.
>
> Summers
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf