On Fri, Feb 15, 2013 at 1:00 PM, Christos Vasilakis <cvasilak(a)gmail.com> wrote:
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).
Reading the ticket...
"Cancellation is something that the user initiates and happens
synchronously, so any additional behavior that needs to happen can be
called as soon as the operation is cancelled."
I'd say that I totally agree with this statement!
If we agree on this, that is calling the failure callbacks in case of
"cancel", I can go ahead and implement this.
I am now a bit more convinced that we don't need to add the
callbacks... Another quote:
"cancellation happens immediately, rather than the rest of the
asynchronous bits of AFN that require callbacks.....the consumer of
the library, in that the developer writes [operation cancel], and in
the next line, can handle whatever else that follows."
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.
-1
I think, when one says [pipe cancel], immediately he can do the required bits.
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
_______________________________________________
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