XPages Mobile Controls and Value Pickers Part One: Mobile Development Approaches

Over the last week I’ve come across a couple of requests for some sort of typeahead or Name Picker or Value Picker for mobile. There was a question on Stack Overflow and another query came from an alternate discussion. I will outline my preferred option in my next post, but first I want to add some background on what I consider are the differences between browser and mobile browser development methodologies.

Pickers and typeahead functionality work well in a browser environment, which is heavily reliant on server-side functionality. Partial refreshes abound in XPages and one of its major strengths as a RAD tool is the ease with which AJAX functionality can be made available. Even in an environment with high latency, browser connectivity is relatively reliable. The issue is: “how can the size of traffic between server and client be minimised?” There are a number of options for this, as I discussed in my recent session at BLUG which I will be expanding on at DanNotes – using loaded instead of rendered, using execMode=”partial” with an execId, using partial instead of full page refresh, combining controls.

However, when it comes to mobile development, in many cases the issue is different. On a mobile browser I regularly come across issues where connectivity drops and I have to resubmit a request. Anyone who attended Lotusphere this year or various LUGs will have on some occasion found that wifi dropped. This is one of the reasons for developing offline mobile applications, whether using HTML5, something like Appcelerator, or a tool like Teamstudio Unplugged. But if you’re building for a mobile browser, the issue becomes “how can the frequency of traffic between server and client be minimised?”

A brief perusal of the XPages Mobile Controls provides subtle evidence of this, particularly if one uses the Discussion XL template as an example. The mobile interface is a single XPage, encapsulated by a ‘dynamic content’ control that is the Single Page Application. Each ‘page’ is a Mobile Page and navigation is done by switching between those pages.My use of terminology is deliberate here, because the intention is where possible to switch between pages on the mobile client, not retrieve a page from the server.

The Mobile Page control has a property resetContent which, by default, is set to false. This means that if the user returns to a ‘page’ they have previously visited then, by default, the content is just redisplayed. There is no partial refresh to the server. It is a client-side event to effectively hide on area of the page and display another. There is another property preload which can be used to preload a Mobile Page so that a call to the server is not required. Adding content to a Mobile Page view is generally done with a client-side “Add rows to a data iterator” (xe:addRows) control which has a setting to save the state. This can be used to reduce the need to repeat the paging.

If you compare the mainTopic and the mobile_newTopic Custom Controls in the Discussion XL template, this desire to minimise calls to the server is evidenced still further. The browser version uses an inputText control with typeahead. The mobile version uses an inputText control without typeahead.

The whole approach of mobile browser development is to do as much as possible on the mobile client rather than run the gauntlet of connectivity to the server. This is also why defaults are to minimise the amount of content passed to the browser (so, for example, the tundra stylesheet is not passed to a mobile browser by default) and why defaults do not reload content from the server. This is also why one might choose mobile-specific design rather than using a cross-over pattern of development, using the same custom control for browser and web. More importantly, this is why mobile user interfaces may often provide a subset of browser functionality or different functionality.

And all this is without addressing the smaller screen real estate on a mobile phone (tablets have a bit more, but the XPages Mobile Controls do not yet cater specifically for tablets, so I’m excluding that from this article).

So, how do we provide typeahead or picker functionality on a mobile browser?

I’ll come onto one option in my next post.