Opgenorth.NET » Android

New Version of YEG Buildings up

tom — Sat, 28 Aug 2010 15:56:04 +0000

Last night I pushed a new build of YEG Buildings out to the Android Market. The two changes with this one:

Rather than showing the latitude/longitude of were you are, the application will try to translate that into a more human-friendly address. Note that the address might not be 100% accurate. It depends on how much accuracy the GPS has.
The application no longer uses Google Maps and a KML feed when show where all the historical buildings in Edmonton are. The map of Edmonton is now rendered locally, and all

Just for fun, I also submitted YEG Buildings as part of the Apps4Edmonton contest. So, feel free to check out the contest page – there are a lot of neat applications there. Also feel free to vote mine up.

If you are using or have used YEG Buildings, feel free to let me know your thoughts. If you find a bug, let me know. If you have a feature you’d like to see, I’d love to hear about it.

New Version of YEG Buildings (formerly Historical Buildings)

tom — Thu, 26 Aug 2010 23:34:00 +0000

After a few months of neglect, I put a new version of my Edmonton Historical Buildings application up on the Android Market. I’ve renamed it to just YEG Buildings, as I’d like to eventually include buildings that aren’t historical, but interesting in general for some reason. The previous version had a nasty bug that would crash when you tried to view the location of a building on the map. Was one of those curious things where it worked in the emulator but not on a real device. I’ve tried it out on my HTC Dream running Cyanogen 6.0 RC3 (this is Android 2.2), and it seemed to work.

I’ve also added a feature where you could see all the Historical Buildings from the City Of Edmonton’s Data Catalogue at once in Google Maps. It’s a bit slow (mostly for reasons beyond my control at this point), but it basically works.

You can download it from the Android Market, or via this handy page at AndroidZoom. You’ll need Android 1.6 or higher.

Using IntelliJ for Android Development – the Sequel

tom — Tue, 24 Aug 2010 21:26:00 +0000

A while ago, I posted a blog article about using IntelliJ for Android development. Given that was a year ago, and one version of IntelliJ later, I thought I would do a follow up post. Long story short (and to sound like a TV commercial): I liked IntelliJ IDEA 9 so much, I bought a license.

Since I blogged last year, the Android plug-in for IntelliJ has really matured. I guess the only draw back to it is that you only get the Android plug-in when you buy the Unlimited Edition of IntelliJ – it’s not in the Community Edition. Here are some general comments/thoughts/observations of mine:

It’s cool to have IntelliSense in the XML files. One of the biggest failings of Android (perhaps Java in general?) is the painful lack of a surface designer for a user interface. DroidDraw is tolerable with enough scotch. One could say say the same thing about the UI “designer” that comes with the ADT. So, much of the time I find myself just plugging away at the UI in XML. Sub-optimal, but I don’t have the resources to write a nice designer for the Android layout files, so I’ll just pour another double of Talisker and carry on.
I like the fact that, as a Resharper junkie, IntelliJ seems very natural to me to use. The keyboard mappings are not 100% between IntelliJ and Resharper, but that is merely semantics. I find that within about 30 minutes or so I’ve recovered from the differences and that I don’t suffer to much of a penalty switching between the two.
I’m a bit more structured when it comes to deplopyment. I don’t like how IntelliJ wraps all the deployment magic for me. Don’t get me wrong – it’s handy as all hell for development and getting an APK on my phone real quick. For production level stuff though, I’m finding that Rake more than handles what I need done.

Of course, with Monodroid now in a closed beta and looming in the future, perhaps IntelliJ will be redundant to me? Can I actually just write my Android applications in C# and forget about Java? As Monodroid is in a closed beta, I can’t really comment much about it at this point in time. I think I can say, without the Mono gods smiting me from above with hail, thunder, and lightening, that I’m cautiously optimistic that Monodroid will be appealing to those who want to target mobile devices.

So, over-all impression:

I like IntelliJ better than Eclipse for Android development.
I’d say that IntelliJ is worth the money I spent on the unlimited license.

This claim may not be valid in all states. It is also void where prohibited by law. There is a good chance that it may not apply in Quebec. This definitely does not include batteries. YMMV.

Android, MapView, and your Google apiKey: Part 2

tom — Mon, 09 Aug 2010 22:11:00 +0000

Just to follow up on my last post about embedding Google Maps into your Android application (this part is kind of anti-climatic).

