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

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

Hi Summers, +1 for option #1 using the loader api and support library As you suggest, android support library is commonly used nowadays, so won't have big impact targeting old versions of Android Thanks, Christos On Feb 14, 2013, at 12:47 AM, 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

On Feb 14, 2013, at 2:37 AM, Christos Vasilakis <cvasilak(a)gmail.com&gt; wrote: > Hi, > > as a follow up to my previous email, I want just to pinpoint that the issue that exists in Android where the Activity is killed during (e.g orientation changes of the device) doesn't exist in the iOS land. That is, there is no need to reattach our view (and callback) to the running pending request. > > In cases where a request is pending, and the application goes in the background (e.g. by clicking the home button), the View is not killed, when the data arrives the view is updated normally (even if it's not in the foreground). > > In the case where the system decides to kill us immediately after clicking the home button, we can't do much, clicking the application again will restart the app altogether I believe JS is similar though I'm not sure about actually continuing to update the view (I don't think it does) but if the browser is killed, there is not much we can do.

> > Thanks, > Christos > > > On Feb 14, 2013, at 9:31 AM, Christos Vasilakis <cvasilak(a)gmail.com&gt; wrote: > >> Hi Summers, >> >> +1 for option #1 using the loader api and support library >> >> As you suggest, android support library is commonly used nowadays, so won't have big impact targeting old versions of Android >> >> Thanks, >> Christos >> >> On Feb 14, 2013, at 12:47 AM, 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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Feb 14, 2013, at 7:38 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: On Thu, Feb 14, 2013 at 2:27 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: On Feb 14, 2013, at 2:37 AM, Christos Vasilakis <cvasilak(a)gmail.com&gt; wrote: Hi, as a follow up to my previous email, I want just to pinpoint that the issue that exists in Android where the Activity is killed during (e.g orientation changes of the device) doesn't exist in the iOS land. That is, there is no need to reattach our view (and callback) to the running pending request. In cases where a request is pending, and the application goes in the background (e.g. by clicking the home button), the View is not killed, when the data arrives the view is updated normally (even if it's not in the foreground). In the case where the system decides to kill us immediately after clicking the home button, we can't do much, clicking the application again will restart the app altogether I believe JS is similar though I'm not sure about actually continuing to update the view (I don't think it does) but if the browser is killed, there is not much we can do. having a cancel on the pipe 'interface' does hurt, right ? Think Cordova, once the WebView goes away, there is a hook, and you could cancel that request(s). Shouldn't be too hard to offer that wrapper (instead of leaving the user mixing our pipe and the jQuery.ajax API) Well, I'm just not quite sure how I would implement it. The Pipe has no idea of the state of a read or save or remove action. Once that method is called, everything is passed off to the Promise which is immediately returned by a call to one of those methods. Any cancel would have to happen on that object and not as a method on the Pipe which then it becomes to I call cancel or abort. See this gist for an example of what I'm talking about. https://gist.github.com/kborchers/040710a345941c0abcd4 -M Thanks, Christos On Feb 14, 2013, at 9:31 AM, Christos Vasilakis <cvasilak(a)gmail.com&gt; wrote: Hi Summers, +1 for option #1 using the loader api and support library As you suggest, android support library is commonly used nowadays, so won't have big impact targeting old versions of Android Thanks, Christos On Feb 14, 2013, at 12:47 AM, 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 _______________________________________________ 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 _______________________________________________ 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