iPhone development - app design patterns_问答_开发者

There ar开发者_如何学Goe tons of resources concerning coding on the iPhone. Most of them concern "how do I do X", e.g. "setup a navigation controller", or "download text from a URL". All good and fine.

What I'm more interested in now are the questions that follow the simpler stuff - how to best structure your complex UI, or your app, or the common problems that arise. To illustrate: a book like "Beginning iPhone 3 Development" tells you how to set up a multi viewcontroller app with an top 'switcher' viewcontroller that switches between views owned by other view controllers. Fine, but you're only told how to do that, and nothing about the problems that can follow: for example, if I use their paradigm to switch to a UINavigationViewController, the Navigation bar ends up too low on the screen, because UINavigationViewController expects to be the topmost UIViewController (apparently). Also, delegate methods (e.g. relating to orientation changes) go to the top switcher view controller, not the actual controller responsible for the current view. I have fixes for these things but they feel like hacks which makes me unhappy and makes me feel like I'm missing something.

One productive thing might be to look at some open source iPhone projects (see this question). But aside from that?

Update

To clarify: I suppose what I'm asking about could be summarised as "Recipes and Gotchas for iPhone development". The sort of things that are of interest to developers, but aren't covered in any of the iPhone books etc. that I've seen, such as:

I'm writing an iPad app and want a UISplitViewController presented to the user only some of the time, which Apple seem to be saying I can't do. Is it possible? How?
Apple don't give me a way to stylise my app in a convenient, across the board way (e.g. font tweaks, or colours). How can I approach styling my app?
Memory management isn't made any easier by some of the inconsistencies in UIViewController method names (e.g. viewDidUnload is not the opposite of viewDidLoad, despite the name). Is there a consistent easy way to tidy that up and make view controller memory management less error prone?
How can I consistently and easily test my view controllers for behaving correctly when a memory warning comes in? It's easy to simulate a memory warning in the Simulator, but if the UI I want to test is showing (and is a 'leaf level' view controller), it won't get its view unloaded because it is currently visible.

N.B. I'm not actually asking the above questions here -- I think I have decent answers to them! -- just giving examples of 'good' questions that illustrate this stackoverflow question.

The WWDC talks available on iTunes U (at http://developer.apple.com/videos/wwdc/2010/) have some great information about structuring, especially in the Application Frameworks section.

If you're talking about code, use the Model/View/Controller pattern like in most Web applications:

The model code defines the objects that your program represents. A time tracker app, for example, might have model objects like Task, TimeSlice, and User (especially in a network setting).
The view code is provided for "free" with the iOS SDK, unless you need specialised view code. These are UIImageView, UIButton, etc.
The controller code bridges the 'gap' between the model and view. The controller will change the views to reflect the model selected by the user and facilitate the selection of model objects.

This is the base design pattern for any iPhone app, and it's the one that most will use.

If, on the other hand, you refer to what we in my company call UX (user experience) design, however, you can't beat the Apple HIG guidelines in the Apple iOS SDK documentation set, available online or in Xcode from the Help menu.

The other thing I recommend quite highly is to play around with some test/dummy code. Nothing can top experience. Experimenting with the iOS SDK and getting your hands dirty will allow you to truly learn the best ways to design apps.

Edit:

Also, delegate methods (e.g. relating to orientation changes) go to the top switcher view controller, not the actual controller responsible for the current view.

Can you clarify? In all of the apps I've written, the currently shown view controller receives the orientation change methods. Note that there are two methods. shouldAutorotateToInterfaceOrientation: allows you to decide if the view should rotate, and didRotateFromInterfaceOrientation: allows you to re-layout the view if necessary.

Please go through this link. In this they have explained clearly about design patterns.

http://www.raywenderlich.com/46988/ios-design-patterns

You might want to consider watching videos like the CS193p course from Stanford on iTunes U. They go through the most important parts of iOS development in deep, and give some source code.

As far as I can tell, there isn't a book or resource which deals with the sort of advanced gotchas and recipes that I was looking for. Loads of useful resources exist, but just not addressing the stuff I'm thinking about.