MOBBL is a model-view-controller based framework for mobile apps. The layers are discussed below.
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)
BloodrootSanguinaria canadensis4Mostly Shady$2.44031599ColumbineAquilegia canadensis3Mostly Shady$9.37030699Marsh MarigoldCaltha palustris4Mostly Sunny$6.81051799
Example Document definition for the CATALOG Document
Note: the dataManager attribute tells MOBBL framework to retrieve and store CATALOG Documents on the file system.
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
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.
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
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.
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
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 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.