Advanced Topic: Designing Your Application
Although I labeled this an advanced topic, design should take place before you write a single line of code. The most basic design ideas include:
mCv
PUSHING/PULLING/POLLING for data
Messaging Using Stateful Objects
Encapsulation
Indirection
Chaining Applications
Localization
mCv
This is not the MCV of SmallTalk. The most basic application architecture is to divide your app into three parts. The model object holds the application algorithms and persist the data. The view contains the presentation. The Controller responds to user and system events and owns the model and view. So you create a "separation of concerns" where the view is in Main.xml, the algorithms are in a Model.java class and the Activity handles the events.
PUSHING/PULLING/POLLING for Data
There are at least three ways to obtain data. In response to a user event or system event, the Activity can PULL data from the model as in MyModel.getData(). Alternatively, the app can register an interest in changes to Model state and wait asynchronously for updates as the model PUSHes data to the Activity. This is the OBSERVER design pattern. Finally, the Controller (MyActivity) can check at regular intervals for data calling MyModel.getData(), POLLING for data.
Messaging Using Stateful Immutable Objects
It can be argued that messaging is the key concept in OOP, not objects. Throughout this tutorial you will see how messages are used as a key abstraction. So we send immutable thread safe messages between Activities in an Intent bundle. We save object state in stateful objects and pass the objects back on orientation change, essentially messaging ourselves. Finally, we launch threads that return data in messages that queue up in a message handler bound to our Activity. Since serializable objects are flattened and copied, one could argue that the use of immutable serializable objects is over-kill.
Encapsulation
We try to keep private data private (not protected) and provide public getter and setter when appropriate. We try to keep the event handlers "close to the objects". So prefer anonymous inner classes rather than listeners in the enclosing class and try to avoid switch statements.
Indirection
We look for opportunities to develop a "plug in" architecture using interfaces. We separate out Strings into Strings.xml so that we can localize our application in the future. We look to separate out repeating logical code segments into methods to ensure consistency and ease of maintenance.
Chaining Applications
We look to leverage the power of our application and existing applications by "piping" data to our app and from our app to other apps.
Cycles
We envision a new feature or requirement. We prototype the code. We test to see if we met the requirements. We re-factor the code for clarity, ease of maintenance, and efficiency. We retest the code to see if we still meet the requirements.
Testing
We do testing on units of code. We test for orientation changes. We test for the back button and home button. We test launching our application using Intents. We test our application on different virtual devices. We do user testing to learn what the user's want.
Localization
The Android OS makes localization a relatively simple task IF you took the time to use named strings in strings.xml. The OS will look first into the res/values-XX-XXX files that best match the locale, resorting to using the named strings in res/values only if a more locale specific named string is not available. For instance, for Canada add a folder res/values-en-rCA and for United Kingdom add a folder res/values-en-rGB, each containing the file strings.xml. You can test for localization behaviour on the emulator by launching the app "Custom Locale." Scroll to the appropriate locale and LONG PRESS to select --> and then apply.