Goals and concepts Architecture Sample code API Docs


MOBBL is a model-view-controller based framework for mobile apps. The layers are discussed below.

Model layer

The model layer consists of Documents which have Elements which can have sub-Elements and Attributes. Document objects can be passed to classes in the view, controller and services layers. If you keep your data in Documents the MOBBL framework classes can be used. This is essential for effective porting of code and effective maintenance. If you create your own classes to store data, you will not benefit from the framework.
Example Document (shortened for this page, full document is included in the sample apps) <CATALOG> <PLANT> <COMMON>Bloodroot</COMMON> <BOTANICAL>Sanguinaria canadensis</BOTANICAL> <ZONE>4</ZONE> <LIGHT>Mostly Shady</LIGHT> <PRICE>$2.44</PRICE> <AVAILABILITY>031599</AVAILABILITY> </PLANT> <PLANT> <COMMON>Columbine</COMMON> <BOTANICAL>Aquilegia canadensis</BOTANICAL> <ZONE>3</ZONE> <LIGHT>Mostly Shady</LIGHT> <PRICE>$9.37</PRICE> <AVAILABILITY>030699</AVAILABILITY> </PLANT> <PLANT> <COMMON>Marsh Marigold</COMMON> <BOTANICAL>Caltha palustris</BOTANICAL> <ZONE>4</ZONE> <LIGHT>Mostly Sunny</LIGHT> <PRICE>$6.81</PRICE> <AVAILABILITY>051799</AVAILABILITY> </PLANT> </CATALOG> Example Document definition for the CATALOG Document <Document name="CATALOG" dataManager="MBFileDataHandler"> <Element name="PLANT"> <Element name="COMMON"> <Attribute name="text()" type="string" /> </Element> <Element name="BOTANICAL"> <Attribute name="text()" type="string" /> </Element> <Element name="ZONE"> <Attribute name="text()" type="string" /> </Element> <Element name="LIGHT"> <Attribute name="text()" type="Plant-Light"/> </Element> <Element name="PRICE"> <Attribute name="text()" type="string" /> </Element> <Element name="AVAILABILITY"> <Attribute name="text()" type="string" /> </Element> </Element> </Document> Note: the dataManager attribute tells MOBBL framework to retrieve and store CATALOG Documents on the file system.

View layer

The view layer consists of Pages which have Panels which can have sub-Panels and Fields. Because a Page always references a Document, the Panels and Fields are generated at runtime from the data in the Document. MOBBL framework does basic layout, but we expect you will want to write your own views using xcode, eclipse etc. Each Page has a reference to a ViewController, which is a UIViewController on iOS and a Fragment on Android. The ViewController class contains only view logic. Business logic should go in Actions (discussed further on) in the controller layer.
There are wrappers and builders which can be overridden to customize the Page, Panel and Field layout. Or you can subclass the ViewController, create a custom view from scratch and write code to bind with the Page and Document.
Example Page definition
<Page name="PAGE-catalog" document="CATALOG" title="Catalog"> <Panel type="LIST"> <Panel type="SECTION" title="Plants"> <!-- the ForEach element creates a new row for each element of type PLANT --> <ForEach value="/PLANT" suppressRowComponent="TRUE"> <Panel type="ROW" path="." outcome="OUTCOME-plant-detail"> <Field type="LABEL" path="COMMON[0]/@text()"/> </Panel> </ForEach> </Panel> </Panel> </Page>
Result on iOS7
This page definition dumps the contents of the CATALOG Document into a list. The ForEach element loops through the PLANT data and generates rows with fields. The Fields are populated with the content of the COMMON node. The outcome attribute generates navigation, which will be explained in the Controller layer documentation.

Controller layer

The controller layer consists of the ApplicationController, Outcomes, Pages, Dialogs and Actions. The ApplicationController binds all the Outcomes, Pages and Actions together at runtime. A Page is the equivalent of a screen. A Dialog creates a stack of pages that equates to a tab in many applications. Actions are blocks of encapsulated business logic that process Documents. Actions allow business logic to be separated from view specific logic. Outcomes are the imaginary arrows between Pages and Actions which are typically fired when a user presses a button. Outcomes allow logic to be added without having to rewrite the view layer. Also complicated routing such as login/logout procedures can be separated from the Pages by means of Outcomes. The ApplicationFactory instantiates Actions and ViewControllers, minimising dependencies between parts of the application. This is essential for effective porting of code and effective maintenance.
Example controller configuration <Wiring> <Outcome origin="*" name="OUTCOME-catalog" action="PAGE-catalog" /> <Outcome origin="*" name="OUTCOME-catalog-foreground" action="PAGE-catalog" noBackgroundProcessing="TRUE"/> <Outcome origin="*" name="OUTCOME-plant-detail" action="PAGE-plant-detail" transferDocument="TRUE"/> <Outcome origin="*" name="OUTCOME-add-plant" action="ACTION-AddPlant" transferDocument="TRUE"/> </Wiring> <Actions> <Action name="ACTION-AddPlant" className="AddPlant"/> </Actions> The above Outcomes have a name which is how Pages and Actions refer to them. They also have an action attribute which specifies which Page or Action should be triggered. The origin attribute limits how the Outcome is triggered (the example has wildcards, but another Outcome name can be used). The transferDocument attribute causes the Document that was passed to the Outcome to be transferred to the triggered Action or Page. If it is not specified, a new Document is created automatically according to the Document configuration. The noBackgroundProcessing attribute causes the Page or Action to be triggered in the foreground. Default behaviour is in the background, so the user interface is not blocked. Lastly an Action is defined. The Action will have to be coded and added to the ApplicationController before it can be used.

Services layer

The services layer contains among other things DataHandlers for retrieving and storing Documents. File based, Memory based and network based DataHandlers are available out of the box, including error routing for webservices. Resource handling, Localization, configurable caching of Documents, serialization and parsing for json and xml and session handling are other facilities that the framework provides.
Example config snippet <EndPoints> <EndPoint documentOut="CATALOG" timeout="30" endPoint="http://www.w3schools.com/xml/plant_catalog.xml" cacheable="true" ttl="10"/> <ResultListeners> <ResultListener name="WrongPlantResultListener" matchExpression="*wrong plant*"/--> </ResultListeners> </EndPoints> The EndPoint defines that the CATALOG Document is retrieved from a url at www.w3schools.com, that an http timeout of 30 seconds should be applied, and that the Document should be cached for 10 seconds. If the Document definition specifies a data handler for webservices, the framework will automatically pick up the EndPoint definition. Developers can write code to force a refresh of the cached copy. The ResultListener responds to a 'wrong plant' error in the webservice response and triggers a WrongPlantResultListener, which a developer needs to code. The error code match uses regular expressions (regex).

Sample applications

Sample applications with code and definition examples are available for iOS, Android and mobile web / JSF: https://github.com/ItudeMobile/itude-mobile-samples
The master-detail-sample is the best place to start. Other projects show how to accomplish common developer tasks.

Creating an application

Starter projects are available to get you up and running for iOS, Android and mobile web.

MOBBL framework API documentation

Github docs

Documentation which is specific to a github repository will be available here


The MOBBL XML Schema, described in a XSD (XML Schema Definition) is an abstract representation of the MOBBL object's characteristics and relationship to other objects.