11:33 a.m.
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
12:08 p.m.
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(a)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(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
12:53 p.m.
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(a)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(a)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(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
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
4335
days inactive
4338
days old
2 comments
2 participants
participants (2)
-
Matthias Wessendorf -
Summers Pittman