Building Blocks

So I’ve done my first programming for Android phones and thought I’d write a blog post about the experience.

Programming for Android is a bit different from working with the Compact Framework. The abstraction level for the Dalvik applications is somehow high than the Compact Framework application. One difference for example is that there is no main() method to start your application from.

Central for an Android application is its Android Manifest file. This file describes all services and activities available in the application. This is an XML file that helps describe your application to Android, what it’s capabilities are. Each Activity can then be used as an Entry point, but the manifest also describes Services, Content Providers and Broadcast receivers.

What this gives you is a set of loosely coupled components that interact with each other using Intents, that are passed on a system wide message bus. This allows applications interact not only with central parts of the phone, but also with other applications. Which is quite interesting.

Developing in this manner gives you a set of conventions to follow. I feel that they have managed to find a set of conventions that gives direction in the design of the application, but doesn’t confine you.

The SDK also gives you a set of base classes (template method pattern style base classes) that helps you develop common tasks in a standardized way. An example of these are the Task classes that provide threading and scheduling support. I quickly fell in love the the AsyncTask for example.

Android protects the foreground UI thread quite extensively, making these constructs for doing background work important. For example your not allowed to construct or access any UI elements on background threads. This can be handled by using a special Looper construct that effectively divides your Thread code into different parts. One setup part that’s allowed to access, or setup UI components. And one Loop part that does the actual work.

I worked mainly in the Emulator. The emulator feels fast at first, it takes a while to boot up but is quite responsive once booted. That is until you start typing using the computers keyboard. When you do this the emulator feels slow. Apart from a few issues with the emulator loosing “internet connectivity” when my computer Hibernated.

Now it’s time to mention a tool that’s quite helpful when working with Android applications. It’s the adb.exe logcat tool available in the Android SDK. This tool allows you to watch the result of log statements in runtime, and shows stack traces for those errors the occur but you’ve partially managed to take care of (ignored).

This being said there are some things I’m missing when comparing to working with the Compact Framework. For example, working with XML is much easier in the Compact Framework. I hate having to write my own parsing and serialization code, and there are more tools to help me generate code for doing this in the .Net framework.

Also using the HttpClient in the Android SDK is unnecessarily hard. Https works only with some special glue code. And as far as I can tell everyone seems to simply accept any certificate instead of providing support for showing a UI where the user can accept an unknown (self-signed) certificate.

This is all I can think of right now (this is the second time of writing since I had a crash when I tried to post it…). If there are any questions, please ask them. Hopefully they’ll help generate more knowledge about Android development.

I just added a Cron job to “ping” my application every 1 minute. After a short discussion with Paul Cusch, whom commented on one of my previous posts regarding the load request issues Grails on AppEngine is seeing. I decided to give it a try. This solution is entirely based on Paul’s idea I’m just writing it up.

Grails AppEngine plugin is missing a feature to use cron out of the box. I hope to submit a patch for it. This is how it works. You need to have a cron.xml file next to your appengine-web.xml file. In the cron file you describe which url and how often a GET operation should be done on the specified url.

Details can be found here.

I simply added a request to a specified url, which I added to my URL mapping:

"/today"(controller: "user", action = "ping")

Then added a cron file to ping it every minute:

<?xml version="1.0" encoding="UTF-8"?>
<cronentries>
    <cron>
        <url>/today</url>
        <description>Keep the app alive by ping every 1 minutes</description>
        <schedule>every 1 minutes</schedule>
    </cron>
</cronentries>

The cron.xml file I keep in my grails-app/conf directory, following the conventions used by the AppEngine plugin, for similar files.

The user controller unfortunately got the honor for hosting the ping request.

def ping = {
  render "ping ${new Date().toString()}"
}

And there it is. Next time that application is uploaded to the AppEngine, the ping method on the user controller will be executed every 1 minute. Helping to keep the application loaded.

This method comes with a few drawbacks however. The application will still hit loading requests every now and then, and those requests will take from your quota. This setup can easily eat up all your free quota.

Also, if everyone sets up this cron job. Then a lot of quota is wasted in general, which might affect the service for other applications. This workaround tries to fix a problem that should be fixed in the inner workings of AppEngine it self (not excluding changes to Grails initialization).

