[aerogear-dev] Pipes on Android

Jay Balunas jbalunas at redhat.com
Wed Feb 13 18:20:46 EST 2013


On Feb 13, 2013, at 5:47 PM, Summers Pittman 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.

Not to mention that this is a hard sell to developers.  I.e. use our base classes not androids.

> 
> 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)

+1

>  2. Use the boilerplate heavy API proposal and pass the coding onto the 
> user

-1

>  3. Make our library 3.0+ only

-1

>  4. Extend all the base classes and manage the boilerplate

-10

> 
> 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




More information about the aerogear-dev mailing list