Opgenorth.NET

Just recently I switch my mobile carrier from Rogers to WIND Mobile. Their Holiday Miracle plan was just to good to pass up – even paying the penalty to break my Rogers contract I will still save money in the long run.

Anyway, once the number got transferred over, I didn’t have a 3G connection, even after selecting the WIND Home APN.  After a bit of google, it seems that what I had to do is to setup an APN.  In case I can’t find it later, here are the APN settings:

After setting this up, bingo, got my 3G connection going.

(Or, things to do when you have a sick kid)

One of the new data catalogues that the City of Edmonton has put up is the 2010 Election Results.  This Thanksgiving Long Weekend I was kind of “grounded” at home when my son came down with a nasty inner ear infection.  I was hanging out with him, and thought I could use the time to see how hard it would be and how quickly I could put together an Android application that would poll these results and show leading candidate in each contest for a given ward.  Turns out it was not that hard at all.  Development time was less than one day, and then I had the application running on my phone for a couple of days.

If you search the Android market place for YEG Vote, and you’re running Android 1.6 or higher you should able to find the application and install it (assuming, of course, you care about the election results).  The application itself is pretty bare bones.  It will get the results every five minutes, and then show the leading candidate.

I think my next trick will be to duplicate the application in C# and MonoDroid just to get a feel for the differences and such.  I’d wager that it will take even less time in MonoDroid for me, given that I’m much more fluent in C# than I am in Java.  I’d have done this in MonoDroid to being with, but MonoDroid is currently in a limited preview and one of the conditions of being in the preview program is that you can’t distribute applications written in MonoDroid yet. I would have tried a Windows Phone 7 port, but it just doesn’t make much sense, given that the number of people in Alberta with actually WP7 devices is probably less than 10.  Maybe next election.

If you have any suggestions or ideas, feel free to let me know. If I can scrounge up some time this weekend before the election I’ll see if I can implement them.

And, it goes without saying, regardless of what you think about this application, if you live in Alberta, make sure you get out and vote this Monday (October 18th, 2010).

My trusty old ADP1 is beginning to show it’s age, and I’m thinking that it’s time to get a new Android based smart phone.  So, what should a guy get?  My criteria (to be modified as thoughts come to mind):

• Not carrier locked
• Would prefer it compatible with the frequencies used by Rogers (I’ve got about 18 months left on my contract with them).
• I can install CyanogenMod on it.  More to the point:  I can install the latest versions of Android as they become available.  CyanogenMod seems to be the handiest way to do so.

Personally, I’m thinking either an HTC Desire or a Samsung Galaxy S.

I’m not against a Windows Phone 7 device, but there aren’t any on the market now, and I’m thinking that I don’t want to take the pain of a first generation Windows based device.

If you’ve got any thoughts/suggestions/comments/tips, feel free to post them in the comments.

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.

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.

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.

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

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.

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