So, by now you’ve signed your application. This is the “hardest” (i.e. busiest part) of the whole process. The next part, getting your Goggle apiKey, is the easy part. First you need to get the MD5 fingerprint of your keystore:

keytool -list -alias androiddebugkey -keystore .keystore -storepass android -keypass android

Once that is done, you and register for a Google Maps API key. You need a Google account, and have to agree to some terms of service legal mumbo-jumbo, but it’s pretty simple. Once you click “Generate API Key”, you will get your key string. You then simply add the Maps API key to your MapView in your application. There are a couple of ways to do this, heres how you would do it if you were using the XML layout files:

Of course, after all this is done, the next trick is managing these keys. You see, when you are working locally, your application is automatically signed using a debug key. This is fine and dandy for most development. However, when you deploy your application, you sign the application using your keystore that you created in Step 1. You may have a brief moment of clarity here and realize that the apiKey from your debug keystore and your deployment keystore are different. I’ve got some ideas on how to deal with that that, but that will be for another day.

Full documentation for all this can be found on the Android developer’s website.

Induction Into the Android Army – the Aftermath

tom — Tue, 15 Jun 2010 23:27:10 +0000

Thanks to all who attended my “Induction into the Android Army” talk this afternoon at the monthly Edmonton Java User’s Group meeting. I’d say it was a good turn out, especially when one considers that this is only the second monthly meeting for EJUG. It was a pretty basic talk, and didn’t dive to deeply into the “fun” Android stuff. If anybody from EJUG wants a follow up presentation that’s a bit more in depth, give a shout out on the EJUG mailing list. If there is enough interest, I’d be happy to put something together.

If you want to browse the code and don’t want to download the Android SDK, you can do so at the Android website. Otherwise if you have downloaded the SDK, you can the samples/Notepad folder. For those who want the PowerPoint slide deck, please hang tight and I’ll get a link to that shortly. Basil already has a copy of it, and he’ll probably post it to the Google Group shortly as well.

Android at the Edmonton Java User Group

tom — Sat, 12 Jun 2010 03:51:42 +0000

Just a heads up for those interested: On Tuesday, June 15th the Edmonton Java User’s Group is having it’s monthly meeting at noon at the Canadian Western Bank Building. The speaker is none other than yours truly. I’ll be giving a brief introduction to application development to Android, using my trusty G1 and IntelliJ.

It’s free to attend, so stop by if you’re so inclined.

Gotta Love JetBrains

tom — Sun, 23 May 2010 03:22:29 +0000

Gotta love companies that “get it”. Late last night I was hacking away on some Android stuff using IntelliJ 9.0.2 (on Ubuntu 10.04). For reasons unknown to me, none of my breakpoints seemed to be working. In fact, IntelliJ just didn’t seem to be working. I narrowed it down to the breakpoints I was setting – it seemed that every time the breakpoints were being hit. I managed to narrow it down to this error:

