Monthly Archives: June 2009

Understanding the Mobile Killer App

Clearly, with the success of iPhone and Blackberry and the buzz around Android and Pre, mobile already has its killer apps. But for someone new like me to this arena, I find it important that I try to understand what that app is and simplify the category so I can know where to focus what little time I have to play here. So this is what I’ve come up with, and I hope you have an opinion you can share in the comments to help guide me.

Here we go. I actually think there are two killer apps happening in the smartphone market today. (I’ll leave out the *book platforms for another post as that’s starting to gel in my mind as well). Start by looking at the iPhone, including the iPod Touch. It’s really Entertainment apps that have made the iPhone one of the most popular mobile platforms of our time. My son has a Touch. He has his mp3’s there, he watches YouTube videos there, he plays games on it. It’s probably what the PSP should have been if it had downloadable content. The platform pretty much comes with good multimedia apps, so if you want to make a hit, writing a good game is the place to start. And looking at most of the other platforms, especially the ones with 3D hardware acceleration, this is true across the board. Actually, you look at the real big picture, good games are popular on all computing platforms, even Spacewar! on the PDP-1.

The other killer app is something a we talk lot about in the Eclipse community, especially my enterprise brethren. And that is thin web client apps. This is most obvious on the Blackberries that almost all business managers have today. Accessing e-mail from an exchange server on a small screen requires specialized software to ensure a good user experience. But I really think it goes beyond just e-mail. There are a lot of web services available in web browsers today. But web browsing on the small screen still sucks and likely will always suck. Writing a thin client that can present information from the web in a format suitable for the form factor is a real winner. The top Android apps I use are clients for gmail, twitter, and RSS. I’d love a good app that lets me write this blog, but I haven’t found one yet. But I know the Google provides the API to do it and Twitter has a good API. Wrap those together and you got a customer. Or maybe I should be the developer ;).

Of course, now I’m torn. I’ve always dreamed of making games, but never had the opportunity to do it. I know it’s a lot of work and probably something I couldn’t do well in my spare time. I’m also pumped by the “mash-up” possibilities writing thin clients for internet apps. And that’s probably something I can do more quickly. Lots of fun. And a reason why I think the industry is going through a reinvigoration. Where the killer app for the desktop has come and the shine has gone (that killer app was office apps, browsers, IDEs, and games by the way). There’s an opportunity to get in on the ground floor of the new generation.

Android NDK Release 1 is Out

I got a surprise today (aside from the passing of Michael Jackson), the Android Native Development Kit (NDK) team has put out its first release. They never really hinted on their mailing list this was about to happen, nor did they actually provide a real time line. But it’s a good surprise.

The purpose of the NDK is to provide the ability to write native libraries that the Dalvik Java code can call through the Java Native Interface (JNI). This is the exact same interface we’re used to with desktop JNI so it’s quick to use. As I’ve mentioned here before, writing native code allows you to take advantage of the underlying hardware that Java hides from you. In this first release, it’s pretty basic, exposing only a few basic APIs such as the standard libc C run-time library, the math library, and libz for accessing compressed files. Just enough to accelerate some of your algorithms with direct execution by the CPU, which is ARM only right now.

There is still a lot missing, and they have promised there is more to come. OpenGL ES and audio are the big items on my wish list. At least I have enough information to be able to set up OpenGL ES so that it’ll run on my HTC Dream phone and the emulator. But there are no guarantees it will run on any of the upcoming phones since the ABI hasn’t been locked down. The GLES shared library name is the biggy (e.g. PowerVR as seen on the TI OMAP chips names their libs differently) although the header files should be the same.

The build system, though, has me very concerned. They’ve taken a lot of the concepts from the Android platform build system, which builds everything in one tree, and brought it to the NDK, including the restriction that everything has to be in one tree. I don’t build software like that. I put my native code in the same Eclipse project directory as the Java. I’m also working on a library that I want to use in a number of different platforms as mentioned in my previous entry. Android is just one target, it’s not the center of the universe.

I also noticed this when I took a look at Moblin. There is a standard way you setup a gcc cross-development environment. GCC has the facility to define a sysroot that organizes include files, and libraries in a natural way. And that allows for multi-target projects with very little change to your makefiles. Don’t assume you’re the only build system that wants to build my code.

One final nit, the Windows toolchain was built using Cygwin. Cygwin is a Linux emulation environment for Windows. As such it tries to hide as much of the Windows environment as it can, in particular when dealing with file paths. That messes up the CDT. We have some code that tries to deal with that, but the architecture is poor and we may loose that functionality over time. I’m a big fan of CodeSourcery and these guys are masters at building toolchains for multiple targets and run cleanly on Windows without Cygwin. Mind you, I’m pretty much solely on Linux now so that doesn’t matter to me as much any more. But others in the community will care.

Anyway, besides all that, it’s a great start. Native development and standard native APIs will be a key success factor for Android. We saw in the game console market how important it was for game developers to be able to target multiple platforms. That larger market allows for larger budgets which, of course, allows for better apps. The Apple guys get that and the iPhone SDK is very good, and at least for 3D Graphics and Audio, very standard. John Carmack of id (Doom and Quake) is a huge fan of theirs, but I wouldn’t mind seeing Doom titles running on my Android phone.

CDT 6.0 Leaves the Station

CDT 6.0 is out. Come and get it!

As I posted on the cdt-dev list the other day to the CDT developers, “CDT 6 has reached all expectations I’ve ever had for the CDT and for that I’m proud of you all.” And I mean that. The biggest new feature for me is CDT 6’s new ability to find header files pretty much anywhere in your workspace. With that, the CDT search and code navigation features work almost all the time, even on code that you simply import even without makefiles. I’ve been using it a lot on projects like that and I continue to be amazed and proud of how well it works. It’s been a great group of people who’ve worked on indexing over the years and after 6+ years, I can finally call it a success!

There are a few other new features that are also very handy in CDT 6. The New and Noteworthy is on our wiki at: Feel free to take a look and try them out. The quality of CDT 6 is also very good. As the pace of new feature development for CDT has slowed over the last couple of years, we’ve gained in robustness so I’m proud of that as well. As I did with CDT 5.0, I can recommend using the 6.0.0 release in production, something that I wouldn’t have in releases before that.

As I look over the last year or so and look to the future, I see my involvement in the CDT has taken a real hit. I do not see myself working on any big features for the CDT in the forseeable future, as I haven’t really in quite a while either. That’s just the reality of where I am right now and I’m OK with that. The CDT is in fine shape. Yes, there are some areas that people want to fix up, scanner discovery being at the top of that list, and I will help guide them as they need my help. But I’m going to transition my role into a CDT user who wants to contribute to make the workflows I use better. And hopefully, others will find that useful as well.

It’s been a great ride with the CDT and I’m not ready to jump off yet. But there are other interesting rides that could use my attention, Android development being my personal interest area. And if you can’t tell from my recent blog posts and tweets, I’ve been totally re-energized by what’s happening in the mobile space. And, trust me, that’s a good thing.

Multi-target Makefiles

I learned a really cool trick with gnu make the other day. I’ve started work on a little game engine based on OpenGL and OpenGL ES targetting Android (of course), the PowerVR simulator for ES 1.1 and 2.0, as well as Linux and Windows desktops. When I first set up the Makefile, I had five different target binaries and I hooked it into the CDT as a Makefile project with five different configs that called make with the right target. Worked fine.

But switching back and forth between each of the configs in order to test an idea was a pain. The CDT does have a Build All Configs menu item but it’s a pain to fire that up since it’s like three levels deep. I got to digging around the gnu make manual in hopes that something would jump out and bite me to make things simpler. And, it did!

Gnu make has a couple of interesting features that help. One, you can create a multi-line macros that take parameters (define … endef) much like the C preprocessor. You can then call ‘eval’ on the resulting string to have that string parsed into the Makefile. That’s awesome on it’s own. But, the second great feature is the ability to define variables on a per target basis. That allows you, for example, to have different CFLAGS settings for different targets.

So combining these features, I’ve been able to set up my builds to generate my library in five subdirectories under lib and objects under obj, all from the same sources. I tried this with a native app at work and I’ve also figured out how to add target specific sources to the mix. What a lifesaver.

Unfortunately, there are gotchas in CDT-land. With each source file compiled by five different compiler and option combinations, it gets pretty confused about what’s what. But the guesses it’s making aren’t so bad and it really drives you to keep the target specifics to a minimum.

To give you an idea of what it looks like, here is the relavent fragment from the makefile for my engine right now. I also just noticed the nice way it does source/header file dependencies using -MD of the gcc compiler and gnu make’s include. Now if I can get the CDT to generate me a SOURCES list automatically…

