Life has been a bit busy as of late.  On Sept 4, 2010 a little monster invaded my house.  A savage beast, suitably evolved for our Canadian winters and a fearless hunter of snow-snakes.  Oh, that, and it turns out that she is a distant cousin to my last dog Bailey.  This is my new puppy Casey, who is just shy of 9 weeks old.

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.

Lately I’ve found myself doing a lot more web application development in JavaScript.  Typically, I always seem to fall back on plain old Notepad++ or Visual Studio.  As a developer, the user experience in either is, IMHO, somewhat lacking.

However, for the past week, I’ve been using RubyMine.  RubyMine is a Ruby on Rails IDE from Jetbrains, but it seems to work rather well for editing JavaScript and HTML files.  Plus, as an added bonus, it automatically comes with built in support for jQuery.

Curious about RubyMine?  Why not come to the Edmonton Code Camp on November 29th, 2008 and see it in action during my presentation on jQuery?  Or better yet, download your own copy and check it out.

<rant>
Now this may strike the one or two readers of blog as odd (assuming they haven’t fallen asleep or navigated away by now) – a lot of what I do is ASP.NET Development (WebForms and ASP.NET MVC), so shouldn’t I have been doing a lot of JavaScript up to now?

Well, if you allow me to digress a bit, my answer to that is “No”.  I’ve said it before, and I’ll say it again that, as a web developer relying very heavily on WebForms in the past, nothing has done more to emasculate my JavaScript skills than Microsoft’s ASP.NET WebForms.  ASP.NET Webforms, with it’s emphasis on making development as VB6-like as possible, seems to encourage you do try and do everything server-side.  I know that I’ve sat in on at least one presentation by Microsoft employees who have spoken disparagingly of JavaScript.  This is just plain wrong, IMHO.  Ask me why in person, if you’d like to hear the full rant.

Note:  This is my opinion.  Lots of people are happy with Webforms, and if you are, good for you.  I’m not.  Direct all comments and opinions on my viewpoint to /dev/null. 

Of course, this rant doesn’t apply if you’re using ASP.NET MVC or MonoRail.
</rant>

Updated August 10, 2010 : A bit of time has passed since I first wrote this post, figured an update couldn’t hurt

These days I seem to use a combination of Notepad++ and Firebug.  Firebug truly rocks.  It would be really nice if it worked for Internet Explorer, but it’s probably more realistic to hope for universal peace or an end to world hunger.  I’m told IE9 is supposed to have some good stuff for JavaScript development, but I somehow doubt that will help me out when I have to debug IE7/IE8 issues.

I’ve had some people in the past suggest Visual Studio 2008 whenever I do an informal poll.  Personally, I’ve found the JavaScript editing experience in VS2008 to be lacklustre at best. 

When WebStorm was in beta, I tried that combined with Firebug.  I rather liked it for my JavaScript editing needs. 

If you have any favourite tools (or IDE’s) to help with your JavaScript/jQuery development, I sure would like to hear about it.

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.

 

You have to love spring time in Alberta.  The tulips have such a contrast against the snow at 21:30 on a Saturday evening:

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.