There is however a query that is ongoing. Google is considering the possibility to allow people to pay for keeping their application in memory. If you would consider such an option then star the this issue. I myself starred it, I think it’s quite acceptable.

I turned the cron loading task off in my application, instead seeing it as an experiment with Cron on Google AppEngine. The payoff for this solution wasn’t that great and for me it comes with the expense of some of my code quality.

In the 1.2.8 version of the AppEngine SDK there is an option to precompile your solution as you deploy it to the AppEngine. Apparently precompilation can save up to 30% runtime on loading requests.

I added the option to turn on the precompilation-enabled setting in appengine-web.xml to the AppEngine plug-in this morning. Hopefully I can submit a patch with change, I’ll get back to that in a bit.

As I’m writing this I’m deploying to AppEngine for the first time. What happens is that during the deployment to Google AppEngine, the appcfg.cmd compiles the solution locally.

Showing the following lines in the input:

37% Cloned 600 files.
40% Uploading 4 files.
52% Uploaded 1 files.
61% Uploaded 2 files.
68% Uploaded 3 files.
73% Uploaded 4 files.
77% Precompiling.
80% Precompiling. 174 files left.
82% Precompiling. 94 files left.
84% Precompiling. 22 files left.
90% Deploying new version.

Now it’s deployed, I’m going to let it run for a while while I fix something else.

I have Pingdom set up for checking the AppEngine project every minute. That way I can see the changes in response time, and from the dashboard I can see if the CPU use goes down.

As far as I can tell, the precompilation doesn’t help with the timeout issues when starting a grails application hosted on AppEngine, it might help, but it doesn’t affect the loading time noticeably. However I for one am going to have my application precompiled.

This SDK release makes Morten (that would be me) a happy camper. Now I have something to do when I get home from work!

Release information

http://googleappengine.blogspot.com/2009/12/app-engine-sdk-130-released-including.html

Why am I looking forward to this? It’s the first time I see a mention of performance updates for dynamic languages in AppEngine. I’m upgrading later to night to see what my actual performance boost is.

The blob service is also a welcomed scenario. We’re using something similar in our REST-API in RemoteX Applications.

If you use the app-engine plug-in deploy command using AppEngine SDK version 1.2.8 it will fail with the following error:

[java] Bad argument: email requires an argument, for example, "email=FOO"
[java] usage: AppCfg [options] <action> <app-dir> [<output-file>]
[java] Action must be one of:
[java]   help: Print help for a specific action.
[java]   request_logs: Write request logs in Apache common log format.
…
[java]                         request logs are returned.
[java]   -n NUM_RUNS, --num_runs=NUM_RUNS
[java]                         Number of scheduled execution times to compute
[java] Java Result: 1

Google changed so deployment is targeting a directory instead of a war file.

What you need to do to deploy is instead to use the AppEngine built in command to deploy

%APPENGINE_HOME%/bin/appcfg.cmd update c:\users\morten\.grails\1.2.0.RC1\projects\<projectname>\stage

After this all I had to do was to update my deployment scripts, and the stage is set for some serious Grailsing.

I should point out that all previous workarounds for working on Windows still need to be in place.

Google just announced their attack plan for handling the long startup cost for, among others, Grails applications.

Apparently what I can do as a developer is to enable pre-compilation of my application. I’ll experiment with this at the end of the week I hope.

Read the full post on the AppEngine blog

As far as I can see there is no mention of startup performance. Doesn’t have to mean they haven’t worked on it. Ill check it out to night to see how the application behaves.

I got this on twitter last night. Google is doing a prerelease of the next AppEngine SDK.

Details can be found here:

http://groups.google.com/group/google-appengine-java/browse_thread/thread/fe334c9e461026fa

Only thing that worries me is that there is no mention of application startup times.

Regarding the logging issue with Grails and Google AppEngine, I’ve just installed the latest build of Grails1.2 and deployed to AppEngine, and it works.

No change to the loading time of grails however, I’m still getting timeouts on my initial requests.

The issue with the AppEngine enhancer still exists with Windows 7. Let’s hope for the next version of Windows then…