Opgenorth.NET

I just uploaded an update to HistoricalBuildings.  The list of historical buildings used to be sorted alphabetically, by name.  Now they are sorted by the distance from your current location (assuming the GPS can figure that out).

Well, for the brave, criminally insane, curious, or otherwise bored I have a alpha version of Historical Buildings – download the APK if you want to try it out.  This is just, at this time, the application just shows a simple list of historical buildings in Edmonton (according to the City of Edmonton’s Open Data Catalogue).  Click on a building, and it will show you on Google Maps where the building is in the city.  The code for this is, in my opinion (and to say the least) – rough.  But it is a start.  Definitely needs some improvement.  Or maybe I just need to change my thinking to more of a Android/Java mindset.  Anyway the usual caveats apply:  use at your own risk / batteries not include / do not eat / void where prohibited by law, etc, etc, etc

Anyway, if you use it let me know.  There are bound to be bugs, but hey it “Works for me!”.  Time to work on some other stuff for it.  I think the next neat thing is would be to show the closest building to you.  Either that, or handle some of the seedy code issues and infrastructure stuff that bugs me. 

Thanks to the MapView, it’s drop dead easy to put Google Maps into your application.  There are lots of posts out there how to do it.  Interestingly (to me anyway), when I did a quick search of the Android developers mailing list, I was surprised to see that a lot of people had the same problem:  basically, when you look at your MapView, you end up with a grid of white squares.  It kind of sucks.  There are a lot of blog posts and articles out there on how to fix this problem, but this one is for me, and to help me remember it.

The trick to fixing this is setting your Google Maps API key.  Note the layout below:

   1: <?xml version="1.0" encoding="utf-8"?>

   2: <RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"

   3:     android:id="@+id/mainlayout"

   4:     android:orientation="vertical"

   5:     android:layout_width="fill_parent"

   6:     android:layout_height="fill_parent" >

   7:

   8:     <com.google.android.maps.MapView

   9:         android:id="@+id/mapview"

  10:         android:layout_width="fill_parent"

  11:         android:layout_height="fill_parent"

  12:         android:clickable="true"

  13:         android:apiKey="Your Maps API Key"

  14:     />

  15:

  16: </RelativeLayout>

In particular, pay attention to line #13.  What you have to do is create a Google Maps API key, and then paste it in there.  That’s simple.  How do you do that?  Well it’s simple too, but not as simple as it could be.  The first thing you need to do is to sign your application.  This isn’t a big deal, you have to sign your application before you can publish it anyway.  Android will NOT install an application otherwise.

So, it seems we have two steps here:

1. Sign your application
2. Use your signed application to get a Google Maps apiKey.

Generate a private key.  Keep this safer, as if it were the Holy Grail.  Lose this, and as far as the public is concerned, you’re locked out from your own application – you will not be able to update it.  The image below will show you the steps to go through

"C:\Program Files (x86)\Java\jdk1.6.0_19\bin\keytool" -genkey -v -keystore my-release-key.keystore -alias alias_name -keyalg RSA -validity 10000

Once you have that done, build your application (in release mode).  I leave this as an exercise for the reader.

Now that you have your application built, you need to sign it.  This is where jarsigner comes in:

And the final step is to zipalign your  APK.  You have to do zipalign last.  Basically, you do zipalign for performance reasons.  If you want to know more, RTFM.

C:\android-sdk-windows\tools\zipalign -v 4 HistoricalBuildings-unalign.apk HistoricalBuildings.apk

Now, of course, both Eclipse and IntelliJ will handle these steps for you.  But where is the fun in that?

Yeah, I’ve been kind of quiet as of late.  So quiet, I suspect that some people might be wondering if something happened.  I was a bit surprised to see that the last time I had blogged was after TechDays in Calgary.  Well, nothing significant has happened – just a bit of laziness augmented by a touch of tech-burnout compounded by the odd bit of single malt scotch.

So, now that one month is almost up on 2010, I figured that it was time to start blogging about something again.  The first trick to this, of course, was to figure out what I wanted to do in 2010.  It does seem like there will be a lot of interesting things, technically speaking, coming up this year.

A couple of new things I want to look at over the remaining 11 months:

Mobile development, particularly with a focus on Android.  For the latter half of 2009 I have been dabbling in Android.  I believe that it’s time to go out on a bender, and in a drunken stupor get some embarrassing tattoo and join the Android Army.  So far, I’m at two out of three.  Not bad, huh?

Ruby is another technology I’d like to explore – particularly Rails.  I can help but think that the opinionated view that Rails development has taken is the way to go for the bulk of web development.  A lot of websites are basically just forms over data, and Rails seems to address that concern rather well.  To bad nobody around here in Edmonton does much Rails development.

.NET 4.0 and ASP.NET MVC2.  I know there is a lot of debate between Web Forms and ASP.NET MVC.  Personally, I think MVC is the better way.  Probably best to keep abreast of what is going on in the ASP.NET MVC world.  And, of course, the DLR in .NET will come to maturity soon.  By maturity I mean widespread acceptance.  If this happens, then maybe developers won’t get so hung up on languages:  i.e. “I’m a C# guy so VB.NET sucks”.

And finally, a guy needs hobbies.  Now granted, my past hobbies of alcohol and guns (no, not together at the same time) have served me well for the past 20 years or so. However, they are hard hobbies to share with my sons at this point in time.  So, at the start of winter I expanded the geek factor of my sons (and myself) by getting back into Warhammer.  Now the last time I played was about 20 years ago, with the 3rd edition rules.  In fact, I still have some of the books in my basement from back then.  Anyway, picked up The Battle for Skull Pass boxed set.  My son rather likes the Dwarfs.  I suspect it’s because he’s similar in stature/height to the stunties.  Myself, while I find the Greenskins amusing, I suspect I might have to move on and get serious with Dark Elves.

Anyway, enough for tonight.

After a bit of tinkering, I managed to provision my ADP1 setup without a SIM card.  A bit of google, and here is what I did

1. Download the Android SDK.  In my case, I unzipped it to C:\android-sdk-windows-1.1_r1.
2. Connection the phone via the USB cable to my computer.  When the phone asks for a device.
3. You’ll get the new hardware dialog, when prompted for the drivers, you’ll need to specify the location.  The Android SDK has the drivers, in my case they were at C:\android-sdk-windows-1.1_r1\usb_driver\x86.
4. Once you have the drivers installed cd to c:\android-sdk-windows-1.1_r1\tools.
5. Type adb devices.  This should list all the Android devices that you have connected.  If you don’t see any devices listed, then you have a problem.
6. Type adb shell.  This will direct your commands to your ADP1
7. Now while at the adb shell, su to root, then : 
8. cd /data/data/com.android/providers.settings/databases/
9. sqlite3 settings.db
10. INSERT INTO system (name, value) VALUES (‘device_provisioned’, 1);
11. .quit
12. Reboot the phone
13. adb shell
14. am start –a android.intent.action.MAIN –n com.android.settings/.Settings

Once all that is done, you should be enable to use your ADP1 as if you had a SIM card in it (we’ll except for the phoning part).

Useful link:  FAQ: Unlocking/Activating a G1 or ADP1 Without A Sim Card.

(Note:  this article is pretty dated, and used IntelliJ 8.  I plan a follow-up covering IntelliJ 9)

So I have this semi-fancy Google Android Dev Phone 1.  Lately I’ve been devoting part of my spare time to learning about programming for Android (the OS of the phone).  Google (probably because they didn’t ask for my opinion and/or input) decided to use Java as the lingua franca for Android programming.  If you ask me – and I know you will – they should have used C# and Mono (I might be a bit biased here).  Luckily, years ago I had done Java programming, so I wasn’t that intimidated by the use of Java on Android.

The first big question that every developer faces is which IDE?  There are a few Java IDE’s out there, but if you ask me the only ones worth considering are Eclipse and IntelliJ.  The documentation for Android points you to using Eclipse.  Eclipse is a good IDE.  However, back in the day when I was getting paid for Java development, my employer got us all copies of IntelliJ, from JetBrains.  I liked it.  I like it enough that if I landed a contract tomorrow that involved Java, I’d buy me a copy of IntelliJ.

So, all that being said, I figured I’d give IntelliJ a spin as I travelled down the stack-trace of Android programming.  Here are my observations, in general:

