Last time I covered Notes Client and XPages modernisations. In this blog post I’ll cover Domino Mobile Apps enhancements. DMA is already available on iPad, with Android and iPhone to follow. You can use a Notes Client application on mobile with no changes. My personal view is that if you just hand it over, without review, without modernisation, without consideration, you’re doing it wrong. A mobile device is not the same as a desktop computer, neither is a touch-enabled device like Windows Surface tablet. Nor is the method of use the same. On a desktop computer you regularly have an application open, working in it, all day. On a mobile device you rarely stay in the same app for long, and the mode of use is open, do what you need to, and move on – quickly. A 70Gb database can work fine on Domino 10 (remember the limit has been increased to 256Gb), but that’s jut not feasible as a local database on a mobile device and users of a mobile device will typically need a local replica, if only for better performance.
So it’s time to modernise. The slides from my session go into more depth on the thinking behind what was modernised. But I’m only adding a mobile interface to Contacts. States shouldn’t need to be exposed: they’re preloaded, are unlikely to change, and if they need to it can be done in a Notes Client. Mobile needs to be streamlined and modernisation should bear that in mind.
First off, the launch properties open a Frameset. But if you open the Notes Client, you won’t see a Frameset. Why? It launches a frameset which loads another frameset, and the inner frameset is computed to @If(@Platform = "iOS";"mobile";"FAIL"). On a desktop that throws an error, so no frameset gets loaded – the same experience you historically see with the XPages Extension Library Demo database.
The other key part that happens when you open the database is the Postopen event in the Database Script. All the scripts for mobile are in a central “mobileScript” Script Library. The Postopen stores some environment variables if we’re opening the server replica – the server name and two undocumented properties for the hostname and filepath. They’ve always been undocumented but with DMA and LotusScript HTTP Request methods, there’s a new reason to need them, to avoid hard-coding the values. If you see the value of them, up-vote this idea in the Aha portal. Obviously the first time we open the database on the mobile device, we’ll open the server replica. That will set the environment variables. Then we’ll create the local replica, but we still have the environment variables for the URL of the server database.
The “mobile” Frameset has two frames. The “percent” size changes depending on portrait / landscape and whether the keyboard is visible. I’ll leave that as a little teaser for you to solve. The top frame is the “Nav” form. The bottom is computed, depending on an environment variable set in the top frame. Let’s look at the top frame first.
SaveOptions field is set to “0” to prevent prompts to save. For viewSelect field, using a combobox with native OS style gives us a drop-down that feels like the iPad but allows us to check “Run Exiting/OnChange events after value change” on the Advanced (beanie) tab of the properties. Dialog boxes don’t give that option. This means we can run code when the user chooses a value. The code we run is again in the “mobileScript” Script Library, the exitViewSelect function. It depends on the value selected. If it’s “By Name” or “By Surname”, we set an environment variable for the relevant view to open and reload the window to display that view in the bottom frame. Things get more sophisticated for “By State”. Now we set the environment variable to the “mbContactsState” view, but load the “statesView” form in the bottom frame.
Going back to the bottom frame in the “mobile” Frameset, that just picks up the previously set environment variable to do the same thing – open the “mbContactsName” view, “mbContactsSurname” view or load the “statesView” form. This means we’re retaining the state for the device. Historically I doubt many if any) have done that for Notes Client. But for web we’ve expected it and on a mobile device we also expect it. And it’s not rocket science – a little tricky, maybe, but with a simpler interface on mobile, it’s not overly convoluted.
The views are pretty straightforward. They have a different look and feel, specifically for mobile. Hopefully that makes it feel a little fresher. We also pre-load the search bar in the Postopen, which we can do for a normal view. It has a Form Formula, if you wanted to open it in a normal new tab. But this is a small form, so what actually happens is in the Queryopendocument. We get the selected document and open it in a dialog box. This gives a more streamlined user experience and, because of the size of the form, it works fine. Note also that in this mobile interface the application is read only.
Things get more complicated if you select “By State”. As well as the “statesView” form opening, additional fields get displayed, to select state and city. City allows “All” or a specific city. One last point is that there is a very small text field on the “Nav” form. I found that there were problems with uidoc.currentField not getting set on iPad if there were just comboboxes. It’s been reported, but this is a workaround.
Again, on exiting the state and city fields, we set environment variables, for state persistence and also so the “statesView” form can use the values that have been set in a different, unsaved form in a different frame. The “statesView” form pulls those in and concatenates them for the stateCity field. I think I had problems using the environment variables directly in the embedded view’s “Show single category” property, but that may have been cause by uidoc.currentField not getting set. The Postopen refreshes the document, so the view’s single category displays. You’ll notice we don’t have a search option here. I don’t think you can have a search bar for an embedded view. But the whole point of the filters is that you should be displaying just a handful of documents. So you shouldn’t need to search. The other views encourage you to search. So whether you search or filter, the intention is to quickly get to the document you want and move on. And by using a top frame and comboboxes, the intention is to minimise whitespace needed for view options and maximise the screen real estate for data.
The final part is the button in the “statesView” form – “Email Me Contacts”. How do you do an export on a mobile device? You can’t interact with Microsoft Office, as you do on a desktop. You can’t post an Excel spreadsheet in a web page response to “download” it. And you don’t want Microsoft Office on the server. What we do instead is call emailExport function in the script library to use the new NotesHTTPRequest (DMA will definitely have it available), building the URL from the environment variables set in the Postopen the first time the application was opened, and calling the XAgent EmailContacts.xsp. That’s the one I mentioned in the previous part, an XAgent that’s not intended to be called from XPages. We’re calling it from DMA and it re-uses the Apache POI code to generate the spreadsheet for the state and city selected, and email it to the person logged into DMA. It means the application has to be anonymous access, or the XAgent needs to be in an application that’s anonymous access, or we need to pass credentials. But even with anonymous, we’re passing a secret key that the XAgent is validating. There are a variety of options, and others not discussed here, if you think outside the box.
All together it gives a DMA interface and experience that’s very different to the Notes Client application and – even with the quirks I had to overcome – doesn’t take a significant amount of time to develop what looks like a simple, single page mobile application.
In the final part I’ll cover modernising the most modern of interfaces.
