Stores and Auth(was: Re: Pipes on Android)
by Matthias Wessendorf
Hi summers,
the issues around the Activity, are they valid for our auth offerings
(e.g. login + callback) and the store (+ its callbacks) ?
-M
On Wed, Feb 13, 2013 at 11:47 PM, Summers Pittman <supittma(a)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(a)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
11 years, 10 months
Pipes on Android
by Summers Pittman
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
11 years, 10 months
Removing Auth dependency from Pipeline
by Kris Borchers
In https://issues.jboss.org/browse/AEROGEAR-858, I propose a change to the APIs of both Pipeline and Auth when creating new pipes or auth modules. What this change does is change the dependency from Pipeline depending on Auth to only the Auth rest adapter depending on Pipeline. So what does this get us?
A narrower dependency between Auth and Pipeline
Removal of AeroGear.ajax and instead build directly on top of jQuery.ajax which in turn gives us a much smaller file size (important for JS)
I would appreciate other thoughts on this. There are some issues with my current PR (https://github.com/aerogear/aerogear-js/pull/21) but I think I have solutions so once I update that PR I would appreciate feedback on that as well.
Thanks!
11 years, 10 months
Re: [aerogear-dev] AngularJS/Backbone discussion
by Kris Borchers
On Feb 11, 2013, at 5:48 AM, Pete Muir <pmuir(a)redhat.com> wrote:
> Kris/Douglas,
>
> I also realised there might be another point of confusion in this discussion. I'm definitely not proposing a strategy that Aerogear needs to adopt (for you guys it's really important to be more JS framework neutral IMO), but for JBoss. So the answer to "What JS frameworks can I use with Aerogear?" is different to the one "I want to use JBoss to build a mobile app, how do I do it?".
Hmmm. I feel like that could be confusing to someone new who says, "I want to use JBoss and AeroGear to build a mobile app" and we tell them JBoss says go with framework "X" but AeroGear says use what ever you like. This is not an easy thing to sort out. :-)
>
> Pete
>
> PS not sure what your team (internal) list is, please add it to the cc :-)
11 years, 10 months
Pipes in the event of application interruption. AKA We're doing it wrong.
by Summers Pittman
What happens if a Pipe is running a call to the server (let's say a read) and the application is put in the background? (IE a phone call comes in).
On Android the answer is a big it depends on the application and there is nothing the developer can do about it. On iOS the answer seems to be the same. We need to fix the "there is nothing the developer can do about it".
My general proposal (I am working on a more specified one) is for Pipe to provide hooks into its running requests so the application can register itself as a listener.
In Android it will look like this (pseudocode)
https://gist.github.com/secondsun/a7a92eea911884071aea
Here the Pipe returns an identifier of the thread which is running. When you call read you pass in a listener which will handle the response. The Activity is responsible for managing the life cycle of the listener in relation to its own. If if the Activity is put in the background it should not listen for responses.
I don't like this approach as much because it is a LOT of boring boilerplate for the developer to add into her activity. However, we could provide utilities to manage this and perhaps some tooling to create other services we may or may not need.
Summers
11 years, 10 months
