Mobile Apps

Abstract

This page discusses what mobile apps are, including some thought on what I think they should be. It also discusses basic strategies for implementing mobile apps.

What Are Mobile Apps?

Mobile apps can be thought of as applications that run "on-the-go", that is, on devices that aren't full-sized laptops or desktop machines. I prefer to think of mobile apps as apps that run 'on-the-go' but also 'at-home' or 'in-the-office'. In other words, apps that run anywhere on any platform at any time.

The history of computing is tending strongly towards this evolution in software. In a way, we've taken many steps backwards as we've embraced first home computers, then laptops, and now mobile computing devices such as the iPhone and ASUS 10" laptops and cellphones. But I think, as a society, we long for that happy utopia where your personal data is magically stored somewhere safe and yet instantly accessible anywhere at any time on any platform you can imagine.

Web browsers are taking us very close to a world filled with truly mobile apps. But they cannot get us all the way there. There are too many limitations with HTTP, HTML, and Javascript, and these limitations make applications written on that platform, well, limited.

I imagine the following scenario when I imagine mobile apps. It's not an uncommon vision, and it is shared, I believe, by everyone.

John wakes up to the sound of his alarm clock beeping. It informs him that he has an early-morning meeting that day. It knew because the alarm clock is tied into John's calendar and he had the alarm scheduled.

John arises and sits down to his home computer with a full keyboard, mouse, and twin 24" displays. He has, available, all of his work and home files and programs. He can read messages, both personal and professional, or otherwise. He can also quickly jot down some ideas he had before he went to sleep or while he was preparing for the day.

John's meeting is in the city, so he grabs his mobile computing device, a machine that has a 10" screen, and runs to catch the bus. On the bus, he has available to him all of the work he was working on at home, but it is presented differently since the screen cannot nor should it appear like his workstation at home. The screen is a touch-screen, and it has a tiny keyboard missing many of the keys on his full keyboard at home. There is no mouse. But also, if it tried to display exactly like his home computer, the words and images would be so tiny that he'd need a magnifying glass to see them. But John understands the limitations of his device and he doesn't try to write lines and lines of text on it. Instead, he reads his messages or makes short notes. He may also voice record some things.

In the meeting room, each seat has a display inside the desk with a keyboard built in as well. This way, they have a larger workstation than their mobile devices, but still smaller than John's home system. There is also a wall projector that they share among themselves as the meeting progresses. Even though this is a "public" terminal, John still has available all of the apps he uses. Again, they are in a slightly different form. When John shows an app on the projector, it again changes to suit the medium.

In this short story, we see five different devices:

• John's alarm clock
• John's workstation at home
• John's mobile device
• The meeting room terminals
• The meeting room projector

But in the story, John never has to switch the application he is using to match the device he is using.

On Applications

In programming applications, I divide up the world into the Model-View-Controller Paradigm. The Model are those elements that store data and keep the business rules intact. The View are those elements that display data that comes from the Model, as well as components that allow the user to interact with the Controller. The Controller are those bits that implement user actions.

This is a neat way to see how an application can be structured from the inside, but it is also a good conception of how the application can be viewed from the outside. That is, you have the skin on the app which controls how it looks, the guts of the app which determine what the app does, and the data that the app uses.

In the web world, we have pretty much moved into a Service-Oriented Architecture. This is really an extension or logical result of the MVC paradigm. Services store both the data and the business logic for some connected set of concepts and ideas. Clients interact with the services, relying on their business logic and data, but also have their own ideas on how the data should be represented and how the user should navigate the logic. Two clients can put a front-end on the same service in remarkably different ways.

I think applications will have to separate themselves out into these two categories. On the one hand, you have the business logic and data abstracted behind a service. On the other, you have a collection of bits and pieces that allow users to interact with that service appropriately that we call the client.

As seen from the outside, the client is the view and the parts of the controller that map the control in the view to interactions with the service. The service is a representation of the model and the rest of the controller.

Implementation Strategies

With this in mind, I believe that we should start separating our applications out into clients and services. That's the first step. The next step is to allow people to freely implement clients in whatever format they like against the services. In this way, we'll be building applications that will give us the mobile apps we really want.

In implementing services, let's separate out the two concepts of the interface and the implementation. The interface describes what the service does and how it provides it. For instance, it will list all the methods that the service can be called with, and what they do. Part of the interface is also what style of service you are using, whether it is SOAP, XML-RPC, or JSON based. Services may provide multiple interfaces in a variety of formats, but let's make sure that we don't confuse a service for its interface.

The different types of implementations of a specific interface can be numerous as well. One may use a database to store the data, while another will use the local hard drive. A third may use some other service to store user data.

Given a service interface, you can have a number of different clients that use it. Those clients may include web applications or even native applications. They can also include other service implementations.

The branching point has to be the interface of the service. You need to nail down the interface and then live with the results. If you want to change an interface, be explicit about it and call it something new, not something old upgraded.

For instance, let's say I was writing an accounting application. I would separate out the task into writing the service interface, writing a service implementation, and writing a client. Once I get a working combination, then I can think about porting the client onto other devices. Of course, they will look different, modelled specifically for the type of machine and environment they are running in. But they will all provide the same functionality and access the same service.