Maybe you are right, for the developer point of view maybe it doesn't simplify 
the use of the API, this suggestion was from the problem of use block (that if 
the intention was to use bloks as delegate method parameter doesn't have to 
much sense the use of NSOperation).

But from the implementation point of view, use NSOperation could make it easier 
to manage different action (operation) depending of the type of date send or 
received, give concurrency control (as example: you could control how many 
download thread are open, without any difficult). Yo divide the data reception  
action into different operations  (parse, import, save, etc). It give you a 
easy way to debug the code and improve performance each step of the process.

Any way if it is possible I would suggest to experiment with blocks, it look 
that works relay well with CFNetwork this project the use it and it looks with 
great results:
http://code.google.com/p/cocoaasyncsocket/.

Any way I think maybe I,m getting away for the purpose of this mail,  
apologize. 

So to answer this  email question:
I prefer to have a solution like Path 2, simplify delegate method. I think is 
much easy to debug, because a lot checking will be the same independent of the 
action type. Then the developer with a simple switch could decide which method 
call in its implementation. (inside the MyInventoryAction class could be an 
action Type enum)

I think the key to make this implementation works is give to the developer 
enough information to take the correct action fast, and I thing with the 
MyInventoryAction class as input parameter there is room to give to the user 
the information needed and  at the same time give the possibility to improve 
the API without behavior modification, and without the need to add more API 
methods.

Good luck at your decision
--Pablo

El 24/05/2011, a las 19:49, Tito Ciuro escribió:

> Hi Pablo,
> 
> Why would NSOperation be a better solution than say, NSURLConnection? I can 
> call NSURLConnection several times (performing different actions) and have 
> each delegate be invoked appropriately while maintaining some level of 
> concurrency. It seems that adding NSOperation would add an extra level of 
> complexity in this case, no?  In any case, it's an implementation detail. 
> What I still wonder is what would simplify the API from the developer's point 
> of view.
> 
> Thanks!
> 
> -- Tito
> 
> On May 24, 2011, at 11:24 AM, Pablo Pons Bordes wrote:
> 
>> What about use NSOPeration?
>> 
>> This way you could have a different NSOperation implementation depending of 
>> the item type, and use a solution like path1, and it will work at older iOS 
>> (the documentation said it is available since IOS 2.0).
>> 
>> I think Bloks was introduced at iOS 4 but, anyway iOS 4 works on any iPhone 
>> since iPhone 3G so you will be able to cover most of the devices, if Is it 
>> correct? (I thinks it is).
>> 
>> If you move to Bloks it could simplify a lot some asynchronous code, and 
>> prepare the code form multiples core devices in the future.
>> 
>> It could be interesting to know how many iPhone older than 3G are in use and 
>> install apps on there.
>> 
>> --Pablo
>> 
>> 
>> 
>> El 24/05/2011, a las 19:05, Tito Ciuro escribió:
>> 
>>> Hi Seth,
>>> 
>>> I thought about adding blocks, but I would like to support older iPhones if 
>>> possible. Blocks were introduced in iOS 4, correct?
>>> 
>>> Thanks,
>>> 
>>> -- Tito
>>> 
>>> On May 24, 2011, at 10:30 AM, Seth Willits wrote:
>>> 
>>>> On May 24, 2011, at 8:25 AM, Tito Ciuro wrote:
>>>> 
>>>>> I have a question about Cocoa API design. I think I can give a concrete 
>>>>> example to best explain what the goal is. Assume I have an Inventory 
>>>>> service and I need to write a client API that deals with it. Goals:
>>>>> 
>>>>> - The API should allow me to add, update, delete and search items
>>>>> - These operations should be asynchronous
>>>> 
>>>> 
>>>> - (void)addInventoryItem:(Item *)item resultHandler:(void (^)(NSError * 
>>>> error))resultHandler;
>>>> 
>>>> In this way, the result handling block already has access to every 
>>>> parameter and the receiver, so there's no need for verbose delegate 
>>>> methods which pass them all back, or packing and and unpacking an object 
>>>> which contains them all.
>>>> 
>>>> 
>>>> --
>>>> Seth Willits
>>> _______________________________________________
>>> 
>>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>>> 
>>> Please do not post admin requests or moderator comments to the list.
>>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>> 
>>> Help/Unsubscribe/Update your Subscription:
>>> http://lists.apple.com/mailman/options/cocoa-dev/pablo.mailinglists%40gmail.com
>>> 
>>> This email sent to pablo.mailingli...@gmail.com
>> 
> 

_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to