Getting Organized

Organization is extremely important in creating applications for Android. This is of course true for any type of programming development, but it is particularly true in this case because the limited nature of the devices one is programming for requires careful organization of how things will be presented to the user. This is one of the main reasons that it is highly advantageous to use a development environment like Android Studio, since this automatically provides a substantial amount of structure and organization for a project.

Some General Guidelines

Because one can combine so many possibilities into an Android project, it is difficult to give a completely general set of guidelines for organizing and developing a project. Nevertheless, it is useful to give a default general outline for developing projects, with the realization that is will sometimes have to be modifed to accommodate issues associated with specific projects.

• Sketch conceptually what the project is intended to do, with words and with diagrams where appropriate. Because of the nature of target Android platforms, basic chunks of an app should be relatively compact and self-contained. Thus, in a more complex project, one should as far as possible organize it in terms of a set of subprojects, each with a well-defined task or limited set of tasks.


• Sketch the visual layout of the screen or succession of screens that will be used to interact with the user in order to carry out these tasks. Here one needs to give careful attention to the most appropriate widgets to carry out the desired tasks in an efficient and user-friendly fashion.


• Choose appropriate names and list the Java classes and associated XML resource files that will be defined to implement the tasks outlined in steps 1-2. Make a preliminary list of any special permissions or keys that the project will need.


• Sketch the logical layout for how your app will respond to user input. Since applications will often be event-driven, this will usually involve at a minimum listing the types of event handlers that will be attached to the screen widgets, but may require additional specification if the app has multiple parts that must interact with each other.


• Create an Android Studio project with a descriptive name. Since they are not so easy to change later, choose wisely the class name for the primary Java file (typically the app entry point) and the namespace (e.g., com.lightcone). Also choose wisely the target Android platform and the minimum SDK that you intend for the application to run under. These can be changed easily, but it is best to know exactly what Android SDKs are being targeted before you begin programming.


• Modify the AndroidManifest.xml file for the project to add any specific permissions that you know the project will require, such as internet access or access to Google maps, or coarse-grain and fine-grain location services.
• Create or modify the resource XML files for general strings (in res/values/strings.xml), colors (in res/values/colors.xml), styles (in res/values/styles.xml), and special icons (in the subdirectories of res/drawable) that will be required (guided by step 2 above). For example, screen titles, button labels, and colors for fonts and backgrounds can be specified here. Be sure that these files indicate no errors when saved.


• If the default entry Java class file does not compile, modify the file so that it does compile. At this stage, errors will normally be associated with missing resources or assets, or errors in the XML files, or possibly missing Android and Java import statements at the top of the file. Android Studio can indicate the source of most of these errors, and can often fix these errors automatically, as illustrated in the A Simple First App and WebView Demo project.


• If not already done, configure appropriate Android Virtual Devices (AVDs or emulators) to test the project, as described in Configuring an AVD. At the very least you will want to test with an emulator for the target API level at each step, but you also should have an emulator for the minimum SDK that you have specified (if it is lower than the target API level), and should test on it at least at the completion of major pieces of the app. If you have a physical device that you wish to test on also, attach it using the USB connection, and configure the device (if not already done) as described in Installing on a Device.


• Open windows and initiate logcat logging for all emulators and devices on which you will test as described in The Purr of the LogCat.

Some Application-Specific Issues

To this point the outline has been rather generic and can be applied with only simple modification to most Android projects. From this point onward the development becomes much more specific to individual projects.

• Add the additional code to the main Java file and to the main layout file main.xml to implement the first screen of the project. In parallel with that, add any additional Java classes and associated XML resources required to implement this functionality. Normally as part of this you will have to add various import statements to give your app access to the required parts of the Android API. As noted above, Android Studio can automate much of this if you use it as illustrated in the WebView Demo projects.


• Add additional Java classes, associated XML resource files, and additional resources such as image or sound files to implement functionality beyond the main screen of the app. Often this will involve working on Java/XML file pairs that reference each other. As part of this, you may have to add additional permissions and registrations to the AndroidManifest.xml file. In particular, addition of functionality will often involve defining new activities, and Android requires that each activity be registered in the AndroidManifest.xml file with a line of the form
  
  

  <activity android:name=".Webscreen" android:label="Web"></activity>
  

  inside the <application></application> tag.

And, of course, test extensively on emulators spanning the range of API levels and physical capabilities that you are targetting, and on as many hardware devices as possible.

Last modified: July 25, 2016