1. There is an Android plug-in for IntelliJ.  Now, you might believe that development on the Android plug is dead.  Not true.  The plug-in is undergoing active development – it just seems to be kind of slow
2. I found the installation of the Android plug-in for IntelliJ far easier than for Eclipse.  Just download the most current release, and then unzip to your plugins folder in your IntelliJ installation.  With Eclipse, it is simple, but not when the documentation is wrong.
3. The IntelliJ plug-in is simple, and seems to get the job done.  It’s a bit to simple at this time, if you ask me.  The ADT for Eclipse provides a far richer dev-centric experience for Android coding.  For example there are designers to help you with laying out your form, a lot more control over starting up the Android emulator, and better tooling for hooking up the debugger to either the emulator or an app running on the physical phone.
4. Being a Resharper junkie, I found that IntelliJ was more natural for me to use.
5. I didn’t run into to many problems when I was trying to use/convert Eclipse project with IntelliJ. This is good, because the vast majority (all?) projects I’ve seen are all Eclipse based.

So, my conclusion at the end of the day, is that I’m going to stick with Eclipse for my Android development.  There just seems to be less friction at the moment if you’re using Eclipse.  In a couple of months maybe I revisit IntelliJ and see what’s new with it and Android development.  However, at this time, I’d like to really concentrate on learning the Android SDK, and it seems simplest to me right now with Eclipse.

Figured I was due to spend some time setting up a Linux VM and learning how to program my Android Dev Phone 1.  Eclipse is what is recommended, so I thought I’d give that a try first.  So, with the help of Suse Studio, I quick built myself a VM with Java 1.6 (Aside:  I love Suse Studio, I can provision a VM in minutes).  I figured it would be pretty straight forward.  The docs on the Android Developer site for installing ADT plug-in seem pretty straight forward and simple, and I remember Eclipse having a very rich ecosystem of plug-ins that were easy to install (something I wish Visual Studio had – hint, hint Microsoft).

However, I ran into some hiccups with the provided documentation.

The first annoying one was item #4 in the list for Eclipse 3.4.  You’re directed to enter the location https://dl-ssl.google.com/android/eclipse/ for the location of the ADT plug in.  This did not work for me.  The location I had to use was  https://dl-ssl.google.com/android/eclipse/site.xml.  There is a chance https might not work for you, then use http://dl-ssl.google.com/android/eclipse/site.xml.

After overcoming that hurdle, I tried to do the Hello World sample.  This did not work out so well – Eclipse crashed.  Turns out that the default packages for Eclipse provided by OpenSUSE doesn’t have the Web Standard Tools, which is a requirement for using ADT.  So, I went back and uninstalled Eclipse, and download the tarball from the Eclipse website.  Then I installed and setup the ADT plug.

After a bit of tinkering, I managed to provision my ADP1 setup without a SIM card.  A bit of google, and here is what I did:

1. Download the Android SDK.  In my case, I unzipped it to C:\android-sdk-windows-1.1_r1.
2. Connection the phone via the USB cable to my computer.  When the phone asks for a device.
3. You’ll get the new hardware dialog, when prompted for the drivers, you’ll need to specify the location.  The Android SDK has the drivers, in my case they were at C:\android-sdk-windows-1.1_r1\usb_driver\x86.
4. Once you have the drivers installed cd to c:\android-sdk-windows-1.1_r1\tools.
5. Type adb devices.  This should list all the Android devices that you have connected.  If you don’t see any devices listed, then you have a problem.
6. Type adb shell.  This will direct your commands to your ADP1
7. Now while at the adb shell, su to root, then : 
8. cd /data/data/com.android/providers.settings/databases/
9. sqlite3 settings.db
10. INSERT INTO system (name, value) VALUES (‘device_provisioned’, 1);
11. .quit
12. Reboot the phone
13. adb shell
14. am start -a android.intent.action.MAIN -n com.android.settings/.Settings

Once all that is done, you should be enable to use your ADP1 as if you had a SIM card in it (we’ll except for the phoning part).

Useful link:  FAQ: Unlocking/Activating a G1 or ADP1 Without A Sim Card.

After an uneventful flight from YEG to PSP, I’m settled in with my family.  After spending some time with beer at the pool, I’m sitting down with my Android Dev Phone 1 that I ordered last week (ship to PSP).

First impressions:  it seems like a nice phone, and I like the fact it has a keyboard.  I don’t have a SIM card to help with provisioning the phone, so all I get is this message saying "No SIM in phone" and "Emergency call".A quick search on Google tells me that how to get around this and use WiFi.  So, that’s my task for tonight.

Tomorrow we’re heading to the farmer’s market at the College of the Desert where I hope to refresh my collection of quality shirts.