Some of this really boils down to platform specifics, how they handle things like that...

I guess... from a high-level point of view we need at least the availability to "cancel" a request!
I think this is true on ALL the AGPipe "interfaces"...

in iOS/Android for sure!

Also in JS/Cordova land...:
When the browser/webView becomes inactive.... there MAY be an event, telling the environment that is goes to "background".
This event callback could simple invoke the cancel, on the pipe, to stop ALL of networking activity, on THAT pipe.

The (iOS) API usage would be like:
[myProjectPipe cancel]; 

Not sure if we need callbacks on that cancel......


-Matthias




On Tue, Feb 5, 2013 at 1:08 PM, Matthias Wessendorf <matzew@apache.org> wrote:
for iOS, it looks like the underlying AFNetworking has something for
that - currently evaluating....

So... it could just boil down something _LIKE_ this:
https://gist.github.com/matzew/369f6d43389d5564cbdc

( a 0.0.1 version :))


On Tue, Feb 5, 2013 at 12:33 PM, Summers Pittman <supittma@redhat.com> wrote:
>
> 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
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev@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



--
Matthias Wessendorf

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