Re: how to slim down view controllers?
Re: how to slim down view controllers?
- Subject: Re: how to slim down view controllers?
- From: Luther Baker <email@hidden>
- Date: Wed, 01 Apr 2015 09:55:58 -0500
> What's odd to me is that Apple preaches MVC, but then when we have the view controller class, all to often the delegate is lumped into the same class,
Whoa, you're blaming Apple for this?
How is MVC, MVP or Apple forcing you to do this?
> fostering code bloat and sorta going against compartmentalization of tasks (at least in my book it seems strange).
??? are you suggesting that how your code ends up is somehow not your responsibility?
I've seen a lot of complaints levied against Apple and product behaviors but I've never seen someone complaining that Apple made them "do it" (put a delegate somewhere).
Massive View Controllers is a well-known anti-pattern. For one thing, it suggests you're not refactoring enough. Development 101 stuff. It is not anyone's fault but your own if you are bloating your view controllers. You still need to *think*
> Here's the link to the article I'm thinking about.
>
> http://www.objc.io/issue-1/lighter-view-controllers.html
>
Consider reading all the articles in issue 13. http://www.objc.io/issue-13
Take a look at reactive cocoa ... https://github.com/ReactiveCocoa/ReactiveCocoa
Dig into Martin Fowler's articles http://martinfowler.com/eaaDev/PresentationModel.html
And by all means, pick your fights with Apple wisely lest you blame them for everything. Development is hard work. At some point you've got to reflect on your own skills.
> Hope this helps. Cheers,
> Alex Zavatone
>
-Luther
>
>> On Apr 1, 2015, at 8:59 AM, Juan Felipe Alvarez Saldarriaga wrote:
>>
>> Hi,
>>
>> How you guys slim down your view controllers?, sometimes you end up implementing a lot of protocols in your view controller, so there’s a lot of code inside the controller itself. Reading about how to slim down view controllers in iOS I found that a common way is to move DataSources (http://www.objc.io/issue-1/lighter-view-controllers.html) to other class, but what about other delegates?, or if you create views by code?. First, I think about move each delegate to a NSObject class, so I try this:
>>
>> self.locationManager.delegate = [[FRRYPetDescriptionViewControllerLocationDelegate alloc] init];
>>
>> Then I ask in IRC and somebody suggest categories, so this is what I got so far:
>>
>> // FRRYPetDescriptionViewController.h
>> @interface FRRYPetDescriptionViewController : UIViewController
>>
>> @property (nonatomic) CLLocationManager *locationManager;
>>
>> @property (nonatomic) TPKeyboardAvoidingScrollView *scrollView;
>> @property (nonatomic) UIView *contentView;
>>
>> @end
>>
>> // FRRYPetDescriptionViewController+Protocols.h
>> @interface FRRYPetDescriptionViewController (Protocols) <UITextViewDelegate, UIActionSheetDelegate, MFMailComposeViewControllerDelegate, UIGestureRecognizerDelegate, MKMapViewDelegate, UIViewControllerTransitioningDelegate, CLLocationManagerDelegate>
>>
>> @end
>>
>> // FRRYPetDescriptionViewController+UIAdditions.h
>> @interface FRRYPetDescriptionViewController (UIAdditions)
>>
>> - (void)createScrollView;
>> - (void)createContentView;
>>
>> @end
>>
>> // FRRYPetDescriptionViewController+Callbacks.h
>> @interface FRRYPetDescriptionViewController (Callbacks)
>>
>> @end
>>
>> // FRRYPetDescriptionViewController+LocationAdditions.h
>> @interface FRRYPetDescriptionViewController (LocationAdditions)
>>
>> @end
>>
>> This makes me think, what about “private” methods?, do I need to declare all properties in the view controller header file?. What you guys think about this approach or there’s some common pattern to follow to not end with a fat controller?.
>>
>> Thank you.
>>
>> --
>> Juan Felipe Alvarez Saldarriaga
>> http://juan.im
>> Twitter: @nebiros
>> Google Talk: email@hidden
>> Skype: jfasaldarriaga
>>
>> _______________________________________________
>>
>> 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
_______________________________________________
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