On 02/14/2013 03:10 AM, Matthias Wessendorf wrote: > Hi summers, > > the issues around the Activity, are they valid for our auth offerings > (e.g. login + callback) and the store (+ its callbacks) ? AFAIK Stores don't use callbacks so they aren't an issue,

but the issues are also valid for auth.

> > -M > > On Wed, Feb 13, 2013 at 11:47 PM, Summers Pittman <supittma(a)redhat.com&gt; 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev