Posts Tagged ‘service’

Business Android: Enterprise APIs missing in the platform

Friday, December 3rd, 2010

My definition or, rather, my perception of an enterprise mobile app is generally the following:

  • The app in question is a mobile client for a multi-user client-server application. It can either be the only kind of client for the app, or co-exist with a web interface or, for example, a PC desktop client for the same server app.
  • It has a “serious” user interface – rather than trying to impress the end-user with a slick, non-typical UI, it aims to be as straightforward and predictable as possible. It tends to have various forms, charts, trees and lists of various complexity.
  • Conceptually, very often a big part of the app is dedicated to managing (CRUDing) a set of entities such as users, documents, reports etc. Domain models can get quite complex, often with tree-like structures, fine-grained user permissions with different access levels and profiles.
  • Internally the app uses typical client-server protocols like SOAP, XML-RPC or even CORBA. Often in-house protocols and frameworks are used on top of those generic ones or instead of them. You get the picture.

Enterprise apps might not seem to be the most interesting kind to work on. However, they are attractive for many studios because customers usually pay well for them. In addition, as a developer, you will find that they are often challenging to implement – at least with functional and internal quality that will satisfy both the customer and you.

In this article, I would like to cover a list of typical facilities that Android developers need when developing such kind of apps. The platform does not really have that much to offer (as we will see), and many developers build their own ad-hoc frameworks that they try to reuse as needs arise.

I will share some thoughts that I have about that, and will be happy to know your stories too.


Android Architecture Tutorial: Developing an App with a Background Service (using IPC)

Tuesday, June 1st, 2010


Android is a wonderful platform. It has a rich API that allows you, a developer, to easily implement things that other platforms do not support at all or they need you to bend over backwards to get what you want.

The ability to develop a service that runs in the background and does something when the user is not actively working with your app is a great option for application authors. Examples of usage include mail or IM apps that send you a notification whenever there is a new message (we’ll discuss notifications and how to program them correctly in another post), background music players, background downloads and so on.

Yes, there is a dark side to Android background services too – too many services doing too much stuff in the background will slow down the phone and suck the battery. However it’s not quite what I wanted to bring up in this post, so maybe we’ll come back to resource management etiquette in yet another post.

Problem Definition

What we will develop here is a dummy application that contains the following components:

  1. A background service doing something important but not immediately visible to the user
  2. One or more activities that, once launched by the user, talk to the service, control the service and present some information that the service provides

The architecture also has the following characteristics:

  • The service will run in a separate process, allowing the platform to manage its lifecycle and resources separately from the activities
  • The service is supposed to run all the time (there are other valid usage patterns for services, but we won’t discuss that here)
  • The UI (activities) will get updates from the service in a callback or passive mode, reacting to service events rather than polling the service for updates. This is very important in terms of effective architecture, so please keep it in mind for now
  • Since the service will run in a different process, we need to use IPC to talk to it from activities. IPC stands for interprocess communication and is not an Android-specific term but Android has its own implementation (as we will see)
  • The service will do all the thinking (business logic) while the UI will be designed to be as thin and dumb as possible. We’ll keep the architecture well-layered
  • The service will be configured to start during system boot-up

In terms of functionality, our service will grab the latest #android tweets using the twitter search API. The activity will show the latest tweets grabbed by the service when you launch them, and update automatically. Yes, it is a pretty artificial use case, but later you can add notifications and turn the app into “Android News Notifier”, and then put it on the market. :)