注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

姑射道人的博客

博客新地址:nixuchen.com

 
 
 

日志

 
 

5StepsToBecomingABetteriOSDeveloper  

2012-05-31 21:02:44|  分类: iOS开发 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

5 Steps to Becoming A Better iOS Developer

by Costa Walcott

Introduction

When I first started learning to develop iOS applications, I went in to it expecting the process to be pretty simple. By this point I had a fair amount of experience with a number of different development environments, including web, desktop and server-side.

But as I started to get my feet wet with iOS development, I was thrown for a bit of a loop. The platform just wasn’t “clicking” for me.

Maybe you’ve experienced that point in the learning process where everything just fits into place. Well that just wasn’t happening for me.

The world of iPhone and iPad development can be hard to get a grasp on. You’re being thrown into a new language, new APIs, a new IDE, and new debugging tools. But even more than that, the day-to- day patterns that make up the “DNA” of development are quite different than any of the other environments I’ve worked in.

This can be especially frustrating when you keep hearing Apple say how easy it is to write an app! Don’t worry, you’re not alone.

In this guide I want to share with you the top 5 concepts that kept holding me back from getting that deep, intuitive understanding we all look for.

In the process I hope I’ll be able to help you become a better, wiser iOS developer.

1. Understanding Delegates

The delegate design pattern is used all over the place in the world of iOS, but it’s not one that I see used in many other environments.

Copyright ? 2010 Costa Walcott www.iosdevnotes.com

When you’re first starting out it can be really confusing trying to figure out what a delegate means, and when are the proper places to use them.

First let’s talk about why the design pattern is used.

A typical iOS application has all sorts of objects: windows, tables, buttons, input boxes, and so on. In a particular app, there are specific things you want to do with each object. You might want to perform a particular action when a user presses a button, or display specific data in a table.

Each instance of an object will require unique events and handling. Say we have an instance of UITableView. We’re going to want to display specific data in a specific way in the table, as well as handling events like tapping or swiping on rows.

To avoid having to make a separate subclass for each and every instance of every object (that would be a lot of subclasses), delegation is used almost like callbacks. You can write methods that respond to those actions or events, and they’ll get called when they occur. Instead of having to point the UITableView to every callback method individually, you can give it one object (the delegate).

A nice thing about delegation is that you don’t necessarily have to create a separate class for each delegate. You can have one of your existing classes also behave as a delegate for another object, or even behave as multiple delegates.

Although that provides a lot of flexibility, it can also be confusing trying to figure out what should behave as a delegate, and when.

Here are the most common ways you’ll see delegates being used in iOS code. A lot of this is just commonly accepted practice, not necessarily strict rules.

1. The application delegate. This is a bit of a unique one in that the application delegate (UIApplicationDelegate) is usually it’s own

Copyright ? 2010 Costa Walcott www.iosdevnotes.com

class. It allows you to respond to all sorts of application related events like starting up, shutting down, and going into the background. Xcode will create an app delegate for you when you start a new project. The application:didFinishLaunchingWithOptions: method in your app delegate is the place to look to see where the app first gets setup.

  1. UIView subclass delegates. There are lots and lots of subclasses of UIView that represent specific view objects, including UIScrollView, UITextField, UISearchBar, and so on. Many of these use delegates to allow to to respond to things like a user scrolling inside a few, or changing the text inside a field. Most of the time, you can make the corresponding UIViewController be the delegate.

    One thing that used to really confuse me when I was learning iOS development is when I should be looking to handle an event with delegates, and when I should use Interface Builder actions (IBActions). Usually if you’re listening for a user’s direct action (like pressing a button) you’ll use an IBAction, but there’s no clear-cut rule. When in doubt, I’d recommend looking up the documentation for the class in question.

    Over time you’ll just intuitively remember when you need to be creating a delegate. To help you on your way, here are the most common delegates I find myself using over and over again: UIScrollViewDelegate, UIAlertViewDelegate, UITextFieldDelegate and the two UITableView delegates (which we talk about below).

  2. UITableViewDelegate and UITableViewDataSource. UITableViews actually have two delegates, so I wanted to talk about them separately. It’s somewhat arbitrary, but the reason is to separate the logic behind the data being shown in the table from the UI actions like a row being tapped. More often than not both delegates will be handled in the same class anyway, usually a UITableViewController or a UIViewController subclass.

