6 a.m.
Hi,
following up to Matthias email, in the underlying AFNetworking library default behaviour
when calling cancel is to traverse all running operations, cancelling each one of them.
Further, default behaviour is not too call the "failure" callbacks ( the reasons
why is described here[1]). It can be adjusted though by doing an override, as described
(without modifying AFNetworking library).
If we agree on this, that is calling the failure callbacks in case of "cancel",
I can go ahead and implement this. My only worries is that the "usual" failure
callbacks, display some kind of an alert informing the user, and I am not sure if popping
up multiple alerts (for simultaneous requests) is a good thing..
Another suggestion is to allow the user to register on the Pipe Config a cancel
callback(optional) that will be called only once (when issue "cancel" on the
pipe). This will:
a) Will let the user decide how to handle cancel. Either dispatch an alert on the main UI
queue, or do some other work, or if not configured, silently ignore.
b) No checks on the failure callbacks to see if the failed was called by a cancel or by an
error
c) Enforces the statement that "cancel", cancels all the pending requests on
the Pipe and a single callback is called when performing it.
What do you think?
Thanks,
Christos
[1] https://github.com/AFNetworking/AFNetworking/issues/479
On Feb 15, 2013, at 10:14 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
On Thu, Feb 14, 2013 at 6:08 PM, Summers Pittman
<supittma(a)redhat.com> wrote:
> On 02/14/2013 02:31 AM, Matthias Wessendorf wrote:
>> On Mon, Feb 11, 2013 at 4:12 PM, Summers Pittman <supittma(a)redhat.com>
wrote:
>>> We have three JIRA's[1] to add a cancel method to Pipe.
>>>
>>> In Android (and presumably iOS and to a lesser extent JS) Pipes are shared
>>> among multiple threads and each request exists in its own scope. (IE
>>> multiple threads can have multiple requests running at one time).
>>>
>>> When a "cancel" is called, which request is cancelled?
>> When calling cancel on a pipe, I'd assume that all enqueued/running
>> requests, for that particular pipe, are canceled.
> -.15
>
> I don't like it but 99% of the time there will only be one call in the
> Pipe.
that's what (because of underlying AFNetworking) the iOS side of
things will be doing
> What happens on the callbacks? I would assume either onError would be
> called with an appropriate object/message(+1)
+1
> or we add an onCancel
> method(-1).
>
> Summers
>>
>> -Matthias
>>
>>
>>> I've attempted to address this (and some larger issues) here:
>>>
https://github.com/aerogear/aerogear.org/blob/pipe_spec/docs/specs/aeroge...
>>>
>>>
>>> Summers
>>>
>>> 1: (898,901,895)
>>>
>>> _______________________________________________
>>> 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