On Oct 19, 11:46 am, Kevin TeslaCoil Software <[email protected]> wrote: > Disclaimer, I don't know ant so I might be doing things awkwardly. > This is by no means a packaged solution, but an idea/example for you > to build your own system with.
This was closer to a better solution, but I really dislike build systems that need to mess with code to do their business. I've found it's much cleaner to have build systems mess with "external" config which alters the way a build is produced. I work on an app that has over 10 variations for various combination of market/free/paid/partners, and all the differences between them have been abstracted into simple configuration. There is one master library project that contains the vast majority of code and resources. Each individual variation of the app has a "shell" project which has customized resources expressing the different config needed for each variation of the app. The way android tools builds these projects forces the shell project resources to replace any existing library project resources, so I can override default settings this way. In the shell project resource files, I can have booleans for free/ paid, strings for hosts and ports, and so on. Each of these will override a default from the library project resources, or the project can take the default. In order to have different logic for each variation at runtime, I specify fully qualified java object names for the different implementations. These implementations can live in the library project or in the individual shell projects. Think of these as plugins that all implement a common interface. At runtime, my app will find the implementation of the logic it needs using resources, then use reflection to instantiate that class, then call into it using the common interface to get the behavior I want that is specific to the app. You could use this to, for example, abstract away logic that does market license checks. On top of all that, I have my ant build scripts create new Android resource files that are added to the shell projects in order to inject things like build tags that come from my continuous integration environment. I was originally doing token substitution on resources files, but that kind of sucked for development. It's much cleaner to create whole new files for configurations that are only known at build time. Android build tools will just include every resource file it finds under the res directory, so I can create new files there as much as I need. There is really no need for a preprocessor at all with intelligent use of resources. Hope this helps. Doug -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
