Tech conferences on the cheap

I like attending developer conferences. Developer-focused conferences bring a huge breadth of thought and concepts, an intoxicating  buffet of technology and learning that widen my knowledge beyond my current job's focus. Alas, technology-focused conferences have not brought the revolution in conference prices that technology has accomplished in other areas. That is, tech conferences remain very expensive. Including airfare and hotel accommodations, you could spend thousands of dollars for a single conference. I have been fortunate to have my employer pay for me to attend some developer conferences, but wouldn't it be nice if such conferences were cheaper in general?

This brings me to RIM's BlackBerry DevCon developer conferences. True, the conference itself is not unusual: lots of technical content plus parties, concerts and a price tag of a few hundred dollars. What I find interesting is what comes after the conference: the DevCon On-Demand website that lets you access the keynote and practically all conference session content. You get the transcript, streaming video/slides, streaming audio (synchronized with video and transcript) and source code. DevCon On-Demand is available not just to conference attendees but also to the entire public. Last year, RIM charged a mere $20 for a year's access to the US conference content. This year, they are charging … nothing.

BlackBerry development is a hobby for me, so I could never justify the cost -- airfare, hotel, registration and vacation time -- to attend something like DevCon. DevCon On-Demand is a great way for me to access the big ticket technical content without the big ticket cost. True, for some people the networking opportunities justify the cost of the real thing. But for geeks like me where the technical content is the primary draw, this is a great deal. Wouldn't it be great if other tech conferences followed this model?

Twilight of BlackBerry Java

I have mentioned before in this blog that I develop apps for the BlackBerry as a hobby. For all my apps so far, I used RIM's BlackBerry Java SDK, which has been their the "official" way to develop apps. I just learned that by next year all my apps will be obsolete. I am not exactly overjoyed. Here are my thoughts.

My latest BlackBerry app: TempoBeat

My latest BlackBerry app is out. Presenting: TempoBeat, an electronic metronome app. I paid quite a bit of attention to the user interface with this app, since I wanted something that works well with both a keyboard and a touchscreen. The controls can be manipulated by touch, but I also included a number of keyboard shortcuts for non-touch BlackBerry model. It has a bunch of features or characteristics typical of metronomes: tempo, beats per measure, volume control etc. This being a BlackBerry app, I added one more feature that truly belongs on a BlackBerry: you can use the iconic BlackBerry LED to blink the beats, in colors of your choice.

I am a Torch bearer

I am a Torch bearer. More specifically, I am now a proud owner of a BlackBerry Torch 9800. This came as a surprise to me, actually, since I had no plans to buy one. The Torch is an AT&T phone: even after unlocking it, the Torch's 3G radio does not work on my T-Mobile network (wrong frequency). I own a Torch because my MissingLight app became a Regional Selection in RIM's 2010 BlackBerry Super Apps Developer Challenge, and the  prize for that honor is a new Torch. I'm not complaining.

MissingLight 2.0 for BlackBerry

I released version 2.0 of my MissingLight BlackBerry app a few weeks ago. This blog entry provides the background for this release.

Counting down my life

When I wrote TimeForTea for my BlackBerry, I had in mind a countdown timer to let me know when my tea is ready. As it turns out, a countdown timer has a lot more uses than that. I am indebted to my own customers for for their ideas of additional uses of TimeForTea. With room for 9 preset times, you can do a lot more than timing your tea. Looking over the reviews, I found a whole lot of other timing uses, such as:

• Washing cycle
• Dryer cycle (no more wrinkled clothes)
• Lunch break
• Pizza/Chinese takeout
• Kids' timeout
• Kids' video game time

You get the idea. I personally also started using TimeForTea to time when my grill is warmed up. Hey, it's summer.

Notes from a BlackBerry Meetup

I went to the first-ever meeting of the New England BlackBerry Developer's group tonight in Cambridge. An official RIM-sponsored group, this Meetup had as speaker Mike Kirkup, Director of Developer Relations at RIM. He covered a number of developer's topics, and his slides will probably be posted on the Meetup page. I won't try to summarize the presentation ("what makes a 'super app' etc"), since the slides should be available elsewhere, but would like to note a few things that I found interesting from the meeting. Since we had an official RIM rep to answer questions, I thought it was a good session.

What's new in KBLauncher 1.1.1

I recently released a new version of KBLauncher, my application quick launcher for the BlackBerry. This blog entry serves as my release notes for this app. The rest of you who are here for non-BlackBerry topics can safely move on.

Oops, did you accidentally ship your BlackBerry source code?

If you develop BlackBerry software using RIM's BlackBerry Java plugin for Eclipse and use Subversion for version control, you could end up shipping your source code with your executable if you are not careful. I had hoped this would be solved with the new version (1.1) of the plugin -- still in beta -- but based on my experience with one of the betas this does not appear to be the case.

The problem comes from the plugin's naive handling of non-Java files. Subversion keeps a copy of every version-controlled file in your sandbox. For example, if you have a Foo.java you will also have a copy as .svn/text-base/Foo.java.svn-base. This allows you to do diffs with the base version or revert your changes without even contacting the SVN server. But when RIM's plugin builds your *.cod executable, it assumes those *.svn-base files are resource files to be bundled with your COD file. The result is that if you view your resulting COD file in a text viewer, you will see copies of your source files -- those svn-base files -- embedded in the binary. Good grief.

Until RIM fixes this, one way to work around this is to specifically tell Eclipse to omit those SVN support files from the build. In your project properties, go to Java Build Path, select the Source tab and edit the source folders' "Excluded" entries. You can use wildcards in your exclusion patterns. And of course, make a test build and view it to make sure your source code is really excluded.

BlackBerry development: big things happening

The buzz in mobile development seems to be on other platforms. People outside of the BlackBerry community probably haven't been paying much attention, but there has been some major announcements in the area of BlackBerry development. These announcements, coinciding with the recently concluded BlackBerry Developer Conference, show that RIM is actively responding to its competition on several fronts. RIM's BlackBerry Developer's Blog has been covering these developments faithfully, so go there if you want to read from the official source. Here, I will go over what seem the most significant announcements to me as a developer.

KBLauncher for BlackBerry has launched

I released my latest BlackBerry app, KBLauncher, last week. So far, the major BlackBerry blogs that have mentioned KBLauncher are CrackBerry, BerryReview and BlackBerryItalia. I also partnered with BerryReview for a giveaway program. All 50 copies of KBLauncher were snapped up within the half hour. People do love their freebies.

KBLauncher is an app that I have been wanting to write for a long time. I have a personal policy of writing only apps that I would want on my own BlackBerry. KBLauncher is an app launcher/switcher that gets its inspiration from a number of familiar desktop applications, such as Bash, ENSO and the IDEA/Eclipse class name lookup. It addresses the too-many-apps problem in a way that I find both efficient and intuitive.

New BlackBerry app in beta: KBLauncher

My latest BlackBerry app KBLauncher is finally undergoing beta testing. KBLauncher is an application launcher and switcher. My idea is that a keyboard-intensive device like a BlackBerry would have users that prefer to use the keyboard rather than scroll endlessly with the trackball to find an app to launch. Oh, and I think the UI is pretty slick too.

This has taken longer than I expected. Part of this of course is the nature of a hobby: I can -- and did -- put the project aside when more important issues came up. But the problem is also technical: the vast BlackBerry installed base comes at a cost, and that cost is the large number of models and operating system releases out in the field. The API for launching apps does not behave consistently across releases. Something that was possible in OS 4.2 stopped working in 4.5, and the workaround in 4.5 does not work in OS 4.6. And a bug in 4.6.0 was fixed in 4.6.1. You get the idea. I spent a lot of quality time with various simulators, and while they are a great development tool, they have their limits. Unfortunately, as a hobbyist I don't have full time QA staff nor a stockpile of test equipment.

This is why this beta period is critical for me. It's not a marketing exercise. I am hoping to find a sufficient number of beta testers who care enough that KBLauncher works to report bugs and collaborate with me.  KBLauncher will likely not be perfect, but I hope to make it work fine in the most common cases.

The App World torture continues

I have a handful of BlackBerry apps published on RIM's BlackBerry App World, the "official" app store for BlackBerry phones. Recently, I have been getting emails daily from users who have trouble downloading my applications. The problem is actually with the on-phone App World application, which can get stuck trying to download an application. App World does not make it easy to figure out who to contact for help with the store, so its users click on the tech support link for the individual apps instead. Those tech support requests, of course, go to the app publishers such as myself, who are in no position to fix App World problems.

It has been a rough ride for many publishers of apps on RIM's store. In their rush to match Apple's App Store, RIM released App World store software that remains buggy and immature. When it first opened in April, App World 1.0 had a glaring bug: for software that sold as try&buy, the store would either deliver paid versions to people who downloaded the free trial version, or delivered the free trial version to people who paid for the full version. This bug was only fixed in App World 1.1, released months later at the end of July.

App World is not the only option for publishers of BlackBerry software. Stores like Mobihand and Handango have been around for years, and you can publish for free. It is a bit of a shame, really: these older stores are in many ways more mature. For example, Mobihand's vendor portal lets you issue coupon codes, set promotional pricing, set prices as low as $0.99 and issue refunds. None of this is possible with App World. So why do I publish on App World? The reality is that for all its problems, App World still has the highest sales volume among the 3 BlackBerry app stores I am publishing on. It probably works fine for most people most of the time. Unfortunately, I have to deal with the exceptions.

