Re: Cocoa Asynchronous API Design
Re: Cocoa Asynchronous API Design
- Subject: Re: Cocoa Asynchronous API Design
- From: Pablo Pons Bordes <email@hidden>
- Date: Tue, 24 May 2011 22:45:51 +0100
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 (email@hidden)
>>>
>>> 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:
>>>
>>> This email sent to email@hidden
>>
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden