It is not a surprise to anyone that the amount of smart phones and tablet devices is increasing rapidly. Some figures at the beginning: Gartner predicts that the total number of Android devices will increase from 47 million units (2010) to 92 million during 2011, and iOS devices from 41 million to 71 million. At the same time, the number of tablets (like iPad and Samsung Galaxy Tab) will grow from 19 million to 55 million.

Many organizations in all kinds of businesses are thinking whether they should create presence in mobile world or how they should do it. Currently, when established companies start to develop a mobile app, most typical cases are either bringing current content to new context (like news applications) or spreading the information about a brand, organization, band, or product (like many fan or lifestyle applications).

One question that we've heard a lot is: "We want to provide mobile services to our customers and end users, but why should we have only an iPhone (or Android) app? If we create a mobile theme for our web site, isn't that enough?" That can be true, but usually there is much more possibilities with native applications. I try to answer that question by describing four levels for mobile apps.

Levels of a mobile application

Level 0: "Smart phones have web browsers." It's quite common to think that the easiest (and the cheapest) way to provide mobile services is to create web site that is designed for small touch screens. The easiness in this approach is that you don't need different apps for different platforms. But honestly, do you actually like browsing the web with your mobile phone? I don't. Of course you can optimize your web site to mobile screen, but still, it is just a web site. HTML standards are not developing very fast while large corporations are fighting which features should be standardized and which not. Usually, if you try to create a satisfactory user experience for your mobile web service, you still have to consider multiple browsers and platforms.

Level 1: "Web inside an app." One simple and fast way to create a mobile app is to create an application (for iPhone, Android, or other platform) and wrap your web site inside it. Platforms like iOS and Android have components that make it easy to embed a web browser inside an app. Compared to simple web site, this approach enables you to add some great (native) user interface components or utilize some advanced features described in level 3.

Level 2: "Great user experience." Especially in iPhone, Apple has created numbers of components with great look and feel designed for touching. By utilizing those and adding a little bit own eye candy to the user interfaces, it is possible to not only achieve a great overall feeling, but also give users wow effects. User experience is usually a lot better with native UI than with web pages. However, using those components can contain even less work than trying to do the same with HTML, CSS, and JavaScript.

Level 3: "New possibilities." Real mobile applications should give user something more than regular web applications. The mobile means that the user has your application with her all the time. Mobile devices provide a lot of data that your app can leverage, for example the location of user,  position of the device, camera data etc. In addition, your service can send messages to user with push notifications, or sell content with Apple in-app-purchase. And platforms add new services with every OS version update.

Of course, these levels are generalizations, and real applications usually are some kind of mixes from different levels. One common combination is to create an iPhone and an Android app for a service and, in addition, to create web site to serve other mobile users.

In following weeks, we will discuss here more about what kinds of applications might be suitable for different kinds of purposes.

Now, I'll wish you a merry Christmas and hope you'll get a lot of mobile gadgets from Santa Claus. =)

I've been building web applications professionally for over five years. I've worked on various platforms with different programming languages, platforms like .Net, PHP, Ruby on Rails and J2EE. In the recent years I've mainly worked on server side Java applications, mostly because there are a lot of this kind of work available and because I enjoy working on something where the development efforts are quickly visible.

Recently I was given an opportunity to develop an application to the Android platform and, since I'm keen to try out new things, I took it. I thought that since Android application are developed with Java, it should be fairly easy thing to do. So now few weeks into development, I'm writing this blog post about my initial impression about the Android platform and development.

The Good

One of the positive things about Android, for me at least, is that the development is done with Java. So there's no need to learn a new language or a new syntax to be able to write code. This also means that you can get an Android project to full speed rather quickly with experienced Java programmers, the only thing they need to learn is the Android way of doing things.

I've also been surprised about how close the Android development is to server side development. Of course there are differences in things like threading, but I never expected to able to use advanced features like Dependency Injection in Android until I stumbled in to RoboGuice. Also the fact that Android projects can be built with Ant means that the dependencies can be sorted with Ivy and builds can be managed with Hudson.

The Bad

