[aerogear-dev] "cancel" method on Pipe

[Matthias Wessendorf]

On Fri, Feb 15, 2013 at 1:00 PM, Christos Vasilakis <cvasilak at 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 at apache.org> wrote:
>
>> On Thu, Feb 14, 2013 at 6:08 PM, Summers Pittman <supittma at 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 at 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/aerogear-client-pipe/index.markdown
>>>>>
>>>>>
>>>>> Summers
>>>>>
>>>>> 1: (898,901,895)
>>>>>
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> aerogear-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at 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