a+bi

Android’s developer guide has a section on Developing in other IDEs for those who don’t want to use Eclipse. However the documentation leaves out a few details and all of the examples use Eclipse with perhaps a token paragraph discussing the CLI. The rest of this post will assume that you have already installed the SDK and properly configured it (added the SDK to your path and installed the appropriate SDK components).

The first thing to do is to figure out which version of Android you want to target. Version 1.6 (aka – “Donut”) is a pretty good lowest-common-denominator. Using the Android tool we will figure out the ID for 1.6:

niki@redblacktree:~$ android list targets

Which will give you a list of all the targets available (this depends on which SDK components you have added). My output looks like this:

Available Android targets:
id: 1 or "android-3"
Name: Android 1.5
Type: Platform
API level: 3
Revision: 1
Skins: QVGA-L, QVGA-P, HVGA (default), HVGA-P, HVGA-L
id: 2 or "android-4"
Name: Android 1.6
Type: Platform
API level: 4
Revision: 1
Skins: WVGA854, QVGA, HVGA (default), WVGA800
id: 3 or "android-7"
Name: Android 2.1
Type: Platform
API level: 7
Revision: 1
Skins: WVGA854, WQVGA400, QVGA, HVGA (default), WVGA800, WQVGA432

The target ID for version 1.6 is 2. Knowing that, let’s set up an Android Virtual Device (AVD) for our emulator using the android tool, specifying the target with the –target option and giving it a name with the –name option. We will use the default hardware configuration:

niki@redblacktree:~$ android create avd --name donut
Android 1.6 is a basic Android platform.
Do you wish to create a custom hardware profile [no]
Created AVD 'test' based on Android 1.6, with the following hardware config:
hw.lcd.density=160


Finally, let’s setup a project. Again well use the android tool, this time to create a new project. I’m going to create the project in the directory ~/projects/android/hello:

niki@redblacktree:~/projects/android/hello$ android create project --name HelloAndroid --activity HelloAndroid --path ./ --package com.examples.helloandroid --target 2

This will create a new project in the current directory (–path ./) with the name “HelloAndroid” (–name HelloAndroid). It will be targeted towards Android 1.6 (–target 2). It will create a Java source file containing an Activity “HelloAndroid” (–activity HelloAndroid) and will be in the namespace “com.examples.helloandroid” (–package com.examples.helloandroid).

We can now use Apache Ant to build our project:

niki@redblacktree:~/projects/android/hello$ ant debug

This will build a debug version of our project and place the “HelloAndroid-debug.apk” in the bin directory. This application has been signed using a default debug key and is ready to be installed on a device. To do that, let’s fire up the emulator, using the virtual device we created earlier:

niki@redblacktree:~$ emulator -avd donut

Once the emulator has finished booting, we can get a list of attached devices using the Android Debug Bridge or adb:

niki@redblacktree:~/projects/android/hello$ adb devices
List of devices attached
emulator-5554 device


If there is only one device attached, then you can install the application using ant:

niki@redblacktree:~/projects/android/hello$ ant install

Which will automatically remove any previous versions installed on the device and install the current build. Alternatively you can use adb to install the application:

niki@redblacktree:~/projects/android/hello$ adb install bin/HelloAndroid-debug.apk

This will fail, however, if you have already installed a previous version of the application on the device. If that is the case, you need to uninstall it first:

niki@redblacktree:~/projects/android/hello$ adb uninstall com.examples.helloandroid

Note that you must specify the application by the name of its package.

Finally if you have more than one device attached, (say, a phone and an emulator) then you must specify which device (using the name returned from adb devices) using -s:

niki@redblacktree:~/projects/android/hello$ adb -s emulator-5554 install bin/HelloAndroid-debug.apk

Now you can just navigate to the application on the emulator or on your phone and run it! You’ll notice by default it says “Hello World, HelloAndroid!”

That’s the basics of setting up, building and running an application using the CLI instead of eclipse. In the next post I’ll go over release builds and signing your applications.

I have owned an Android-based phone (the G1) for awhile now and have been meaning to develop applications for it since day one. I have finally gotten around to learning how. So far it hasn’t been easy for me: I don’t know Java and I don’t use Eclipse which are the primary development tools for Android.

