Android Development Part 1 – Choosing the right project structure

I’ve been doing some android development now for a little over 4 months, and I thought I’d try to convey my lessons learnt while both celebrating my successes, and bashing my head on my not so grandest moments. I’ll attempt to break my journey into a few blog posts which will talk about project setup, all they way through to choosing the right frameowkrs, and deployment of the app.

So to start, lets talk about how to structure your project. I’ve used eclipse to develop my android goodness, and I’ve found it to suffice for what I need – although I am pretty tempted these days to IntelliJ, but thats a story for another blog post! 🙂

The best way I found to structure my project, was to use maven. Honestly, I could have just stuck with the standard project that comes with the android SDK, but there’s something that really erks me about not describing my dependiencies in a POM file! This also makes me feel a little more cosier inside for when I eventually try and set the beast up to run a Jenkins build!

OK, so we’ve established that we need to use Maven. Thats great, but how do I go about trying to structure where my files go, and what about the nice feature in eclipse that allows me to build my android project, and even deploy it?! Well, here comes the neat little plugin called : maven-android-plugin This is a fantastic little maven plugin to help you build you project, and to help you along, below is a xml snippet of what it would look like configured in your pom:

<dependencies>
	<dependency>
		<groupId>com.google.android</groupId>
		<artifactId>android</artifactId>
		<version>2.2.1</version>
		<scope>provided</scope>
	</dependency>
</dependencies>
<!-- Other config ommited for brevity -->
<build>
<plugins>
	<plugin>
		<groupId>com.jayway.maven.plugins.android.generation2</groupId>
		<artifactId>maven-android-plugin</artifactId>
		<version>2.9.0-SNAPSHOT</version> <!-- 2.8.4 -->
		<configuration>
			<sdk>
				<path>${env.ANDROID_HOME}</path>
				<!-- platform or api level (api level 4 = platform 1.6)-->
				<platform>8</platform>
			</sdk>
			<device><!-- Insert the device ID here if you want to deploy to an actual device --></device>
			<!--  emulator>emulator_name</emulator -->
			<deleteConflictingFiles>true</deleteConflictingFiles>
			<undeployBeforeDeploy>true</undeployBeforeDeploy>
			<coreLibrary>true</coreLibrary>
		</configuration>
		<extensions>true</extensions>
	</plugin>
</plugins>
</build>

One thing worth mentioning here, is the version of the maven-android-plugin I’m using. Its actually my own rolled version which I forked from the github repo because I needed to fix a bug. The bug fix has been included into the currently 3.0.0-alpha-1 release. You can read about it here. I haven’t yet updated to the 3.0.0-alpha-1 version, because I haven’t had time yet to make sure everything still works. I can’t see anything majorly wrong with using this version for now, but do be warned.. it is an alpha after all!

With that started, I’ll be writing next about some really cool frameworks there are for the android platform, that could easily cut down on the amount of code you’d have to write!

Till next time…

Maven android plugin, “–core-library” option not quite working

I’ve recently been working on building some android based applications now for the passed 3 or so months, and its been a fantastic journey so far. However, there have been times where I’ve found I talk to myself quite a bit, and for most part, I find myself muttering “what the heck is that supposed to mean?!”

This was one such occasion. I use maven for building my android project, but I had recently started using Springs RestTemplate, and there were a few libraries that I had to import while attempting to build REST based communications.

One thing that caught me off-guard, was, that when I came to build the project, I was now presented with a number of errors, all with the same sort of warning which read as:

[INFO] [android:dex {execution: default-dex}]
[INFO] C:\Program Files\Java\jdk1.6.0_20\jre\bin\java [-jar, C:\Program Files (x86)\Android\android-sdk-windows\platform-tools\lib\dx.jar, –dex, –output=C:\dev\android-sample\target\classes.dex, C:\dev\android-sample\target\android-classes]
[INFO]
[INFO] trouble processing “javax/xml/bind/annotation/adapters/CollapsedStringAdapter.class”:
[INFO]
[INFO] Ill-advised or mistaken usage of a core class (java.* or javax.*)
[INFO] when not building a core library.
[INFO]
[INFO] This is often due to inadvertently including a core library file
[INFO] in your application’s project, when using an IDE (such as
[INFO] Eclipse). If you are sure you’re not intentionally defining a
[INFO] core class, then this is the most likely explanation of what’s
[INFO] going on.
[INFO]
[INFO] However, you might actually be trying to define a class in a core
[INFO] namespace, the source of which you may have taken, for example,
[INFO] from a non-Android virtual machine project. This will most
[INFO] assuredly not work. At a minimum, it jeopardizes the
[INFO] compatibility of your app with future versions of the platform.
[INFO] It is also often of questionable legality.
[INFO]
[INFO] If you really intend to build a core library — which is only
[INFO] appropriate as part of creating a full virtual machine
[INFO] distribution, as opposed to compiling an application — then use
[INFO] the “–core-library” option to suppress this error message.
[INFO]
[INFO] If you go ahead and use “–core-library” but are in fact
[INFO] building an application, then be forewarned that your application
[INFO] will still fail to build or run, at some point. Please be
[INFO] prepared for angry customers who find, for example, that your
[INFO] application ceases to function once they upgrade their operating
[INFO] system. You will be to blame for this problem.
[INFO]
[INFO] If you are legitimately using some code that happens to be in a
[INFO] core package, then the easiest safe alternative you have is to
[INFO] repackage that code. That is, move the classes in question into
[INFO] your own package namespace. This means that they will never be in
[INFO] conflict with core system classes. JarJar is a tool that may help
[INFO] you in this endeavor. If you find that you cannot do this, then
[INFO] that is an indication that the path you are on will ultimately
[INFO] lead to pain, suffering, grief, and lamentation.
[INFO]
[INFO] 1 error; aborting
[INFO] ————————————————————————
[ERROR] BUILD ERROR
[INFO] ————————————————————————
[INFO]

Now that’s a pretty scary error to have, and on subsequent investigation, it seems like some marshalling libraries I’ve imported have the same namespace as some included java namespaces. Not to worry, I trust that the developers of this marshalling library know what they’re doing, so I just want it to build. But alas, following the instructions to use the –core-library option, the maven-android-plugin still refuses to build, and you just get back the same build error message.

I then found this nice bug report, which detailed pretty much everything I was experiencing – thank you to whoever you might be! So I thought the least I could do was fix the bug, if it was so well logged!

It turns out that the maven-android-plugin had a small bug in it, where the order of the options weren’t quite 100%. The GitHub pull request is here, and it has been accepted, so I assume it will be available in the next release.

I hope this helps anyone else out there experiencing this problem.