Last year I rustled up an introductory article for C# programmers to get the hang of the then new Mono for Android. However the Mono for Android project then hit some bureaucratic snags and went on hold before getting new life.
Since then, the project has been flourishing and it seemed time to update the article to the current version, Mono for Android 4. The updated article is available on my web site.
For all those working in Android development you should head along to the new Android Design web site.
This new area on the Android developer's site gives the low down on how to design Android applications and looks at the various controls, common aspects of Android UIs, style, and much more. It’s been put together to help people get a handle on how to work with the new Ice Cream Sandwich (Android 4.0) release.
It makes useful and interesting reading!
Sometimes you try and launch your Android application from Oxygene for Java and nothing much happens. Sometimes you the application builds successfully and then nothing appears on the device. Sometimes you go to choose a target device to deploy to and none are listed. There are many of these sort of problems, which often have very simple solutions.
When building Android apps with any development tool, be it Oxygene for Java, C# and Mono for Android or Java and Eclipse, there are a lot of different tools trying to work together to produce the results you want. In the case of Oxygene for Java we have Microsoft’s Visual Studio, RemObjects’ Oxygene for Java compiler, Google’s Android SDK tools and Oracle’s Java tools. All different tools, of various versions from different software companies. Sometimes tools from different vendors don’t play well together.
For most of the problems I mention above i find the commonest cause is that the Android Debug Bridge (adb) daemon has gone ‘stale’. You can try a quick remedy by bringing up a command prompt and running these commands:
adb kill-server
adb start-server
Then try what you were trying before and see if that improves matters. Note that you’ll need the Android SDK’s platform-tools directory on your path to run the command without fully-qualifying the call to adb.exe.
If that doesn’t fix the problem then you should resort to the Android logs to see if there are any clues, for example, in the case of an application not installing on a device or emulator.
You can see the logs either by using:
adb –d logcat
or by running DDMS from the Android SDK and selecting the appropriate device.
During the attempt to install your app there will be log messages showing the progress and when the failure occurs you should see some sort of error message and maybe a call stack to assist working out what’s wrong.
Additionally, if you install your app from the command-line (as opposed to your IDE) you will often see an error code printed, which you can look for advice on with an Internet search. The error code is the name of a static field from the PackageManager class, albeit one that won’t be listed in the Android SDK documentation You can, however, find them in the Android source.
A command-line install looks like this
adb –d install –r mypackage.apk
The –r switch requests a reinstall, which preserves app data such as databases. If that is not important, skip the –r from the command.
For example, if you messed up the details of a certificate the app was signed with, you might get this:
Failure [INSTALL_PARSE_FAILED_NO_CERTIFICATES]
or perhaps this:
Failure [INSTALL_PARSE_FAILED_INCONSISTENT_CERTIFICATES]
Searching the Internet will tell you that during the package manager’s verification process it couldn’t verify your package was suitably signed – perhaps because the certificate was in error, or maybe because you are using JDK 7 and haven’t worked out how to work with it’s set of new default values that affect harmonious Android development (I’ve written about this issue as it cropped up in this article).
Sometimes a small change in the application, like updating the package name or altering the signing process (i.e. changing the package’s signature), will mean an application can’t be re-installed over a previous version.
Failure [INSTALL_FAILED_UPDATE_INCOMPATIBLE]
You can easily deal with this by forcibly uninstalling the prior version, again using adb. If your app’s package is called org.me.myapp and is on a physical device, you’d use:
adb –d uninstall org.me.myapp
Change the -d switch to a -e if using an emulator instead.
I’ve been quite surprised how many times rather annoying issues have been deftly resolved by simply restarting the adb daemon, or uninstalling an old version of an app that was ‘getting in the way’ of a new version being installable.
One other point to mention before ending is that DDMS is a great log viewing tool, but it acts as a debugger. If you have it running and then try to launch an application for debugging from Oxygene for Java, you won’t get very far as DDMS will already have set itself up as the primary debugger. To debug, you must first close DDMS, which isn’t a great loss – the Oxygene debugger does have a logcat window that shows the same logging information as DDMS does.
When I was working out how to use the Google Map control on Android devices i found it a little daunting with all the information scattered around the web, often missing out crucial points and almost never mentioning the impact that Java 7 has on things….
So I thought it best to write all my findings up in a detailed article on the matter from the viewpoint of an Oxygene for Java developer – it turned out to be much longer than I was expecting! You can find the article on my web site as Using the Google MapView in Android with Oxygene for Java.
I hope you find it useful – it represents quite a long time spent researching and fiddling and testing things out!
Over the last 16 years verity Stob has brought forth occasional Old Testament stories about the Sons of Kahn – wryly observant treatises on the comings and goings of those who were at Borland and work with the Delphi compiler.
It’s with delight I’ve learned that she’s back with the eighth instalment, The Sons of Kahn and the Pascal Spring, which can be read on The Register.
For those interested, here is a complete list of Verity’s Old Testament books, one of which has been lost in time and is only accessible through the Internet’s Way Back When machine:
[Edit: I’ve added the latest instalment from 11th December 2012 to the list]
When I first started looking at the Android SDK I quickly realised that events were set up differently to the frameworks I had worked with before. Instead of being defined as closures, or method pointers, event fields are defined using interface types. To handle an event you need to implement the interface in some class.
In Java this is done using some syntactic sugar that gets the compiler to implement the interface in an anonymous helper class. When working with the Oxygene language we also need this syntactic sugar to avoid degenerating into a mess of unwieldy code, hence the introduction of inline interface implementation.
There are various ways of using inline interface implementation and a couple of other options for implementing events, so I’ve written up a short article illustrating the primary options available for those using Oxygene for Java called Android event handling & inline interface implementation with Oxygene for Java. If interested in following up on this, you can find the article here on my web site.
In Autumn 2011 I was approached by Nail Soup Ltd. about an Android development opportunity. Nail Soup had a client, a charitable organisation called Amber Foundation, who wanted some mobile applications built. Primarily they wanted to offer a free iPhone and Android app that would allow people to search for various types of resources to help homeless people in the UK. This was to be called the Amber Homeless Helper and was set to be released shortly before Christmas 2011.
The idea was to have a web-resident database sat behind a web service that could be queried with various different search criteria to get resources around a specified location. Nail Soup were happily building the web service, a web front end and also the iPhone app, and they asked me to build the equivalent Android application. Since at the time it was very close to the release of Oxygene for Java I chose that as the development tool for the job.
The app was completed and published for the target release date of 19th December 2011 and the iPhone and Android versions are in the Apple App Store and the Android Market respectively, though they are only visible to people in the UK since they are providing UK-specific resources.
Amber Homeless Helper is the first published app built with Oxygene for Java and was fun to do. It’s not the most complex application, primarily being a search tool with some additional information and the ability to contact Amber and donate to the charity, as well as look at previous archived search results but involved a number of technically interesting aspects of Android development. Additionally it acted as a good test of the initial 1.0 release of Oxygene for Java finding a couple of rough edges that were quickly addressed by the developers at RemObjects.
This post is intended to give an overview of what areas of Android programming were involved in getting the Amber Homeless Helper to its finished state, operating as the design dictated.
Over the holiday period i spent some time knocking up an introductory article that looks at getting Oxygene for Java set up for Android development, looking at an overview of how Android apps work and how an Android project is laid out, and getting a simple app up and running on an Android device or emulator.
You can find the article on my web site at http://blong.com/Articles/OxygeneForJavaIntro/OxygeneForAndroid.htm.