[ 166030] ERROR – lij.debugger.impl.InvokeThread – null
java.lang.UnsupportedOperationException
at com.sun.tools.jdi.ReferenceTypeImpl.sourceDebugExtension(ReferenceTypeImpl.java:774)
at org.jetbrains.plugins.ruby.jruby.debug.JRubyPositionManager.getPath(JRubyPositionManager.java:141)
at org.jetbrains.plugins.ruby.jruby.debug.JRubyPositionManager.getPsiFileByLocation(JRubyPositionManager.java:156)
at org.jetbrains.plugins.ruby.jruby.debug.JRubyPositionManager.getSourcePosition(JRubyPositionManager.java:51)
at com.intellij.debugger.engine.CompoundPositionManager.getSourcePosition(CompoundPositionManager.java:51)
at com.intellij.debugger.engine.ContextUtil.getSourcePosition(ContextUtil.java:63)
at com.intellij.debugger.impl.DebuggerSession$MyDebugProcessListener$2.compute(DebuggerSession.java:462)
at com.intellij.debugger.impl.DebuggerSession$MyDebugProcessListener$2.compute(DebuggerSession.java:460)
at com.intellij.psi.impl.PsiDocumentManagerImpl$3.run(PsiDocumentManagerImpl.java:298)
at com.intellij.psi.impl.PsiDocumentManagerImpl$4.run(PsiDocumentManagerImpl.java:321)
at com.intellij.openapi.application.impl.ApplicationImpl.runReadAction(ApplicationImpl.java:695)
at com.intellij.psi.impl.PsiDocumentManagerImpl.commitAndRunReadAction(PsiDocumentManagerImpl.java:317)
at com.intellij.psi.impl.PsiDocumentManagerImpl.commitAndRunReadAction(PsiDocumentManagerImpl.java:296)
at com.intellij.debugger.impl.DebuggerSession$MyDebugProcessListener.paused(DebuggerSession.java:460)
at com.intellij.debugger.engine.DebugProcessAdapterImpl.paused(DebugProcessAdapterImpl.java:28)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at com.intellij.util.EventDispatcher.dispatch(EventDispatcher.java:87)
at com.intellij.util.EventDispatcher.access$100(EventDispatcher.java:33)
at com.intellij.util.EventDispatcher$1.invoke(EventDispatcher.java:64)
at $Proxy84.paused(Unknown Source)
at com.intellij.debugger.engine.SuspendManagerImpl.notifyPaused(SuspendManagerImpl.java:306)
at com.intellij.debugger.engine.SuspendManagerImpl.b(SuspendManagerImpl.java:299)
at com.intellij.debugger.engine.SuspendManagerImpl.voteSuspend(SuspendManagerImpl.java:318)
at com.intellij.debugger.engine.DebugProcessEvents$1.contextAction(DebugProcessEvents.java:412)
at com.intellij.debugger.engine.events.SuspendContextCommandImpl.action(SuspendContextCommandImpl.java:62)
at com.intellij.debugger.engine.events.DebuggerCommandImpl.run(DebuggerCommandImpl.java:44)
at com.intellij.debugger.engine.DebuggerManagerThreadImpl.processEvent(DebuggerManagerThreadImpl.java:148)
at com.intellij.debugger.engine.DebuggerManagerThreadImpl.processEvent(DebuggerManagerThreadImpl.java:36)
at com.intellij.debugger.impl.InvokeThread.run(InvokeThread.java:135)
at com.intellij.debugger.impl.InvokeThread$WorkerThreadRequest.run(InvokeThread.java:52)
at com.intellij.openapi.application.impl.ApplicationImpl$5.run(ApplicationImpl.java:329)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:636)
at com.intellij.openapi.application.impl.ApplicationImpl$1$1.run(ApplicationImpl.java:125)
[ 166036] ERROR – lij.debugger.impl.InvokeThread – IntelliJ IDEA 9.0.2 Build #IU-95.66
[ 166036] ERROR – lij.debugger.impl.InvokeThread – JDK: 1.6.0_18
[ 166036] ERROR – lij.debugger.impl.InvokeThread – VM: OpenJDK Server VM
[ 166036] ERROR – lij.debugger.impl.InvokeThread – Vendor: Sun Microsystems Inc.
[ 166036] ERROR – lij.debugger.impl.InvokeThread – OS: Linux
[ 166036] ERROR – lij.debugger.impl.InvokeThread – Last Action: Debug

So, the problem to me seemed to be something wonky with IntelliJ. I e-mailed Jetbrains, explaining the symptoms and the above stack trace. This morning, I was pleased to find an e-mail from Serge at Jetbrains. He suggests disabling the Ruby plug-in that I have installed.

BINGO!

Worked like a charm. Problem goes away, and in less than 12 hours since I asked for help.

Quick Update to HistoricalBuildings

tom — Sat, 10 Apr 2010 19:36:37 +0000

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).

YEG OpenData and their Historical Buildings on your Android phone

tom — Fri, 09 Apr 2010 05:36:24 +0000

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.

Screen shot of the list of historical buildings		Clicking on a build shows you where the building is

Android, MapView, and your Google apiKey: Part 1

tom — Thu, 08 Apr 2010 03:52:38 +0000

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:

xml version="1.0" encoding="utf-8"?>
      
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
      
    android:id="@+id/mainlayout"
      
    android:orientation="vertical"
      
    android:layout_width="fill_parent"
      
    android:layout_height="fill_parent" >
      

      
    <com.google.android.maps.MapView
      
        android:id="@+id/mapview"
      
        android:layout_width="fill_parent"
      
        android:layout_height="fill_parent"
      
        android:clickable="true"
      
        android:apiKey="Your Maps API Key"
      
    />
      

      
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:

Sign your application
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?