Lesson Learned: Wipe data and cache before upgrading a ROM.

Question to Answer: How best to back up settings so I don’t have to re-enter them? Android does a great job of re-installing all of the apps I’ve downloaded from the Android Market, but re-entering all of my settings is a pain. Some apps let me back up settings (like Setting Profiles), but most do not. Is this something Titanium can help me with?

Armed with this knowledge, let’s look at one possible way to organize our framework configuration files to account for environment differences. My preferred approach (at the moment) is to use a directory structure – with a different directory representing each environment. I’ll throw all of my config files for a given environment in the corresponding directory. This approach works for any component configuration that can be included from app_config.xml. Not all components will honor this approach, but many will (see list below). For all the “non-compliant” configurations we’ll group the environment settings together and use a naming convention coupled with the system property to pick out desired settings at runtime.

Configurations That Honor “Include”

Let’s start with the directory-driven stuff. Set up a directory structure in the /src directory of your WAR (or whatever you are using as your source directory) as follows:

In this example I place the configuration files for Codes and Data Access in the Development, Test, Prod directories, with environment specific settings in each copy of the file. We will drive which directory and file is selected using the include file mechanism in app_config. Let’s cover that in a moment, first I want to address those pesky non-compliant config files. The non-compliant configuration files (all those not in the above list) must be placed in a subdirectory named after the component itself – as is reflected in the prior example. To enable environment-specific settings, I recommend lumping all of the environment settings for a given component in a single file, then use a naming convention to differentiate them. Here is an example for the Directories component.

You can follow the same pattern for content-services.xml and any other configuration file that must be in a fixed location. The key is to define the lookup name in such a way that they reflect a specific environment. We’ll use custom configuration properties to determine the appropriate lookup name at runtime using the app_config.xml file, which follows:

Notice that we’ve used a reference to a system property to customize the location of the log4j.xml file, placing a custom copy in each of our environment directories. We use the include file mechanism for environment specific configurations for codes and dataaccess – using the system property substitution to provide a specific path at runtime. For the non-include-compliant configuration files you can use a lookup mechanism driven by custom properties. In your application, when doing a lookup (i.e. using the services factory to get an instance of a component, use the custom property to do the lookup rather than the specific literal name given in the configuration file. In this example, use the property “EDMS.AD_Directory” to do your lookup for an environment specific reference to the directory instance you want to work with. With this approach you can change the system property EDMS_Environment to reflect the name of the environment you are running in. Your application uses the property to do lookups for those components that are not yet capable of supporting the “include file” mechanism for app_config.

You could, of course, use the environment variable/lookup mechanism for ALL configuration files. That provides consistency, but requires a little more effort. On the other hand, it also lets you put all of your environment configurations for any component in a single file. Also, you might elect to using a file naming convention rather than a directory structure. In this case, you could prepend or append the env variable reference to the file name to create a reference to the desired config file. Use whichever approach works best for you.