Copyright ? 2010 Costa Walcott www.iosdevnotes.com

Although delegates can be confusing at first, once you get used to them you might actually find yourself liking them, and even creating your own delegates! What’s nice about them is that they help you create cleaner, more reusable code.

For example, say you’re creating a dialog that asks the user for their name and age. Whatever object pulls up this dialog is probably going to want to know when the user is done entering their data. Instead of having to hard-code the dialog to one specific type of class that will initiate it, you can have a delegate for the dialog containing a method like userDidEnterName:age. Then any class can use this dialog as long as they implement the delegate.

2. Connecting XIBs with your code

The XIB files you create with Interface Builder can be a big help. It’s really nice to be able to visually layout how a screen should appear just by clicking and dragging. Imagine how tedious it would be to always describe that as lines of code!

However, I remember being confused with how these XIB files were supposed to match up with the code I writing in Xcode. Let’s walk through how it usually works.

The XIB files describe how views should appear in the app, but they don’t let us describe how we should react to events, or when we should change which screens the user sees. That type of logic is written in code, usually in a subclass of UIViewController.

The typical pattern is to have a subclass of UIViewController for each XIB file, usually of the same name. If you create your code by clicking File -> New File, Xcode can create both at the same time.

How does the code connect with the views? Usually in one of two ways: outlets and actions.

Outlets let you connect an object in the XIB file with a property in the view controller. When you declare the property in code, you

Copyright ? 2010 Costa Walcott www.iosdevnotes.com

have to remember to use the IBOutlet qualifier, or else Interface Builder won’t know about it.

When you want the view controller to be able to handle an action that’s shown in Interface Builder, create a method whose return type is IBAction. Again, Interface Builder won’t know about it without the IBAction qualifier.

Here’s some sample code from a UIViewController subclass that uses both IBOutlets and IBActions:

@interface LoginViewController : UIViewController { ! IBOutlet UILabel* headerView;
}

- (IBAction)doneButtonPressed:(id)sender; @end 

Just remember: IBOutlet is for attributes, and IBAction is for methods. In both cases, you hook it up in Interface Builder by going to the Attributes Inspector (under Tools -> Attributes Inspector) and dragging the circle on the right onto your view controller.

3. Memory Management

If you’re coming from a language like Ruby or Python, having to start worrying about memory management can be rough. On the one hand, Objective-C adds provides some features to try to make it a little easier to keep track of memory, but on the other hand this means learning new ways of handling memory.

An in-depth discussion of every aspect of iOS memory management would be too long for this guide. For a full discussion, I’d recommend checking out Apple’s “Memory Management Programming Guide”: http://developer.apple.com/library/ios/ #documentation/Cocoa/Conceptual/MemoryMgmt/ MemoryMgmt.html.

Copyright ? 2010 Costa Walcott www.iosdevnotes.com

But I’d like to share a few tips to help you along your way, especially since a lot of your early crashes while programming will probably come from memory handling.

The big thing to remember is that iOS really cares about who is “responsible” for an object. If you create an object by calling a method that starts with “init” or “copy”, you “own” it. When I say “you”, I really mean the class that’s calling the code. That means that at some point you’ll need to release the object, often when you yourself get released.

If you’re getting an object from any method that doesn’t start with “init” or “copy”, you don’t own it yet. That object might get freed by the OS behind your back. If you don’t need the object after the end of the current method, don’t worry about it. But if you’re going to want it later, you need to retain it (and also make sure it gets freed sometime in the future).

If your app crashes with a message like ‘Program received signal: “EXC_BAD_ACCESS”’, it probably means your code tried to send a message to an object that’s already been released.

4. Connecting View Controllers

