[aerogear-dev] Stores and Auth(was: Re: Pipes on Android)

[Matthias Wessendorf]

On Thu, Feb 14, 2013 at 6:05 PM, Summers Pittman <supittma at redhat.com> wrote:
> 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,

Ok - I think that's than still a "design" issue on iOS:

See AEROGEAR-918

> but the issues
> are also valid for auth.

yep ;-)

>>
>> -M
>>
>> On Wed, Feb 13, 2013 at 11:47 PM, 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



-- 
Matthias Wessendorf

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