all: android pvr11lx pvr20lx linux mingw

define PLATFORM_rules
$(1)_OBJS = $$(SOURCES:src/%.cpp=obj/$(1)/%.o)
$(1)_LIB = lib/$(1)/libdasEngine.a

$(1): $$($(1)_LIB)

$$($(1)_LIB): $$($(1)_OBJS)
@mkdir -p lib/$(1)
$$(TOOL_PREFIX)ar rc $$@ $$^

obj/$(1)/%.o: src/%.cpp
@mkdir -p obj/$(1)
$$(TOOL_PREFIX)g++ $$(CFLAGS) -DDAS_PLATFORM_$(1) -MD -o $$@ -c $$
-include $$($(1)_OBJS:%.o=%.d)

android: TOOL_PREFIX = arm-none-eabi-
android: CFLAGS += $(ANDROID_INCLUDE) -DANDROID -fno-exceptions -fno-rtti
android: $(eval $(call PLATFORM_rules,android))

pvr11lx: CFLAGS += -m32 -I$(HOME)/gl/powervr/1.1/include
pvr11lx: $(eval $(call PLATFORM_rules,pvr11lx))

pvr20lx: CFLAGS += -m32 -I$(HOME)/gl/powervr/2.0/include
pvr20lx: $(eval $(call PLATFORM_rules,pvr20lx))

linux: $(eval $(call PLATFORM_rules,linux))

mingw: TOOL_PREFIX = i686-pc-mingw32-
mingw: $(eval $(call PLATFORM_rules,mingw))

Palm, doing open source right

I found this in a roundabout way through the blog. Palm has recently started up an open source license compliance program. They have a team that oversees it and have set up a web site,, where they are releasing the open source packages they used and the modifications. See, is that so hard? Well it is a significant amount of work to set something like this up, but you are getting a ship load of great software for free, so it’s well worth it and by sharing your modifications really shows you as a good open source citizen.

There’s been so much FUD spread over GPL and LGPL, especially LGPL. Linux wouldn’t exist without these licenses. And Linux-based platforms, like the Palm Pre and Android, wouldn’t be possible without them either. Neither would a fully open Eclipse CDT-based IDE for MinGW Windows, which due to the anti-GPL rules of Eclipse, there isn’t. But, enough griping about that.

Palm looks like it has a hit on its hands with the Pre. I’m still awaiting to see what their SDK looks like. So far, it looks like a bunch of Javascript, much like Android is with Java. I’m currently looking at these platforms with an eye on gaming. The Pre certainly has the hardware for it. Even my little Android phone draws a mean triangle. But you need access to that hardware to get good frame rates, which for me means native code, of course.

Android at the Ottawa Demo Camp

Well, my demo at Thursday night’s Ottawa Eclipse Demo Camp was a mitigated disaster. My laptop is in power hell as the batteries last only a few minutes and, of course, started to run out during the demo. The USB connection to may Android phone didn’t work and we theorized that laptop shut down the USB connections due to lack of power. So I couldn’t show that. I also ran out of time which I had a feeling would happen and I forgot to add a line of code that would have prevented the app from crashing.

Aside from that, I hopefully got my point across. Eclipse is a great IDE for doing Android development. The Java side is a natural and you get all the advantages of the JDT with the target management provided by the Android plug-ins. I also showed how easy it was to set up the CDT to write native methods in your Android apps. While not officially supported, there is an Android NDK (Native Development Kit) project that is under way to provide that support in an upcoming SDK release (donut I believe).

What I didn’t get to show was the two implementations of Android’s Kube demo, which shows a Rubik’s cube spinning around apparently trying to solve itself (being purely random, I’m sure it’ll solve itself just after the monkeys write that novel). It’s not a complex 3d object, with only around 3000 triangles (300 drawn 10 times per frame to give it some load), but the performance gained by writing the transformation matrix math in C++ versus Java brought the framerate from 25 frames per second to 36. That’s pretty significant. And on a mobile device where every CPU cycle drains a little bit of the battery, doing more with less is a key factor to a successful product.

At any rate, I had a great time that night. I got to catch up with some old buddies that I used to work at QNX with who are now doing a start-up just down the road from our Wind River offices. And there were some old buddies there from my ObjectTime days there as well. For some reason, these Eclipse events bring us all back together. It’s probably because Eclipse is huge in Ottawa. If your a tools developer here, there’s a pretty good chance your involved with it. And there are some pretty good tools developers here.

