This article is part of the use case description for Check In:
Overview – Altering the check-in application for mobile browser
The mobile browser version of the check-in application contains similar functionality found in the desktop version, but arranged differently since the screen size is much smaller. In addition to performing a check-in, the application will also be able to capture the user's geographic location.
When we are done with the implementation, we should have an application that looks something like this.
Our sample model is constructed with the view and form builder and its associated theme builder which defines the HTML and CSS. We need to change the HTML used by the view and form for display on a mobile device, and we do this by specifying some entries in a new **portal_mobile.uitheme**.
Let's start by extending the desktop theme file
Use the default WEF mobile RDD and change a few settings
Since the screen on a mobile device can't handle the desktop layout, let's switch things around and use the WEF templates for stacking the check-in entries in a vertical fashion. Note that these are just the templates that WEF provides with the product, but as we've shown in the desktop theme, they can be easily customized if wish to do so.
Builder 5: Action list
Next, we want the user to see the create new check-in interface when they initially access the application from a mobile device. This would be more convenient than seeing the list of existing check-ins and then having to navigate to create a new entry. Let's do that by adding a new main action list that executes **createReport_InputPage**
Since we cannot have two main action lists, let's use the mobile profile set to enable this builder when the access point is a mobile device.
Similarly, let's enable the original **main** action list when the origin is a desktop browser.
Builder 9: View and form
Earlier, we mentioned that we were going to use a different HTML layout that stacks the entries when displayed on a mobile device. This means that we do not want to use paged data display, so we are going to profile that section of the view and form builder for the desktop and remove the paging. Note that we opted to apply the profile on the builder's **paged data display** input field instead of the builder enable as we have done on the other builders in this model. This is mostly a matter of preference, but just about any input field can be profiled.
We also want to use a different template for the data layout builder. First, we copy the following HTML fragment into a new template file **WebContent/data_layout_templates/gov_demo_thumbnail_multiline_list_template.html.**
<meta data-template-id="GovDemoMobileMultiLineList" data-template-name="Govt Demo Thumbnail Multi-Line List" data-style-picker-file-names="/factory/data_layout_templates/base_template_styles.css" data-stylesheets="/factory/data_layout_templates/thumbnail_multiline_e2e_list.css,/factory/data_layout_templates/thumbnail_multiline_border_list.css,/factory/data_layout_templates/thumbnail_multiline_e2e_list_without_arrow.css,/factory/data_layout_templates/thumbnail_multiline_e2e_list_dark_background.css,/factory/data_layout_templates/thumbnail_multiline_e2e_gradient.css,/factory/data_layout_templates/thumbnail_multiline_e2e_list_with_wrapping_text.css,/data_layout_templates/gov_demo_thumbnail_multiline_e2e_list_without_arrow.css,/data_layout_templates/gov_demo_multiline_center_only_e2e_list_without_arrow.css,/factory/data_layout_templates/blank.css" data-stylesheet-root-class-names="wpfThumbnailMultiLineListE2E,wpfThumbnailMultiLineListBD,wpfThumbnailMultiLineListE2ENA,wpfThumbnailMultiLineListE2ED,wpfThumbnailMultiLineListE2EG,wpfThumbnailMultiLineListE2EWT,wpfThumbnailMultiLineListE2ENAGovDemo,wpfThumbnailMultiLineListE2ENACOGovDemo,wpfThumbnailMultiLineListBlank"/>
<div name="layout_list" class="">
<div class="wpfListItem" name="list_item" data-repeat-wrapper="default">
<div data-target="left_image" class="wpfLeft"></div>
<div data-target="center_top" class="wpfCenter"></div>
<div data-target="center_middle" class="wpfCenter wpfCenterWrap"></div>
<div data-target="center_bottom" class="wpfCenter"></div>
<div data-target="right_middle" class="wpfRight"></div>
Let's also add a new data layout builder that references the template we just created and map the fields like we did in the desktop version.
Note that the enable builder input is profiled for mobile device, we also want to profile the original data layout builder such that it is enabled for desktop so only one is active at any time.
Builder 12: Attribute setter
The pictures captured at the time of check-in look great on the desktop, but when accessing the application from a mobile device we'll want to scale those down to a more manageable size. We can do this by copying the original attribute setter builder and changing the max-height attribute to 200.
Again, we will profile this builder such that it is enabled for mobile and profile the original builder for desktop. Small picture for mobile, bigger picture for desktop.
When executing on a mobile device, the application has the ability to capture the user's geolocation. The application also contains a service provider model that manages landmarks, which is little more than a collection of named latitude and longitude points. The captured geolocation information is used to find the closest landmark which is then added to the check-in entry.
First, we need to add a geolocation builder to our model and select the input page as our target since that is when we want to capture the location.
This script will ask WEF to capture the HTML5 geolocation for us and make it available when we handle it a client event handler builder.
var latInput = document.getElementById("LATITUDE");
latInput.value = this.geoLocation.latitude;
var lonInput = document.getElementById("LONGITUDE");
lonInput.value = this.geoLocation.longitude;
Rearrange some elements
In the desktop version of the application we placed the refresh button at the top of the scrolling carousel of entries. On a mobile device the entries are stacked and at the bottom we have a button to create a new check-in. Let's move the refresh button to the bottom as well so the user doesn't have to go looking for it. Using the same technique we've applied above, we can create a copy of the button builder from the desktop version and change the tag page location.
We will also want to profile the original button builder for desktop.
In this article we have shown how a WEF application designed for display on desktop can be tailored for the smaller display of a mobile device. We also changed the behavior of the application by displaying a different initial page that allows the creation of a new check-in entry. All of this is done through dynamic profiling.
As is the case for most software development, there are many ways to approach and solve a problem. Profiling in WEF can be applied at many different levels – on builder input detail, the builder input or simply on the builder enable which turns the whole builder on or off. There is no right or wrong choice, it is mostly a matter of preference, but it is generally good development practice to keep things simple. If we encounter a case where several inputs on a builder need to be profiled, maybe it makes more sense to simply enable/disable the whole builder with a profile. In our case we mostly chose to copy the entire builder and profile the enable input, this makes it easier to follow even if it means replicating some of the builder inputs.
This article is part of the use case description for Check In. To access associated article, use the links below: