Masa Update

[Shane Isbell]

I'm going to be jumping back into Masa this coming week. I've hit a
point in developing of an Android application (SlideME's SAM client)
where I need to release 5 different versions of essentially the same
application, but with different resource files, different URLs,
images, etc; so it's become completely unmanageable for me.

I've also formalized the test cases for the app and need to get those
automated so will be working on the test support as well. If anyone
else has similar needs, let me know. Also anything burning, get it
into the bug tracker so we can prioritize.

Thanks,
Shane

[Hugo Josefson]

Hi Shane,

Glad to see you're back! The SAM client is starting to look really
good :)

I recognize your use case for building an application in many
different variants, using different resources etc... I have been in
this situation a few times, and there is one specific case where you
can make life a little easier on yourself (depending on how you view
it).

If your application is the type of application which requires a
network connection to be useful at all (which I believe for example
SAM is), then you could make the client as dumb as possible, and serve
all localized and customized resources from a server, which the client
always would connect to as the first thing when starting. This also
gives you the benefit of being able to update some aspects of the
application without installing a new apk. I think you are already
doing this in part, with the images and URLs for the featured
applications on the first menu screen of SAM(?). One drawback of doing
this for all resources is that you would have to implement your own
resource bundle manager, and can't use R.java lookups for localized
resources.

On the other hand...

For applications where you really need to create different apk's with
different resources, I would think the best way to set it up likely
depends on the number of combinations you require. In any case, I
would go for a setup which eliminates (or at least minimizes) source
code and resource duplication across modules. That would be through
having one module compiled to a jar which contains the actual
application source code, and one module for each different resource
package. Then either one of these alternatives for building the apk's
from that:

Either:
1. One module for each apk, which would depend on the source code jar
and the correct combination of resource packages required for that
apk.

2. OR, Only one module like above (not one for each apk), and instead
of depending on specific resource packages, it would depend on for
example a language package and a graphics package with ${parameters} $
{like} ${this} for groupids and artifactids. Then you could build that
pom a number of times, with the different required dependencies as
parameters for each. With Matrix build in Hudson, https://hudson.dev.java.net
, you could set that up to build lots of those combinations easily.

From what you just wrote about how unmanageable the combinations are
becoming, I would guess you are already doing something like
alternative number 1 above?

Any practical experiences from your work so far, or just thoughts on
building stuff like these, you would like to share with us?

/Hugo

[Shane Isbell]

My specific problem is a little more complicated than just resources. I have 6 different versions of SAM that I need to keep track of, based on target device, region and language. On some, the default strings.xml is different, as well as the AndroidManifest. Each of these generated apks will have a different release schedule and may include customized code (although most of it is core).

Likely what I will do is to create a branch for these six different versions off of the trunk and then merge over what I need for each releases. As I mentioned, the AndroidManifest,xml will have some modifications, as well as the default resource strings file. One approach I'm considering is to create something like:

|-- src
    `-- build-resources
        `-- resource-<device>-<region>-<language>
            `-- src
            `-- res
            AndroidManifest.xml
               

and then based on the device-region-language configuration have the appropriate project overlay copied over as part of the lifecycle. Since Maven 2.0.9, there is toolchain support (ok, not great support) so likely we can leverage that to setup these device-region-language params. This approach would allow me to keep a large part of the code and resources within trunk. Branching will allow me to keep a different release cycle per target, as well as code customization.

Shane