What would the IDE look like if invented today?

I just finished reading a great analysis of Google Wave by Redmonk’s Stephen O’Grady. Ever since seeing him present at an Eclipse board/council meeting, I’ve been following his blog. Highly recommended if you’re interested in a great perspective on what’s really happening in the enterprise open source world.

As I was reading it, I was struck by what Lars Rasmussen said at the beginning of his keynote on Wave at the Google IO conference: “What would email look like if we set out to invent it today?”. Well, apparently they’ve ended up with an open, extensible framework for hosted collaboration systems that seemlessly merge IM, e-mail, and documents into a single interactive workflow. Wave has really impressed me as a significant step in the evolution in the way we communicate on the web.

Stephen also brought up IBM’s Jazz. His analysis at the time was that Jazz is application development given a certain number of technologies that were popular at the time, which wasn’t that long ago, i.e., Ajax, Subversion, and IM. And everyone I know who’s taken a serious look at Jazz are pretty Jazzed by it.

Today, though, at least from where I sit, there are a few more technologies that could contribute to our software developer toolchest. And I ask, what would the IDE look like if it was invented today, or at least in the next few years, in a world with Google Wave, distributed source control, and smartbooks. Even just seeing David Green’s blog on Galileo Builds on your iPhone, an app that shows reports on your Hudson builds, gives a hint at this future.

The world around us is changing dramatically since the rise of the iPhone and competing open smartphone devices and our ability to stay in touch with the Internet wherever we go. Also significant is the rise of web technologies that allow us to leverage that connectivity in better ways. What would an IDE look like in that world? My imagination is running wild ;).

Smartphones, Smartbooks different by necessity?

Boy I’m having fun with Android. Maybe because it’s the first time I’m getting the chance (albeit in my spare time) to do some real embedded development. And even in the playing I’m doing, I am experiencing the challenges that regular embedded developers face. Yes, believe or not, even with the latest and greatest hardware, you are limited by the amount of memory and storage your device has, and by the speed and capabilities of the processor. Not to mention power (feel like running your graphics loop at full speed, see how long your battery lasts doing that). You really have to think about these things and write your code carefully to be successful. (And I won’t get started on Java again).

One thing you still see in the rumoursphere with Android is the spreading of it’s wings into the “smartbook” world. I love that term, Smartbook. Mobile Internet Device is too vague and I think there is a clear delineation between the tree contenders: smartphone, startbook, netbook. Smartphones are the small handheld things we know and love today. Netbooks are the small notebooks which likely have a hard drive in them. But Smartbooks are an exciting middle ground between the two. They have usable screens, 5-9 inches, but everything else is like a smartphone, particularly in mobility and power consumption. A good smartbook should last the day without charging making it handy for carrying around conferences like EclipseCon, for example :).

I’m not sure Android can scale to the big screen, so I’ve been looking around at the alternatives and Moblin in particular. I can see myself becoming a big fan of Moblin development. It’s much more like a traditional Linux environment and has my favourite packages available, including Qt, GTK, and X/OpenGL. But I wonder if Moblin has scalability issues the otherway. All those great packages take a lot of resources and they certainly won’t fit on the 256MB NAND flash chip on my Dream phone. And I don’t see consumers being happy losing even more battery life to support bigger and faster chips. So in the grand scheme of things, it appears to me that it requires us to have different software platforms to match the hardware. But we’ll see if the Moblin guys manage to get running on a smartphone.

That’s lead me to wonder if the same is true with the applications. It’s pretty obvious that smartphone and desktop apps have to be different. Screen size and the rest of the resource constraints on phones force you to design the app differently. Now is the same true for Smartbooks? Is this a third category? I have a feeling yes. You may have a bigger screen size and it may look like notebook, but the resource constraints are still there. You still need to be worried about power consumption and you won’t have a desktop class processor to get you out of trouble with sloppy algorithms. Mind you, that’s just good development practice anyway. I’ll have to think about this a bit more.

At the very least, you have a different development environment for your smartbook apps. Generally you’d have a cross compiler, even if it is the same processor. It helps keep the environments separate from the rest of your development desktop. Mind you Moblin seems to be going to great lengths to avoid that for some reason using VMs and remote builds. Cross compilers aren’t that scary, you know :). And the CDT does a great job working with them.

