Donn

I previously posted about how you could make a free and lite version of your application using the Android Library project feature inside of Eclipse.

I set out to do this a few days ago with a client project that I had been working on. My development work flow went like this:

1. Build the entire app in one project first. All features.
2. Turn the said app into a library
3. Build out the Full and Lite shells
4. Crank out the Full and Lite versions as APK’s so I can get them on the Android Market.

The Problem

However, wen I got to part 3 I ran into an issue. The Android Project would not reference the Library. However, in the gen/ folder I could see that the R.java file was being generated by Eclipse with the resources from the referenced project. However, there was no referenced project icon and anytime I added anything to the ApplicationManifest.xml file Eclipse would complain that it could not find the class.

It seemed that Eclipse ‘knew’ about the project because it could build the R.java file, but could not fully find it. It was somewhere in Eclipse limbo.

Solution

After about 6 hours of trying various things I figured out what the issue was.

The problem: My projects in Eclipse had spaces in them (note, I’ve found that periods also cause a problem).

I changed the name of my projects to not have any spaces or punctuation in them. Such as “FooLibrary” instead of “Foo Library” or “Foo.Library”. Then I de-referenced the project, then referenced it again. It still would not show up. Sometimes restarting Eclipse can make everything “bind” again. Not sure why, but it seems to be a bug with the ADT plugin. Long story short, after restarting Eclipse, the referenced project was now available and working as it should.

Note, this is only the project name in Eclipse, not the Java package name.

Conclusion

Moral of the story – don’t use spaces, periods or any punctuation in your projects or libraries if you want to use Android Library Projects.

I wish the Android Documentation had a comment system so that I could post this there as it would have saved me 6 hours and a lot of frustration because spaces in the name of a project being the root cause is not too intuitive.

A full working code example of this post is located on my GitHub account here: http://github.com/donnfelker/FullAndLiteVersionSharedLibrary

I’m in the process of completing an Android app for a client and they needed the ability to have full and lite versions of the same application. The lite version would be free and the full version would be for a small fee (say, $2.99).

The Android Market stores applications based upon their unique Java package name. Therefore you cannot have multiple apps with the same package name. Therefore you’re left to do one of two things-

1. Create two Android projects and copy the code, altering/removing/etc whatever is needed for the Lite/Full Version.
2. Manually recompile and change the package name each time you want to release each version.

Either way its a real PITA. Which is why I’m writing this post. If you’re application requires Lite and Full versions (or more) then you’ll love this below.

Android Project Libraries

Android now has project libraries. This solves the problem of above. I now have the following package structure -

• com.example.myapp – Android Project Library - This is where my ENTIRE app lives. All the functionality for the FULL and LITE versions.
• com.example.myapp.full - Android Application Project - This is a shell that contains graphics and resources needed for the full version only. Basically it’s a super lightweight shell.
• com.example.myapp.lite - Android Application Project – This is another shell that contains nothing but graphics and resources needed for the lite version. Again, its a super lightweight shell.

How To Determine Lite vs. Full

In the com.example.myapp, I have an Application object that derives from the Android Application object. In this part of the app I check to see the package name contains the word “lite”. If so, then the app is running under a lite version. Here’s the code:

return getPackageName().toLowerCase().contains("lite");</pre>

Whats Happening Here? The library project takes on the package name of the project that is referencing it. Therefore at runtime, the package name equates to-

com.example.myapp.lite

Therefore I know that I’m running under the context of my LITE app. I can now disable/enable a feature based upon that knowledge.

Conclusion

While this may be a quick and simple approach, it works. Now, inside of my main library (com.example.myapp), I can sprinkle if statements all over the place to determine if the app is the full or lite version. That way I can share a common code base and not have to worry about maintaining different, yet similar code bases.

Downloads

Download a full working example here

I’ve been working by myself on all of my Android projects and just recently I need ed to expand my workforce to beyond that just myself. Therefore I needed to make my first hire for my company Agilevent. In doing so I needed to get my code over to another developers machine and I ran into all kinds of problems.

Background

The code is stored on GitHub in a private repository and the new developer had access. They had recently set up Eclipse and the ADT with Java 1.6. Everything was working golden. We could create a new project and everything worked fine. Except … when we tried to import the recently cloned GitHub project.

After importing Eclipse would report “Must Override a Superslass Method” on all kinds of methods all over the place (literally 86 different places in this one app).

Resolution

After a ton of futzing around we found the problem. Eclipse was defaulting to Java 1.5 for the imported project. I’m learning more and more and more about Java and its idiosyncrasies every day. In Java 1.5 classes can only be decorated with @Override when overriding a superclass method. In Java 1.6 if you have classes implementing interface methods you can decorate them with @Override and everything’s golden. You cant do that in 1.5. AKA: The source of the errors.

So where to change it?

Choose Window –> Preferences –> Java –> Compiler and ensure 1.6 is selected in the Compiler Compliance Level. If that is set and you still have problems, then in the same window, choose “Configure Project Specific Settings …”, choose the project in the chooser, and enable the project specific settings checkbox and select 1.6 in the Compiler Compliance level.

Fun times. Now if I could only get those two hours back …