(Wanna talk about this? Contact me.)
UITableView class reference links to a companion guide, that explains how table views work in depth.
The documentation Apple provides is more extensive than you think. You've probably seen the class references, since that's the thing Xcode searches by default when you choose Help > Documentation. However, Apple also provides conceptual documentation that accompaines most of the classes; you can find a link to such documentation inside the "infobox" at the top of the class reference doc.
Also: symbols are not the only thing you can look for. Switch the bar to Titles or Full-Text to look for more conceptual documentation, or use the docs home page to browse. It's surprisingly well-organized, once you understand where to look.
Because the app bundle is read-only, damnit!
This is one of the most asked things on #iphonedev. Your application bundle is signed. Any changes to its contents will break it. Treat it as a read-only area. Have a SQLite database? Copy it out to a suitable directory before using it. (Suitable directories are the Documents and Library directories in your application sandbox — you can get a path to them via the
NSSearchPathForDirectoriesInDomain() function. See the docs for more.)
A common segue to this question is, "But it works in the simulator!". Yes, but your app is a Mac app while running in the simulator. On the Mac, .app bundles should be read-only, but the OS does not require this to be the case. (It's still more than just a good idea, because .app bundles may find themselves in situations where they're read-only — for example, if an account installs an application and another uses it.) So: you were doing it wrong, but Mac OS does not devote cycles to enforce this thing. iPhone OS does. You've been warned.
The Mail application shows a Delete button after swiping over a message.
The Tweetie application by atebits shows additional commands "under" a tweet when the user "sweeps it away" by swiping over it. If the user scrolls away, the message snaps back into place.
What I call "action-long modality" is one form of modal behavior of iPhone OS that is rarely seen in other software environments, although it could be easily replicated elsewhere.
"Modality", in software UI design, is the tendency to limit the user's available commands and ways of interactions, usually to direct them to perform a particular task before continuing with the regular use of the program. In desktop operating systems, it usually takes the form of "modal dialog boxes", which prevent the user from interacting with the rest of the application until they are dismissed; in most OSes, it is discouraged to use such an interaction model (especially under Mac OS X). In contrast to desktop OSes, in iPhone OS, given the limited screen real estate, it is common that the application performs "modal switches", removing previous commands to display new ones (with modal controllers, flipping to settings in utility applications and navigation via the navigation bar). iPhone OS also provides
UIAlertView, which works just like a modal dialog box does on desktop OSes.
Alongside fully modal interactions, the system encourages developers to use a slightly different kind of behavior I dub "action-long modality". Action-long modality is a mode switch that happens apparently "without leaving the previous mode"; the UI changes to display additional controls and waits for the user to make a choice. If the user appears to make a choice that does not use the additional controls, the action-long mode is immediately and effortlessly dismissed (rather than trying to block the choice as it happens with traditional modality). Most examples of this kind of interaction are dismissed immediately after the uses performs a choice — hence, action-long.
The most immediate example of this interaction is swipe-to-delete: if the user swipes over a row of a
UITableView, a "Delete" button appears. If the user presses it, the table asks its delegate to remove the row. If the user tries to perform any other action on the view, like for example scroll it, he will succeed, and the Delete button will quickly fade away.
Another application that makes use of this interaction model is atebits's Tweetie. Swiping over a message in any message view slides it away to reveal additional commands tied to that message in its place. If the user scrolls away or moves from the current view, the message will immediately scroll back into place. This allows the user to perform an action without having to press the message first and switch modes, or by adding another always-visible set of controls for performing these actions in the main view.
Action modality reduces the "modality switch load" on the user, making some interactions easier and faster and providing shortcuts for power users. Consider using some form of it in your application rather than requiring navigation before a command can be reached.
Safari displays a picker; note how it displays the web page as context above it.
Pickers are odd. They don't have a defined role; they feel right in a number of places. However, there are a number of situations where they are not the right tool for the job.
A picker is the right tool if:
If you don't have either of these needs, however, consider not using the picker. In particular, if you just want the user to choose between items on a list, use a
UITableView spanning the whole of the screen.
When using the picker, always place it at the bottom of the screen. You might notice it has the same size as the keyboard; this is done for a reason — just like the keyboard, it is expected to provide input to whatever lies at the top of the screen. For this, you should avoid placing the picker elsewhere.
The original keyboard toolbar: the Safari navigation assistant.
Tapolous's Fortune Cookie application doesn't have a navigation bar, so it uses an ornate keyboard toolbar to present its commands.
The Text (SMS) application has a keyboard toolbar that is used to display the input and provide a "Send" button, since the "return" button is used to start a new line.
When contracted, the Text (SMS) keyboard toolbar slides to the bottom.
A keyboard toolbar is a bar that is presented just above the keyboard. It is used for one of these purposes, in order of preference:
You usually implement a keyboard toolbar via an appropriately configured
UIToolbar that is moved up or down with the keyboard (which can be accomplished by responding to the notifications named
Keep this in mind when implementing a keyboard toolbar:
UIToolbar. Also, consider having the text box grow dynamically as the amount of text increases. You can use NSString's font-size category methods to calculate whether a string fits in that much space or if the text box needs to be shrunk or expanded. Avoid making the user use the loupe for scrolling.
Finally: a toolbar can also appear over other input mechanisms that appear on the lower part of the screen, like pickers. Consider following similar guidelines for such bars, too.