Fortunately Google released the Android NDK, or Native Development Kit which can be used to program applications in C or C++ and be compiled for the ARM architecture. This introduces new complexities however. The NDK still requires some Java as the compiled code is executed using JNI. In other words I still need to learn a minimal amount of Java and learn how to interface it with native code.

Finally, most of the information online assumes the use of Eclipse. Google provides some tools for creating ant build files but I have found the documentation to be lacking a bit. Through some trial and error I have figured out how to compile the NDK samples and in my next post will present a tutorial for doing so.

Topics so far:
* Creating an Android project from the Command Line
* Signing Android applications

After becoming increasingly fed up with Ubuntu I decided to reinstall Debian. I had used Debian for a number of years but eventually left it in favor of Ubuntu as I initially saw Ubuntu as Debian with more complete repositories. At first Ubuntu was quite promising however as I diverged from the default install I became annoyed at some of the idiosyncrasies of the system. After attempting to upgrade from Hardy to Intrepid (which requires a graphical installer – and all the directions/tutorials I found online assume you are using gnome/xfce/kde) I realized that what I really wanted was Debian with some additional external repositories.

In the process of setting up my system I decided to update dwm to the latest version (5.6.1). There have been some significant changes to dwm since 5.2 including better multi-head support. Even though I’m not currently using a multi-head system the changes affected my patches and they needed updating. The new diff files can be found on the dwm projects page.

I have added a new project to the projects page: Prime number storage. When I was in college a friend of mine and I came up with a method for compressing and storing prime numbers. While doing research on our method we discovered that it was already in use.

However I recently decided to implement it anyway, as it was (and still is) interesting to me.

Most of the code that I’ve written in the past few years has been closed-source, proprietary code for my employer. As such I have very little publicly available code to show other people. A few months ago I decided to start working on that by implementing some of the more interesting data structures that I’ve read about. The ultimate goal was to create a Fibonacci heap, which I’ve been meaning to do since I completed the final project for my algorithms class in college. We had to implement Dijkstra’s algorithm on the NYC subway system and a Fibonacci heap can lower the asymptotic bound on the running time.

I started with a Red-black tree as that is a pretty classic and oft-used data structure. Perhaps this endeavor was a little pointless as Red-black trees are usually the data structure used to implement the STL map. In a sense this was both the most useful (because of the frequency with which I use the map container) and the least useful (because it’s already available).

I then implemented two different heaps: a binomial heap and a Fibonacci heap. A binomial heap improves the running time of merging two heaps together (and uses this fact to implement most other operations using the merge) and a Fibonacci heap improves the running time of the decrease key operation – an operation that is frequently used in Dijkstra’s algorithm as well as many other graph algorithms.

The code isn’t as nice as I’d like (there is some debugging code left in, for example) but it was a good exercise and greatly took advantage of template meta-programming in C++.

The project page is here.

I participated in the Global Game Jam with my co-worker Chris a little over a month ago. It was held at the Columbia Teacher’s College. Shortly after we arrived there was a brief introduction to the insanity to come, including a video from the guys that created World of Goo, meant to inspire us (and offering up some sound advice on how to create a game in such a short period of time). We were then given a list of design requirements. The theme of the game was “As long as we have each other, we will never run out of problems.” The game had to be completely playable in five minutes. It also needed to include one of the following adjectives: pointed, persistent or illusory.

After the orientation there was a mingling period where we were able to meet the other participants and form groups. To my relief there was a fair balance of students/enthusiasts and professionals, as well as a healthy mix of programmers, artists and designers. I was afraid that this event would attract too few programmers to be viable but my fears were completely unjustified.

Chris and I decided to stick together, and we eventually found a group of six people to work with, with a seventh on the way. Most were professionals in some capacity although aside from me and Chris, only one other worked in the video game industry. However we quickly realized that seven people was too many, as creative differences and [programming] language barriers were getting in the way. Eventually we split into two groups – our group consisting of four members and another group with three. Our group then split further, with one team member amicably leaving to join another group over creative differences. When we finally resolved the team formation issues there were three of us: me, Chris and Stefan – a Full Sail graduate.

