Re: [aerogear-dev] Pipes on Android

I am +1 for option #1 with good docs pointing out the support lib requirement very clearly in docs

On Feb 13, 2013, at 4: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