Mobile Zone is brought to you in partnership with:

Łukasz works as a Technical Architect for an international IT company and is responsible for delivering applications written in Java EE, Spring, and .NET. He has been involved in many various projects ranging from online insurance systems, voice and video solutions, mobile systems (both native and HTML5-based), medical systems, and large system integration projects. Łukasz is an expert in distributed systems, SOA, and cloud. Łukasz holds PhD in Computer Science. Łukasz is a DZone MVB and is not an employee of DZone and has posted 20 posts at DZone. You can read more from them at their website. View Full User Profile

10 More 'Most Useful' iPhone Tips (Part 1)

06.06.2013
| 3579 views |
  • submit to reddit

Maybe you recall my 10 Most useful iPhone tips series: 10 Most useful iPhone Dev tips (Part 1) and 10 Most useful iPhone Dev tips (Part 2).

Today, after yet another iPhone project I decided to write some more most useful iPhone tips as I'm richer in experience now.

1. MVC

Model View Controller is one of the most know/popular design patterns. Never break this pattern, never add business logic to views (as I've seen many examples all over the internet with business logic intermingled with view logic). Also, if you think that the following approach is good, you're wrong:

@interface SomeView {
SomeController *someController;
   UIButton *button;
}
-(void) doSomethingImportant1;
-(void) doSomethingImportant2;
@end

@implementation SomeView 

-(id)init {
   self.button = ...;
   [self.button addTarget:self action:@selector(doSomethingImportant1) forControlEvents:UIControlEventTouchUpInside];
}

-(void)doSomethingImportant1 {
   [self.someController doSomethingImportant1];
}

@end

It's wrong. The view should have no idea about SomeController and what actions are to be executed on touch events. The right approach is to have simple view:

@interface SomeView {
   UIButton *button;
}
@end

and assign all actions in SomeController:

-(id)init {
   SomeView *someView = [SomeView new];
   [self.view.button addTarget:self action:@selector(doSomethingImportant1) forControlEvents:UIControlEventTouchUpInside];
   self.view = someView;
}

this way we can re-use the SomeView in many other places. The business logic is where it should be - in view controllers.

2. Refrain from deprecated API

Don't use deprecated API. In most cases Apple gives you information what instructions you should use instead. For example:

button.font is now deprecated, you should use button.titleLabel.font instead.

3. Write your own protocols

Protocols are what Java/C# developers know as interfaces. The allow you to introduce a level of abstraction. For example you have some views which require login. You can create LoginAwareViewControllerDelegate protocol with following methods:

@protocol LoginAwareViewControllerDelegate<NSObject>
@required
-(void) loginSucceeded: (NSString*)context;
-(void) loginFailed: (NSString*)context;
@end

You can implement this protocol in every secured view controller. Then in LoginViewController you can create a property:

@interface LoginViewController {
   id<LoginAwareViewControllerDelegate> _delegate;
}
@end

and somewhere in login method:

if (ok) {
   [self.delegate loginSucceeded: self.context];
} else {
   [self.delegate loginFailed: self.context];
}

This way you don't care what is the type of the delegate, you just know its protocol and that's all you need to know.

4. Changing interface orientation and tab bars

In my project I was stuck for a while with Three20 Thumbnails/Photo view controllers. They simply didn't want to rotate. My colleague Stu found out the answer on Three20 mailing group. It turned out that parent TabBarController was blocking all rotations. To fix it I had to add the following 3 lines to my TabBarController:

- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation) interfaceOrientation { 
   return [self.selectedViewController shouldAutorotateToInterfaceOrientation:interfaceOrientation]; 
}

5. Call super methods

It's simple, always add [super methodName]. Why? Because in many, many cases (and especially in frameworks like Three20) crucial instructions may not be executed if you forget to call super method.

Summary
5 more (and 1 bonus) iPhone tip to come :)

I also plan to write one post about Three20 framework itself. About things I like and don't like.

Stay tuned,
Łukasz


Published at DZone with permission of Łukasz Budnik, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)