Although I am not doing that much front-end development these days, nor consider myself to be a Titanium-guru, I have observed that it is quite challenging to keep your app's code and organization clean.
In this blog post, I will report on my development experiences and describe the architecture that I have derived for the example chat application.
The Model-View-Controller (MVC) architectural pattern
Keeping the code of an end-user application sane is not unique to mobile applications or a specific framework, such as Titanium -- it basically applies to any system with a graphical user interface including desktop applications and web applications.
When diving into the literature or just by searching on the Internet, then you will most likely stumble upon a very common "solution" -- there is the Model-View-Controller (MVC) architectural pattern that can be used as a means to keep your system structured. It is a generically applicable pattern implemented by many kinds of libraries and frameworks for all kinds of domains, including the mobile application space.
The idea behind this pattern is that a system will be separated in three distinct concerns: the model, the view and the controller. The meaning of these concerns are somewhat ambiguously defined. For example, the design patterns book written by the gang of four (Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides) says:
MVC consists of three kinds of objects. The Model is the application object, the View is its screen presentation, and the Controller defines the way the user interface reacts to user input.
The "problem" I have with the above explanation is that it is a bit difficult to grasp the meaning of an "application object". Moreover, the definition of the controller object used in the explanation above, states that it only has a relation with a user interface (a.k.a. the view) while I could also think of many scenarios in which external events are involved without invoking the user interface. I have no idea how to categorize these kinds of interactions by looking at the above description.
The paper that the book cites: "A Cookbook for Using the Model-View-Controller User Interface Paradigm in Smalltalk-80" (written by: Glenn E. Krasner and Stephen T. Pope) provides more detailed definitions. For example, it defines the model as:
The model of an application is the domain-specific software simulation or implementation of the application's central structure.
I particularly find the term "domain-specific" important -- it suggests that a model should encapsulate what matters to the problem domain, without any obfuscations of things not related to it, for example, user interface components.
The paper defines the view as follows:
In this metaphor, views deal with everything graphical: they request data from their model, and display the data
The above definition suggests that views are everything about presentation of objects belonging to the model.
Finally, the paper defines controllers as follows:
Controllers contain the interface between their associated models and views and the input devices (e.g., keyboard, pointing device, time)
In contrast to the design patterns book's definition of a controller, this definition also suggests that a controller has a relationship with the model. Moreover, it does not say anything about interactions with a physical user. Instead, it refers to input devices.
Although the paper provides more detailed definitions, it still remains difficult to draw a hard line from my perspective. For example, what is the scope of MVC? Should it apply to an entire system, or can it also be applied to components of which a system consists?
For example, in an earlier blog post, I wrote a blog post about some of my experiences with web development in which I have developed a simple library MVC-based library managing the layouts of web applications. The model basically encapsulates the structure of a web applications from an abstract point of view, but it only applies to a specific sub concern, not the system as a whole.
Despite its unclarities and ambiguities, I still think MVC makes sense, for the following reasons:
- View and controller code clutters the model with obfuscations making it much harder to read and maintain.
- There are multiple ways to present an object visually. With a clear separation between a model and view this becomes much more flexible.
- In general, more compact modules (in terms of lines of code) is many ways always better than having many lines of code in one module (for example for readability and maintainability). Separation of concerns stimulates reduction of the size of modules.
The Titanium and Alloy frameworks
As explained earlier, I have implemented the chat example app using the Titanium and Alloy frameworks.
Titanium is a framework targeting multiple mobile app platforms (e.g. Android, iOS, Windows and mobile web applications) using JavaScript as an implementation language providing a unified API with minor platform differences. In contrast to platforms such as Java, Titanium is not a write once, run anywhere approach, but a code reuse approach -- according to their information between 60 and 90% of the code can be reused among target platforms.
Moreover, the organization of Titanium's API makes a clear difference between UI and non-UI components, but does not impose anyone to strictly follow an MVC-like organization while implementing an application.
Alloy is a declarative MVC-framework that wraps around Titanium. To cite the Alloy documentation:
Alloy utilizes the model-view-controller (MVC) pattern, which separates the application into three different components:
- Models provide the business logic, containing the rules, data and state of the application.
- Views provide the GUI components to the user, either presenting data or allowing the user to interact with the model data.
- Controllers provide the glue between the model and view components in the form of application logic.
(As may be noticed, the above description introduces yet another slightly different interpretation of the MVC architectural pattern.)
The Alloy framework uses a number of very specific technologies to realize a MVC organization:
- For the models, it uses the backbone.js framework's model instances to organize the application's data. The framework supports automatic data binding to view components.
- Views use an XML data encoding capturing the static structure of the view. Moreover, the style of each view is captured in TSS stylesheet (having many similarities with CSS).
- The controllers are CommonJS modules using JavaScript as an implementation language.
Furthermore, the directory structure of an Alloy application also reflects separation of concerns. For example, each unit of an application stores each concern in a separate directory and file. For example, in the chat app, we can implement each concern of the contacts screen by providing the following files:
./app/views/contacts.xml ./app/controllers/contacts.js ./app/styles/contacts.tss
The above files reflect each concern of the contacts screen, such as the view, the controller and the style.
In addition to defining models, views, styles and controllers on unit-level, the app unit captures general properties applying of the app.
Organizing the example chat app
Despite the fact that the Alloy framework facilitates separation of concerns in some degree, I still observed that keeping the app's code structure sane remains difficult.
Constructing views
An immediate improvement of Alloy over plain Titanium is that the view code in XML is much better to read than constructing UI components in JavaScript -- the nesting of XML elements reflects the structure of the UI. Furthermore, the style of the UI elements can be separated from the layout improving the readability even further.
For example, the following snippet shows the structure of the login screen:
<Alloy>
<Window class="container">
<ScrollView>
<View>
<Label>Web socket URL</Label>
<TextField id="url" hintText="ws://localhost:5280/websocket/" />
</View>
<View>
<Label>Username</Label>
<TextField id="username" hintText="sander" />
</View>
<View>
<Label>Domain name</Label>
<TextField id="domain" hintText="localhost" />
</View>
<View>
<Label>Resource</Label>
<TextField id="resource" hintText="" />
</View>
<View>
<Label>Password</Label>
<TextField id="password" passwordMask="true" hintText="" />
</View>
<Button onClick="doConnect">Connect</Button>
</ScrollView>
</Window>
</Alloy>
As may be observed, by reading the above code fragment, it becomes quite obvious that we have a window with a scroll view inside. Inside the scroll view, we have multiple views containing a label and text field pair, allowing users to provide their login credentials.
Although implementing most screens in XML is quite straight forward as their structures are quite static, I have noticed that Alloy's technologies are not particularly useful to dynamically compose screen structures, such as the contacts overview that displaying a row for each contact -- the structure of this table changes whenever a new contact gets added or an existing contact removed.
To dynamically compose a screen, I still need to write JavaScript code in the screen's controller. Furthermore, UI elements composed in JavaScript do not take the style settings of the corresponding TSS file into account. As a result, we need to manually provide styling properties while composing the dynamic screen elements.
To keep the controller's code structured and avoiding code repetition, I have encapsulated the construction of table rows into functions.
Notifying views for changes
Another practical issue I ran into is updating the UI components when something changes, such as a receiving a text messaging or an updated status of a contact. An update to a backbone model automatically updates the attached view components, but for anything that is not backbone-based (such as XMPP's internal roster object) this will not work.
I ended up implementing my own custom non-backbone based data model, with my own implementation of the Observer design pattern -- each object in the data model inherits from the Observable prototype providing an infrastructure for observers to register and unregister themselves for notifications. Each view registers itself as an observer to the corresponding model object to update themselves.
The app's architecture
In the end, this is the architecture of the example chat app that I came up with:
The UML diagram shows the following aspects:
- All classes can be divided into four concerns: controllers, views, models, and utility classes. The observer infrastructure, for example, does in my opinion not belong to any of the MVC-categories, because they are cross cutting.
- The XMPPEventHandler is considered to be a controller. Despite not triggered by human actions, I still classify it as such. The event handler's only responsibility is to update the corresponding model objects once an event has been received from the XMPP server, such as a chat message.
- All model objects inherit from a custom-made Observable prototype so that views can register and unregister themselves for update notifications.
- Views extract information from the model objects to display. Furthermore, each view has its own controller responding to user input, such as button clicks.
Lessons learned
In addition to porting an XMPP library from the Node.js ecosystem to Titanium, I have also observed some recurring challenges when implementing the test application and keeping it structured. Despite the fact that the Alloy framework is MVC-based, it does not guarantee that your application's organization remains structured.
From my experiences, I have learned the following lessons:
- The roles of each concern in MVC are not well defined, so you need to give your own interpretation to it. For example, I would consider any controller to be an object responding to external events, regardless whether they have been triggered by humans or external systems. By following this interpretation, I ended up implementing the XMPP event handler as a controller.
- Similarly for the models -- the purpose of backbone.js models is mostly to organize data, but a model is more than just data -- from my perspective, the model encapsulates domain knowledge. This also means that non-backbone objects belong to this domain. The same thing applies to non-data objects, such as functions doing computations.
- You always have to look at your structure from an aesthetic point of view. Does it makes sense? Is it readable? Can it be simplified?
- Finally, do not rely on a framework or API to solve all your problems -- study the underlying concepts and remain critical, as a framework does not always guarantee that your organization will be right.
Within the scope of Titanium/Alloy the problem is that models only make sense if you use backbone models. Using XML markup+TSS for views only make sense if your screen structure is static. The most logical outcome is to put all missing pieces that do not classify themselves into these categories into a controller, but that is probably the most likely reason why your code becomes a mess.
As a final note, the lessons learned do not apply to mobile applications or Titanium/Alloy only -- you will find similar challenges in other domains such as web applications and desktop applications.