In server side development it's common that projects are divided into smaller pieces called modules. Modules are easier to develop and test since they only focus one or two things. I've tried the same approach with the Android project I'm working on and I found out that it's not that easy to achieve. Everything behaves the same if your modules contain only code, but once you have layouts and assets in them, everything goes to sour. The problem is caused by the Android compiler, which cannot find assets compiled into modules. Although this can be easily avoided by keeping all assets in the same project, it makes sharing code between projects more difficult.

In addition there are couple of things that bother me with the Android development tools. All in all the tools are pretty good and do the job they were meant to do, though the Android emulator could be a little bit faster and why oh why doesn't the emulator log scroll automatically? These are small but irritating things, at least when you run into them multiple times every day.

Summary

Although I only have a few weeks experience with the Android platform and despite those small irritating things, I can honestly say that I like the Android platform. The language is familiar, the development tools are pretty good and the whole programming mindset doesn't differ that much from the server side. With a few weeks under my belt, I'm not wondering the success of the Android platform, it's a pleasure to work with.

Within the last decade the software industry has undergone major changes. From our perspective, perhaps the most important change is that in the past, companies like ours were forced to develop, market, and distribute software products and services by relying primarily on internal resources. Nowadays, after the birth of ”online ecosystems”, we can utilize existing software frameworks, development tools, distribution channels, and markets in our business.

So what is an online ecosystem? Well, to give some kind of definition for online ecosystem we could say that it is a combination of business ecosystem and software ecosystem consisting of loosely connected entities, such as producers, customers, marketers, and financiers that interact with each other in complex ways. The environment in which these entities operate is built around the unified platform or market created by the ecosystem hub, such as Apple. This environment provides entities with the means to create, distribute, and consume software products and services. It’s fairly easy to name some more examples of these ecosystems such as, Google with Android and its various markets, Nokia and its Ovi store and so on. These ecosystems exist also in traditional web and server side business. If you’re not familiar check for instance Salesforce and force.com and Google with its Apps Marketplace.

How does the existence of these ecosystems affect software business? Well drastically, but to highlight some issues:

The ease of development and low barriers to entry
In traditional software development vendors select and bind frameworks together, choose deployment and delivery models, implement them and of course do some coding for the actual solution as well ? With the aid of ecosystems, this process may be far simpler. Development frameworks and tools often come with the platform, distribution and marketing channels are implemented by the ecosystem hub as well as integrated payment mechanisms and billing solutions. This means that vendors and developers are much closer to the actual task they should be doing – creating value to customer and end user.

Of course the ease of development has led to lower barriers to entry markets since massive upfront investments are not needed anymore to implement certain service or application. This particular issue has been seen for instance in Apple’s ecosystem with its numerous applications created by individuals. Now anyone capable of reading the documentation is able to deliver solutions for mobile users, which in turn affects the competition, but that’s another issue and the topic of future post.

Quality vs. Visibility
An old wisdom tells that people can’t buy what they can’t see. This is especially true for online ecosystems as the number of different applications is vast.  Unfortunately, most ecosystems are filled with low quality applications that were created just because they were easy to create, not because they serve a certain purpose or create value to users. As the marketing becomes constantly harder, people tend to forget the importance of good quality. Fortunately, we here at Qvik believe that there’s yet room for the premium quality apps ? However, we do understand the importance of marketing to make them succeed.

Of course the issues mentioned above present just the top of the iceberg and perhaps I’ll make a deeper dive into online ecosystems later on.

Wow, it did happen. And all things considered, it happened pretty quick! Looking back just a year, my relationship with Nokia was quite different. For indication on how I felt about Nokia back then, you can check out the Helsingin Sanomat article (€) on 17.5.2009. In the story I posed in the most awkward Pajatzo playing stance while condemning the whole Nokia offering as cumbersome and mediocre, especially so from the developer's perspective. Today, however, I am proud to announce that we are indeed developing a game to be launched on the N8 device (and later on other Nokia handsets).

So why Nokia? What has changed? Well, first of all, some of the barriers of the Symbian creepiness have been lowered with the introduction of Qt. Secondly, the market place has evolved. App Store is no longer the only real venue of app sales - the gold rush is moving. Thirdly, this is a strategic move on the part of Qvik. We are seeing a demand for a complete mobile offering, covering all platforms including iOS, Android and the Qt world. On this we are willing to deliver.

And what game are we working on? Well, stay tuned as we get closer to release. Suffice to say that we are on a roll.