Living with a Dream, an HTC Dream

I realized that I haven’t blogged since I went out and bought my new HTC Dream Android phone from the local Rogers shop. I guess that makes sense since I’ve been busy when I had free time in the evenings and weekends playing with it. First, I had to figure out how to get the Android tooling to hook up to it via the USB cable. Then I went about getting applications running on it and downloading things from the Android market (currently Rogers only has free apps, which is probably OK for now).

The first app I wrote was a stopwatch app that uses the sensors so I can tilt it to start and stop it, something I can use to time curling rocks in the winter. But there are lots of stopwatches out there so it’s probably not worth going through the effort to get it up on the market. But it was awesome to get into that mindset of a mobile application developer. I’ve been doing tools for quite a while. If you want to build good tools, you really need to get into the mindset of your customers. But then, that’s true of all product development.

Of course, I’m using Eclipse to build these apps. There are a couple of things that bug me about the Android plug-ins, including their insistence you set the SDK location preference, even if you don’t have Android projects in your workspace. I’m also using the CDT to work on native apps using the upcoming Android NDK (native development kit) for native libraries. And I’ve already blogged about how mixing JDT and CDT natures in the same project pretty much makes the Project Explorer unusable. I’ve also added egit to the mix as I store the code on a little Linux server I have at home, and egit is still has a way to go to be ready for prime time. Having said all that the IDE is definitely usable and I’d hate to have to do this stuff without it.

So my next step is to try and figure out what makes a good mobile app. The power of these little machines makes anything possible. Their connectivity with wifi and 3G opens the door to great internet apps. I’d like to see the bluetooth connectivity (once they release Android’s Bluetooth API) used to connect to peripherals and other devices. And, of course, the HTC phones have 3D hardware acceleration (despite not having hardware floating point, but that’s typical I hear), making it possible to do some neat little games. The possibilities are endless, you just need to figure out what people want to do on these platforms.

Fighting for Mobile Mindshare

The more I look into what’s happening in the mobile scene, the more excited I get. The smartphone platforms really are the computers of tomorrow. They all have big (enough) screens with touch, most of them have keyboards, connectivity is excellent with both wifi and high speed 3G (Rogers in Canada says it has 3.5G, even better). Heck, they’re way more powerful than the PCs we fell in love with in the 80s.

I’m looking at this from an application developer’s point of view. If you’re a mobile app developer and you have a great idea, what platform do you target? And it’s a pretty significant choice, just like it was in the 80’s. All of the platforms have not only different APIs, but different programming languages. iPhone with Objective-C, Android with it’s own version of Java, Palm Pre with JavaScript, RIM with J2ME, and Nokia with almost everything including Flash and C++. And then you have the Linux-based MIDs such as Moblin (need to mention my upcoming new bosses :)) and Maemo which are also starting to blur the line as they start acquiring 3G functionality. In theory, you’d love to get your idea on all these platforms.

But I’m really not sure how this is supposed to happen and that’s one of the biggest challenges we have in the mobile market. I can see why these vendors want to keep their own identity. These SDKs are differentiating right now, at least until we get more apps in place. And they are fighting for the same market and would rather see developers build apps for their platform and not the other guys. So, I think it’s up to the app developers to solve this, to give them bigger markets to sell into. We’ll see how it pans out.

The good news is that, thanks to Eclipse, there is already a number of these vendors who have tooling based on Eclipse. Theoretically, you should be able to build an IDE that integrates all these tools together and least have a common development environment. And the Eclipse Pulsar mobile working group is working on making it easier to set this up.

There are some common technologies. I think all the platforms have Web Browsers that support Web 2.0 applications (and that’s all Palm Pre seems to have). And since they all have full-time connectivity to the Internet, this seems like a reasonable choice. Also the newer platforms have 3D graphic support through the standard OpenGL ES API. That might be a good choice if you have a more graphics intensive application.

The one thing that crossed my mind is whether modeling has something to offer. People who know me will find that funny as I’m quite jaded from my days working on modeling tools. But Model Driven Development was intended to address this kind of problem. I think the biggest problem with MDD was poor modeling of behavior, a must in this domain, but you can’t dismiss the potential of writing your app in a platform independent language and generating the implementations for each platform you want to support. Whoever comes up with that, and it’ll be immensely expensive to build, will have a market of confused application developers to sell to.