| Issue 2, 2013 | Download pdf |
The Expenses Tracker application, included with webMethods Mobile Designer, provides a valuable example for building graphically rich applications within the tool. The project includes solutions to many common problems and offers best practice examples of how to develop within Mobile Designer.
Building Application Icons
|
For specific guidance on the creation of icons and other graphical assets read: |
The Expenses Tracker application is by no means graphically rich, but there are a number of different graphical assets used within the app, ranging from background images to icons, that are available in the project folder.
Application icons are all specific sizes and required for each platform. It is fairly easy to replace the default icons with your own. The application icons used in the Expenses Tracker application can be found in the resources/icons folder. The rest of the graphical assets reside within the resources/graphics folder, and it is here that we will be examining the contents in more detail.
Figure 1: The directory structure within the resources/graphics folder
Figure 1 shows the directory structure with the resources/graphic folder. There are three folders that relate to individual platforms: AND, iOS and WPh. The fourth folder, GENERAL, contains resources that are used on multiple platforms.
The platform folders contain graphics that are specific to an individual platform. In this example, the icons that are used to illustrate the category of each expense item. Icons on iOS tend to be dark and icons on Android are lighter (as the default background is dark). For Windows Phone, both light and dark icons are supplied as both light and dark themes are supported at the OS level.
Multiple resolutions are often required on some platforms. This is handled on iOS by supplying resources at one size for non-retina devices and at double the size (dpi) for those with retina screens. For Android, the issue of varying resolutions is handled via the use of different dpi images. More details on the specifics of this can be found in the Tech Community article mentioned in the sidebar.
Each folder within the general folder relates to a specific element within the application. For example, the login folder contains images used in the login screen of the application. Multiple versions of each image, at different sizes, reside in various sub-directories.
The application decides which image to use based on the space available. So, in a small screen version of the application, the main logo can be up to 95% of the width of the view. The code checks what this will be, in real terms, based on the view’s actual width in pixels, and then chooses a graphic from the directory nearest, but not larger, in size. On a retina iPhone build, for example, the view is 640px wide. This means the logo can be up to 95% of 640, or 608px maximum. Therefore the logo graphic will come from the w600 folder (w indicates width).
Platform Agnostic Approach
One of the main advantages of using webMethods Mobile Designer is that a developer can create a cross-platform application from a single codebase, without having to worry about individual platform idiosyncrasies. Mobile Designer does a good job of abstracting individual elements (such as buttons) and also deals with broader problems such as containers and views. However, the developer always has complete control over every part of their app and will need to adopt a platform agnostic approach to such things as positioning and sizing of items.
Within the Expenses Tracker application codebase you will find several examples of where elements have been sized relative to the screen or view size rather than by using explicit values.
On the login screen there are several elements to deal with. The driving factor for all of these elements is a value relative to the view width as shown in Figure 2. On the small screen version of the app everything is based on 95% of the view width. On the tablet (or multi-pane) version we use a value of 35% of the screen width. It’s worth noting that the tablet version of this app only supports landscape mode. With rotation another figure would be used for a portrait tablet.
Figure 2: A comparison of the login screen on phone and tablet
Later in the application you will find views that have had their innerx values adjusted. Innerx is a value present on most parent objects (such as views, containers, table cells) that defines the inner padding from the edge of the parent to the edge to any child objects. It is used mainly to stop elements from butting up to the edge of their parents.
Take the Edit Expense Item screen, for example. On the small screen version the innerx values are left at their defaults, but on tablets a little more space is needed to ensure the view is aesthetically pleasing. Rather than setting the innerx to an explicit value, it is set to 5% of the view width.
By using default values wherever possible and relative values when an adjustment is needed, the developer can ensure that the app will remain functional. If, at some future date, a new platform is added that has a markedly different screen metric to those previously targeted, the code will gracefully adapt.