We began designing the game. While we all had similar and complementary ideas we had a lot of trouble coming up with a cohesive design. Eventually we had a rough idea of some basic elements (using time travel to meet the five minute requirement, make a 2D game) and decided to start implementing the basics. I set up a Subversion repository and Stefan and I started coding while Chris dealt with the assets. We used C++ with SDL as our graphics/sound/input library. We ended up using two different compilers (Stefan used Visual C++ while I used gcc) which surprising did not cause any major problems. I worked on the time travel mechanics while Stefan worked on collision detection.

Once we had a code and asset base we went back to design. We ended up dropping the time travel mechanic and using elements of point-and-click adventure games (only with the pointing and clicking – we used the keyboard for input). We created almost a parody of adventure games – showing the consequences of entering someone’s house and looting it (a device all too common in the genre). In the end we had a dark, bleak story of a man who had lost touch with reality and with the one he loved.

With the design finally complete and only a few hours left we got back to implementing the game. By the time the deadline struck we had a fairly presentable (although very incomplete) game. We were awarded “most innovative UI.”

You can download the game and all the source code here, the official game jam website for our game is here.

I have added two more projects to my projects page, both of which come from the dark ages. The dark ages is back when I knew nothing about programming and considered myself to be a great programmer. The Dunning-Kruger effect I suppose. I look back at this code now and shudder, I’m sure that you could post it to The Daily WTF and it would fit right in.

But who doesn’t have some code that they were once proud of and are now ashamed of? That’s all part of growth and learning. I decided to put these projects online for posterity and to remind myself of how far I’ve come and [hopefully] how far I’ll go. With that preamble out of the way, the projects I posted are:

The Mandelbrot set – I wrote this when I was in high school, using the Windows API. The code actually isn’t that bad, aside from some silly code-repetition. Overall it was a pretty simple project with a lot of boiler-plate code so there was little room for my naivety to get in the way.

Robotic Motion Planning – I wrote this in college for my Computational Geometry class. I of course left this to the last minute and coded the entire thing in about a week, getting very little sleep during that time. Given the complexity of it and the extremely tight schedule it’s not that surprising it turned out the way it did. It’s extremely buggy (in fact, I can’t get it to run anymore!) and missing features. I never got around to actually calculating the path of the robot.

I have a few other old projects lying around, mostly from college. If I get a chance I’ll add those to the Dark Ages section of my projects page as well.

Last night I added a Projects page and added two projects: my OCaml code and DWM patches mentioned in the previous post.

Over the past couple of days I managed to fix a couple of bugs in the OCaml code and add a Perl script to generate some information that can be used as input to the OCaml program. Tupper’s self-referential formula is a formula that can graph a monochromatic bitmap. The self-referential part refers to Tupper using it to graph a bitmap that looks like the formula itself. You can check out the projects page for more information on what the software actually does (and check Wikipedia for more information on the formula). The rest of this post is going to be about the code.

Tupper's formula contains an exponent that is negative for most values of (x, y). A negative exponent of course results in the multiplicative inverse of the expression with a positive exponent. Since the OCaml Big_int module only supported positive exponents I simply negated the exponent (thus making it positive) and then inverted the result.

This worked fine for every case except when x was equal to zero, so initially I just skipped that case to prevent run-time errors. Eventually I realized that when x was zero the exponent was positive and since I was negating it, it ended up negative. The Big_int library then threw an exception.

I added in a check to test the sign of the exponent and to do the calculations with the absolute value. Then, depending on the sign, I would either multiply or divide (use the inverse). To do this I curried either the multiplication or division function and used the curried function for the rest of the calculations.

After that it rendered the image properly. I then went about generalizing the formula (and my code) so that it could support any monochromatic bitmap, not just the self-referential bitmap.

Tupper’s version of the formula is restricted to a bitmap that is 17 pixels high. There really isn’t a way to generalize the formula to accept any size bitmap unfortunately, but it’s easy enough to change the formula to accept a specific size. This of course makes it easy to generalize the code.

Finally I wrote a Perl script that will take an image and convert it to that magic number (the special integer representation of the bitmap).