Why BlackBerry?

As I said before, I write BlackBerry software. It's certainly not the most trendy platform. At a gathering of mobile developers, I saw from a show of hands that attention is going to more glamorous platforms like the iPhone and Android. So why BlackBerry? BlackBerry fans can articulate numerous reasons why they like their phones. As a developer, I have my own reasons, some of them quite subjective. I'm going to list a few of them in this post.

It's Java

The BlackBerry development platform is Java. It is the standard Java ME (or J2ME) MIDP 2.0/CLDC 1.1 plus the usual JSR extensions for multimedia, PIM, filesystem, location etc. RIM also adds additional APIs for BlackBerry-specific functionality. As an experienced Java developer looking for a hobby, Java ME seemed like the natural progression for me into mobile development. Development in Java ME reminds me of the early days of JDK 1.1 with a simple class library, before J2EE, generics and other features piled complexity into the Java ecosystem. While I certainly appreciate the richness of the Java platform, the sheer minimalism of Java on the phone is also fun in its own way.

While I called it minimalist, Java on the BlackBerry remains Java. It is a "civilized" language with an ample class library and garbage collection. It lets me concentrate more on writing the app itself rather than tedious plumbing like memory management.

It fixes the signing problem

While portable MIDlet development sounds like a fine idea, the MIDlet signing problem cripples Java ME in practice. The basic problem is that the Java security model severely restricts what your Java app can do on the phone. Security is a good thing in itself, except that it's hard to get out of that security sandbox. And escape the security sandbox you must, if you want to do anything substantial like access the filesystem or the network. 

To sign a Java ME app, you need to buy a certificate from an authority like Verisign for a couple hundred bucks. Actually, you will need to buy from several signing authorities because different phones support different authorities. On top of that, the networks may apply their own layer of restrictions and certification process. This adds up to a lot of money. T-Mobile (through their testing/certification partner True North) charges $195 or $250 per build, on top of a $500 deposit. So to release a bug fix on T-Mobile alone will cost you $250, assuming it passes certification the first time. This heavy burden is likely one reason why Java ME apps seem to consist largely of games and other insubstantial apps.

The BlackBerry world is simpler. You pay just $20 to RIM to register as a developer, and that gets you unlimited code signing. You can continue to write Java ME code or use BlackBerry-specific APIs, and your signed app can now access restricted APIs. Of course, this gives you restricted API access only on BlackBerries, but with 20 to 30 million users out there, it is a big user base.

It's open

Unlike the iPhone, BlackBerries are open platforms in that you can install any software you like on your phone. Like your PC, you can install apps from a number of different web sites or straight from your PC. While RIM's App World received a lot of attention lately as the BlackBerry counterpart to Apple's App Store, it is in fact one of numerous app stores available to a BlackBerry owner. On my part, I can choose to publish my software at one of numerous app stores, or even directly from my own website. My ability to write and publish software is not limited by the whims of any one app store. 

It's cheap

This is where my role as a phone user and a developer coincide. As a phone user, I like the fact that you don't need a $20-$30 data plan to use a BlackBerry. Personally, I don't want the crackberry lifestyle where I would pounce on my phone every time it buzzes or blinks red (red LED means message waiting). I also have WiFi access most of the time, so a WiFi-equipped BlackBerry like my Curve 8320 does not really need mobile data. To sign up for an iPhone or an Android phone means that I need a data plan for the next 2 years. That adds up to hundreds of dollars: much more than the original cost of the phone.

As a developer, I appreciate that all the tools I need are free: Eclipse and RIM's plugin, phone simulators and documentation. All I really needed is $20 for the code signing privilege. It is true that RIM's App World requires $200 up front to be listed, but competing stores like MobiHand and Handango will let you publish your app for free. 

It's small

While Apple likes to boast of an enormous selection of apps, it's not always a good thing for a software publisher: it's hard to get noticed. By contrast, the number of apps available for BlackBerry is still manageable. You can still find the usual apps that make rude body noises, but you can also reasonably expect to browse the entire collection without getting lost. I met a couple of entrepreneurs at the mobile gathering I mentioned earlier, who said that they wanted to target BlackBerry as their preferred mobile platform precisely because the iPhone market is so saturated. Another software publisher mentioned that their downloads break down evenly (50:50) between iPhone and BlackBerry. The old cliche still holds that you can be a big fish in a small pond.

Reality check

I don't mean to imply that the BlackBerry platform is perfect. After all, there is a reason why so much developer attention is going to other platforms. And while I have only published a few modest applications, I have had a fair number of frustrations with the platform's limitations. All I wanted to do with this post is to point out a few reasons why I like it.