Hi Koen, Your approach doesn't sound that wrong to me.
How about having a master controller that is more or less what you have now, and split the functionality that handles the data stream out into a separate class that the master controller calls on to fetch the data? Then according to what it's fetching, it can swap in the appropriate handler object for that data. If that object returns the data as a single simple type, say NSData, then that can be handed off to the parser object (which again could be switched according to type) which does the right thing with it. When thinking about MVC, I find it's helpful sometimes to break it down into M-Ccccc-V (if you see what I mean) rather than trying to cram everything into one big controller. In this case, your controller only needs to know a) what sort of fetch it has to perform and so get the right subparts ready, b) how far along each fetch has got (to update the view showing progress), and c) the final data returned. That sounds like something that can be expressed by a common base class or a protocol. to me. --Graham On 20/09/2012, at 5:14 AM, Koen van der Drift <koenvanderdr...@gmail.com> wrote: > Thanks for the link, lots of info there. Unfortunately he doesn't > discuss the responsibility of the MVC classes in the slides regarding > the best location for the NSURLConnection code. I got that and the > paring already working, but need to make it more flexible. > > - Koen. _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
