This is a post I wrote when I was transferring some of my work to an offshore dev team to help them get started and also to clarify my thinking process a little. Keep in mind that this generally applies to apps that don’t do much Graphics work. (Non OpenGL ES) So here goes –
There are 3 basic equivalent ideas behind all the major mobile platforms. They are –
- Each application runs as a process and can spawn multiple threads.
- Each application consists of screens / views.
- The views are maintained on a stack.
So first the application. The OS (iOS/BlackberryOS/Android) runs the app as a process. This app can have single or multiple threads depending on how you program it. By default it is initialized with one Main/UI Thread. This is the thread that is responsible for drawing all of your UI components and receiving any sort of user input. As a rule of thumb, your application should not do any signficant processing on the UI Thread (Network calls, math functions and the like). This will render the app unresponsive to user input and all 3 OSes kill your app if the UI doesn’t respond in a few seconds. Since all three platforms support multitasking in a fairly similar way, my next post will be on implementing multi-tasking on each of these devices.
The second bullet should be fairly obvious, and it is that you have screens on which you display content. This is roughly equivalent to a page in Web development. (not exactly, but for our purposes it is). For example a Login page has one screen, User Profile page is another and so on. When the Application is initialized, you generally have to create atleast one screen to display as the start screen.
The third bullet is directly related to the second one. In all 3 OS’es, you’ll be pushing screens into a stack and popping screens off it in a First in, first out fashion. The screen on the top of the stack is the one that is displayed to the user.
And a little more detail –
Getting into a little more detail, on the design of the actual screen, it is a strict Model-View-Controller pattern on the iPhone and Android, but Blackberry doesn’t provide an explicit View/Controller separation, so it’s more of a Model-View+Controller.
(A simple explanation of MVC pattern here – http://www.enode.com/x/markup/tutorial/mvc.html)
Lets start with the View because it’s the simplest –
If we go into screen design, each of the mobile platforms has a different approach.
- Apple provides Interface builder, a tool with a drag&drop UI for building your application screens. You can drag drop components and connect them to elements defined in the code. This way you don’t have to worry about changing the code when you need a few UI changes. I’ll talk a little bit more about designing screens for iPads + iPhones (3G vs Retina display) in later posts.
- Android provides XML based UI layouts. You write XML for each screen and positioning of each component is defined in the XML. This again achieves the split cleanly between code and UI. The layout is defined by 3 elements – <LinearLayout> which can place one component next to or below another, <RelativeLayout> which lets you place components relative to another component, <TableLayout> which is equivalent to the HTML table. These elements can be nested, anyone inside any other, to give the UI any look you’d like. I’ll talk a little bit more about the issues that I had to deal with while designing for multiple resolutions in the later posts.
- Blackberry forces you to define all your components and their layout in the code. This means you’re forced to make source code level changes for any UI updates that might want to make which sometimes can be cumbersome. In this context, the controller takes care of drawing the UI componentson the screen. Similar to Android there are various Managers that RIM provides that help you laying out UI elements on a screen. HorizontalFieldManager, as the name suggests, lays out all the elements horizontally. VerticalFieldManager lays out the fields added to it vertically. So to create a Button, you just write Button loginBtn = new Button(); and add it to the screen. mainScreen.Add(loginBtn); The positioning again is defined by HorizontalFieldManager, VerticalFieldManager objects which lay components horizontally next to each other or vertically below each other. These can again be nested.
Next up is the Controller. The controller is fairly straightforward most of the time. You define listeners for each action that you want to be notified about (Button clicks, text changed and the like), and we’re done.