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.
UI Framework
One of the most important facilities you need in a typical enterprise mobile client app is a framework that will allow you to quickly put together a form that consists of a set of fields of various types represented by various UI controls. Have a look at the example on the right – it is Alessandro La Rosa’s example app to calculate your taxes if you live in Italy (click to see full-size).
It might seem that Android has enough built-in UI APIs not to make you think about adding any framework layer of your own. However, some things are missing:
- There is no dedicated layout class that allows to make quick and efficient (especially for various display sizes) form-like UIs where you have a set of controls and labels attached to them. You will probably either use LinearLayout or TableLayout, or build your own FormLayout on top of them.
- There is no data-binding framework. Remember I talked about MVC multiple times already. What I want to say here is that you’d like user’s input automatically bound to your POJO model object rather than kept inside a set of UI controls like TextViews and Spinners. Adapters seem to do a part of the job for lists as they work one-way (from data to UI) rather than two-way. In any case, what we usually want is a control-level solution, such as one that allows you to bind an underlying bean’s property name to a TextView with the ID name_view.
- There is no common way to detect and express validation errors. Almost any form lets the user enter invalid data and then rejects it and helps the user find and fix their error. There are two parts of this facility – an engine that allows you to specify your validation constraints and get the list of errors given an input, and a common way to present those errors in the UI. The platform does not have either of those, so you will have to decide how you do it. If you have created a data binding/MVC solution as described in the previous point, then it will typically take over validation as a phase in its UI-to-data process. When you want to display the errors you found, you can show a popup dialog, or insert a yellow bar at the top of the form, or show each error near the field that it is related to etc. You’ll have to do it manually for each form, or build a set of reusable classes that will help you.
- If you have really many forms in your app, you might consider building a form-generating framework (like those often found in RAD environments) that allows generating dynamic forms based on your POJO beans (that you will perhaps annotate with helper UI annotations such as @MediumText or @Spinner(min=1, max=100) etc.) with minimum work spent on UI.
In addition to the form problem, there are many views missing in the platform that are typically needed for enterprise apps, such as a sortable paginated data table, various charts etc. If you do build those components, make sure they are as generic as possible – there is real value in reusable views when you build your next app.
Server connection
The most obvious missing part in the Android core platform in terms of remote connections is SOAP. There is no SOAP client framework in the platform. This might in fact be a good thing as it should be pretty easy to port the most suitable among the Java SE libraries that do SOAP to Android. The HTTP client that is included in the platform is based on Apache Commons HTTP Client which is a respected and stable piece of code that will serve as a foundation for your SOAP framework.
If your SOAP/XML/JSON-based protocol is complicated, or if you plan well ahead, you will think of including a solution to bind your model beans (POJOs) to XML/JSON and back so that you deal with as little XML as possible. Again, there are existing solutions for that in Java SE, but you will have to think if they fit your performance expectations when ported to Android.
A very common requirement is to keep a server connection open to listen to push-type server events. Luckily, Android has Service (you can read one of the first articles on this blog to learn more about it). If you want to build a higher-level abstract that represents a service-that-keeps-server-connection, I think it could be a good idea and quite reusable in various apps.
What I would also recommend is that if you decide to let a Service do some of your server requests, then it should probably do all of them. You shouldn’t generally do server requests both from Activities and Services. If an Activity needs to issue a server request, you can use IPC to pass it to the Service. Doing all of your server requests in one place allows you to queue them up gracefully, maybe optimize them, and avoid unexpected network load.
In any case, what you would like to do in enterprise apps is to abstractize from the low-level details of opening connections, retrying requests and parsing HTTP and XML data. There is little platform support, but it is possible to do yourself.
Local storage
Android has multiple ways for you to store some data on the device. You can use SQLite behind a ContentProvider, or plain SQLite using SQLiteDatabase, or files using serialization, parcelization or whatever other format.
What I am missing here, again, is a way to bind model data to storage and back. Serialization is not as affected by this problem but it has various other issues such as keeping track of class versions and incompatibility with anything else but Java.
Don’t get me wrong, I’m not saying we need to port Hibernate to Android – at least not now. But a more lightweight and Android-optimized framework to save you from doing it all manually could be very useful. Perhaps a good solution would be to generate source or byte code, or just the necessary SQL strings at the compilation stage. Any automated solution would be better than writing SQL manually as Java strings if you ask me.
In addition, the server connection part of your framework can be combined with the local storage part to build solutions for synchronization, caching and offline access in your app – all of which are appreciated in enterprise applications.
Conclusion
I just covered the “most missing” parts of API that we need and we develop for our enterprise apps. There are other things too, such as building custom UI themes (which is not so easy), security issues when allowing to sign in using different server accounts, encryption etc.
What I was trying to say with this article is not that the Android platform is poor in its enterprise features. Well, maybe a little. But we Android devs as a community should be looking towards sharing and open-sourcing more of what we do when it comes to reusable components, be it enterprise or any other genre of apps. At some point, we should introduce a Spring Framework equivalent, a Hibernate equivalent and a JSF (or whatever) equivalent that are all built specifically for Android. What do you think?
Tags: android, apps, architecture, development, enterprise, service, ui
