开发者

If I write a framework that gets information from the Internet, should I make a degelate or use blocks?

开发者 https://www.devze.com 2023-02-05 00:38 出处:网络
Say I\'m writing a publicly available framework for the Vimeo API. This framework needs to get information from the Internet. Because this can take some time, I need to use threadin to prevent the UI

Say I'm writing a publicly available framework for the Vimeo API. This framework needs to get information from the Internet. Because this can take some time, I need to use threadin to prevent the UI from hanging. Foundation uses delegates for this, like NSURLConnectionDelega开发者_开发知识库te. However, Game Kit uses blocks as callback functions.

What is the recommended way of doing this? I know blocks aren't supported in standard GCC versions, but they require less, much less code for the one that uses my framework.

Delegates, on the other hand, are real methods and when protocols are used, I'm sure the methods are implemented.

Thanks.


I really like blocks but I would be tempted to use a delegate protocol in this case. Network connections can fail in a large number of ways and their delegates tend to keep a fair amount of stateful information about them. I find that that maps well to a delegate protocol with a number of optional methods.

If you're providing a very simplified API for accessing network data then a success/failure pair of blocks might be sufficient. Personally I find that I have to deal with alot of different cases which use many delegate methods on a stateful delegate object. For example; should I retry failed connections immediately or later, does the relative priority of failed connections change, can I make us of a partial response, should I switch a connection to wifi when it becomes available, do I offer a user a chance to authenticate if prompted, do I display incremental progress in a connection? You could handle all of those with blocks but I find that I would rather have a delegate class managing the connection.

Without knowing more about what data you intend for your interface to fetch I don't know that I can be more specific but. I would be tempted to allow users of the API to manage their own connection state if possible.


It all depends on who your target audience is. If you want people writing apps for OS X 10.5 or iOS 3.x, then you need to use delegates. Otherwise, go ahead and use blocks.


It's quite a subjective question since both are valid options, but Apple seems to be shifting further towards using blocks for "throw-away" methods.


The main question would be your target audience.

Block are limited to Snow Leopard (and IOS 4? cant remember).

If you want your framework to be usable by previous operating systems, you can't use blocks.

If you're happy with os limitations, then go with blocks and NSOperationQueue, it's really good and simple to use.

Better, you could offer both options..


I would recommend using blocks, and if you do it right, you can support 10.5 at the same time.

Check out the open-source PLBlocks runtime, it allows you to seamlessly use blocks on both 10.5 and 10.6.

0

精彩评论

暂无评论...
验证码 换一张
取 消