Fundamentally, Mobiliti is a reference architecture for building mobile apps.  Reference architectures describe a standard way of decomposing a particular domain to build an application, predefining complementary structures and components that contribute to a multi-use design.  To assemble a component-based system, a reference model is used to standardize component construction making them interoperable with each other.

Mobiliti’s reference architecture defines a generic model for mobile apps that support multi-user concurrent access and task processing.  It describes the foundation and hierarchy of basic components needed to build content driven systems.  Key features of Mobiliti include:

  • No mobile expertise needed
  • Native apps (not wrapped WebKit)
  • Content-driven using XML to define domain model and UI
  • Find-List-View-Task navigation paradigm
  • Server supported content access and XML schema download
  • Ideal for enterprise apps connecting to internal databases


The Mobiliti framework provides for rapid development of mobile apps and handles networking, transaction management, error handling, and UI creation.  This object-oriented technology can target development of a wide range of mobile apps in multiple vertical industries.

Mobiliti wraps around a content model to automate the viewing, editing, and processing of content objects.  These objects are represented as separate framework entities that encapsulate the data and tasks necessary to support each object.  The framework natively supports graph type databases where there is a structure with entity nodes and their relationships to other entity objects.

Content objects can be developed either at the server or mobile tiers in a Mobiliti app.  This means both mobile UI presentation and functionality revolve around independent object-based components that could be controlled by a server.  This also means a developer doesn’t have to be an Android expert to create apps.  Using Mobiliti’s framework, a true “plug-n-play” capability exists to allow component modules to be dynamically added or removed at the server tier to define an app.

In simple terms, Mobiliti automates the listing, selecting, editing, drill-down, and task processing of discrete entities and their related children of a content model:

List-View-Task Paradigm

Mobiliti is based on a fundamental concept that all apps can be decomposed into a superset of only a few program types.  This approach allows application modules to be built upon a framework that provides much of the architectural foundation for displaying multiple records, viewing and editing single records, or performing a business process.  Mobiliti classifies its programs into three major groups:

  • List – program retrieves multiple records for an associated data object.
  • View – program selects one record instance of an associated data object and optionally allows CRUD (create, read, update, and delete) operations on the record.
  • Task – program performs a business process.

Node Graph

Another key feature of Mobiliti is its built-in support for chaining related data objects together. Nodes of a parent data entity are defined in XML to describe a data graph used for drilling down a hierarchy of objects. In a relational database, nodes are children tables related by a foreign key. In a social graph like Facebook, nodes could be your friends or posts you have made on your wall. Once the nodes are defined to the framework, it automatically builds UI components to allow an recursive navigation down and back of parent/child nodes.

Developing a Mobiliti app is a simple exercise of describing the content model in XML then developing the server program to support List, View, and Task requests for every data object in a content model.

Mobile/server Architecture

While most mobile apps use a single tier architecture where the mobile device retrieves content directly, Mobiliti is able to use a proven n-tier architecture for scalability, easier deployment of content, and off-loading of processing to the server.  Most importantly, this allows normal enterprise developers to create mobile apps without expertise in the mobile tier.  Content handlers can be developed at the server tier which provides more flexibility and power when obtaining content.

Developing an Application

Developing an application with Mobiliti is a very model driven exercise. In essence, each discrete data entity (or database table) in your application model corresponds to a content entity in the app. These discrete entities are inter-connected at runtime by Mobiliti. The mobile presentation layer just reflects the content domain model. Fundamental data objects show as “launch” items on the home screen and navigation pathways follow model relationships from these fundamental launch objects. User security profiles determine what objects, their data attributes, and business tasks are visible to the user.

Mobiliti uses a declarative method to define the data attributes, relationships, and available business tasks of a content entity. The declarations are specified via XML and are used by the mobile app to display authorized information and enable features to the user. The XML “schemas” can be static files stored with the app, sent by the server, or dynamically built at runtime. This flexibility allows the mobile app to morph its UI display and feature set similar to a web browser when it receives HTML.  So features, icons, buttons, etc. will appear as needed to support your particular content-driven application. A content configuration file describes your app as composed of one or more “sub-apps” each with their own home screens containing fundamental data entities to start the Find-List-View-Task paradigm model.

Content Handlers

Each sub-app defined in the content configuration file uses a content hander program.  An instance of this handler can be created on the mobile device or more often on the server.  This handler is responsible for all data access and processing of business tasks.  The content handler is a “provider” of data for the app.  There are 2 types of content providers:

  • Proxy – Content is dynamically retrieved by the content handler which acts as a proxy to any data source. All data access is managed by this handler with your programs. This is the most flexible content provider.
  • Database – Content is dynamically retrieved by a server which uses a relational database for the data source. Data access code is written using Java Persistence API (JPA) modules for each database table which corresponds to data entities in the XML schemas sent to the mobile device. This handler can provide significant capability to access corporate resources while minimizing development code when using JPA/Hibernate for persistence.

Content handlers supply content and perform business processes for content entities.  After the start screen shows up with your sub-apps, a user selects the sub-app which then begins the cycle of displaying entities with drill-down into related entities.  The first screen shows “home” entities which are fundamental data entities that exist in your content model independent of any other entities.  Usually the user selects a Search button on the list of home entities to select a subset of records for that entity.

Although handlers are generally created on the server, instances can be created locally on the mobile device (except for database provider types).  If a handler was packaged onto the mobile device, content calls will first be run through the local instance.  Any handler API methods not overridden by the instance will then be forwarded to a server instance of the handler if an app server was specified in the content XML.  This flexibility allows apps to have content handlers that are either server-based, locally stored, or a hybrid where API calls are serviced by both local and server content handlers.

Dynamic UI

Mobiliti provides built-in user interface (UI) components based on content schemas.  The developer of an app need only define data attribute types to enable UI features to automatically support them.

Development Steps

To develop a Mobiliti-based app, follow these steps:

  1. Create a content.xml configuration file
  2. Create entity schema files (or develop code to dynamically build them)
  3. Create a content handler program to obtain content data
  4. Package all the above onto the web and application servers

%d bloggers like this: