Complementary and Collaborative Apps

Good-bye monolithic application

You may remember the commercials of the card-board cut-out sales person who said, “So… how much software would you like to buy?”

Ironically, today many software companies don’t even have a sales staff — particularly mobile software companies.

Of course, when you are selling software at $0.99 a pop through an app-store, it can be difficult to justify (let alone financially support) the overhead of a salesperson.

In today’s market it may make more sense to have a marketing partner to build awareness of your app/brand or perhaps engage a channel-focused business development team to build distribution and licensing opportunities.

Marketing can be a significant expense, however it is not the only challenge to being a successful software vendor.

As techies ourselves, there is a tendency to want to add every little feature to our software, however this temptation to add “shiny objects” to an app must be carefully examined and the cost counted. Adding features to a mobile application to make it more appealing to potential customers is one way to increase sales, however perhaps a more profitable approach is to build software which is complementary to other titles, be they your own or the products from another software vendor.

Not only can these complementary titles add value to your customer’s mobile experience — these “partner” companies can share the burden of marketing, effectively increasing your reach and hopefully enabling you to sell more software.

If all goes well, you write less code and sell more of it — not too bad if you can pull it off!

Be intentional with your mobile strategy

There will always be exceptions to this observation, but from what I have seen, people who port high-function applications to mobile devices struggle to get it right. I think this is in part due to not only the challenges of writing good mobile software, but also speaks to the management of the customer’s expectations.

When the customer tries to use your “mobile version” and it is a poor attempt at replicating the desktop features, everyone will be disappointed in the end.

The key here is to build useful features and look to complementary applications to deliver their own specialized, niche features.

An excellent example of this use of a complementary application is the practice of launching the Maps application to help a mobile user navigate to an address managed by another application — i.e. the proverbial “field service engineer” dispatched to fix a washing machine on the other side of town.

Replicating the functionality of the core Mapping applications is a non-trivial tasks — and is not recommended for all but a few vendors who really have a reason to be in that business. It just doesn’t make sense to compete with existing, solid functionality with an “also-ran” implementation yourself. If you are a mapping guru — go ahead and sell a better mapping widget, but for the rest of us, we need to be more strategic with our time and talent.

The mobile experience

Instinctively, it makes sense that a mobile application should focus on performing a few tasks very well. Why? Because we don’t value a very click-and-clack intensive mobile experience — particularly when walking down the street, dodging traffic and eating lunch with our other hand.

Apple has shipped tens of millions of devices thanks to the stupid-simple user experience of the iPhone.

Android has increasingly made strides in this area, leveling the playing field with the iPhone, thanks in particular to features such as widgets and live wallpapers.

Blackberry has struggled to let anyone know that they do anything beyond email, calendar and contacts, so they are somewhat playing catch-up in the mobile app game from a consumer perspective. Despite this reputation as a one-trick pony, the Blackberry platform is actually quite capable of delivering versatile and innovative applications.

Launching other apps

How complementary applications get launched varies by platform. Over the course of the next few posts to this space, we will examine and demonstrate the launching of complementary applications on each of the Android, iPhone and BlackBerry platforms.

As an introduction here, we will look briefly at the techniques used by each of these platforms in turn.

The Android platform is perhaps the most versatile of the three platforms because of the multi-faceted Intent class. The Intent class can refer to a specific Java class, to a MIME type, to a specific data element and more. It can be used to start another Activity (i.e. screen or form), a Service to run in the background, or even a feature in the operating system. When it comes to mastering Android and leveraging other applications, the place to begin is with the Intent.

For the iPhone/iPad environment you want to understand the URL Scheme. Each application that wants to be “launched” must register a particular URL scheme that it is responsible for handling. Just like launching a web page in a browser, your application can be launched from another application. Additionally, supplemental data may be passed to the target application.

Finally, the BlackBerry platform allows an application to implement an interface known as a “global listener”. This code “receives” data which is “posted” by other applications and can selectively filter the data, looking for events of interest. The downside to this approach is that your application which implements the listener interface must always be running in the background.

In the next article, we’ll look at code samples for launching one application from another.