As you start to get more comfortable with the basics of making a new UIViewController subclass and setting up its XIB, you may get hung up on how to connect them together. How do I bring up a new screen when the user taps on a button? Or how should I replace the current view controller with a different one?

Remember, when you’re setting up your UIViewController subclass, that subclass will still need to be instantiated somewhere in order to actually appear on-screen.

There are basically two ways to do it: in code, or in Interface Builder.

Let’s start with code. The way to do that is usually to use the initWithNibName:bundle: initializer that every UIViewController

Copyright ? 2010 Costa Walcott www.iosdevnotes.com

subclass has. You give it the name of the XIB file, and you’ll have a pointer to a new instance of that view controller. For example:

UserViewController *userViewController = [[UserViewController alloc] ! initWithNibName:@"UserViewController" bundle:nil];
[self presentModalViewController:userViewController animated:YES];

This code creates a new instance of UserViewController, then presents it as a modal dialog.

You can also create an instance of a view controller inside a XIB file, and then hook it into your code as an IBOutlet. All you have to do is drag the View Controller icon under the Library window onto the main XIB window. Then, select the object and go to the Identity Inspector (under the Tools menu). Next to Class change the field from UIViewController to the name of your subclass (say, UserViewController). Now you should be able to connect this to an IBOutlet in the code.

Be careful with this second method. Although it can be convenient and quicker than writing code, it’s easy to create a messy web of connections between all your different XIB files. I tend to prefer linking things together in code, but if you look at other people’s code you’ll probably see both ways of doing it.

5. Model-View-Controller

As you learn iOS development, sooner or later you’ll probably read about the Model-View-Controller (or MVC) paradigm that’s used by iOS. It’s a way to separate out business logic (models) from the UI (views) and have them only connect via controllers.

Coming from the web development world, I was familiar with the idea of MVC, yet I found myself a bit confused by how it was being used in iOS development.

Let’s start with controllers. This is probably the clearest of the three. Your controllers will be the subclasses you make from UIViewController.

Copyright ? 2010 Costa Walcott www.iosdevnotes.com

The view is an instance of UIView which is set as the “view” property of the UIViewController subclass. This view can contain may subviews of things like scroll views, images, buttons, etc.

The view often defined in an XIB file. However, your controllers don’t have to use XIBs. In some simple cases you might be able to set up your view in a few lines of code. Or, you might be able to create your own custom UIView subclasses.

The “model” in iOS’s MVC is very open-ended. Unlike the view and controller concepts, the model can be whatever you want. You don’t need any official “model” for every controller, but it can be helpful, and can lead to cleaner code.

In a dialog that asks for the user’s name, the model might just be an NSString. Or in a UITableViewController subclass, it might be an array of objects you retrieved from an API call to an outside service.

Whatever your model is, if you’re trying to stick to the MVC pattern, you want to try to keep your model code separate from your view code. Doing so helps leads to more reusable code.

One thing to remember is that there’s not one single “Model” or “View” for the entire app. Rather, it’s helpful to think of an application as a bunch of interconnected “MVCs”.

Take an example of a simple Twitter client app. When you start it up, the application asks for your username and password. That uses an MVC where the model is the username/password, the controller is a UIViewController subclass, and the view is an XIB that lays out how the screen should appear.

After the user enters their info and taps “submit”, the controller catches that IBAction, logs you into Twitter, and then brings up a new MVC for your timeline. Now the model might be an array of statuses, and the view and controller are defined in a separate XIB as a UITableViewController.

Copyright ? 2010 Costa Walcott www.iosdevnotes.com

When you’re starting to write an app, it’s easy to be at a loss for how to get started. While learning the details of specific iOS classes and methods, don’t loose track of the bigger picture. Almost any iOS you see (or build yourself) can probably be broken down into a web of little “MVCs”.

Conclusion

I hope you’ve found this guide useful! Please check out my blog at

http://www.iosdevnotes.com/ for more tips, tutorials and news. You can also sign up for my email newsletter if you’re not on it already.

Copyright ? 2010 Costa Walcott www.iosdevnotes.com 


  评论这张
 
阅读(436)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017