I started off this tutorial series on mobile value picker with a discussion about some key differences between desktop browser development and mobile browser development. One of the key differentiators I discussed was connectivity. That was why this series has so far focussed on an approach that predominantly used Client-Side JavaScript and avoided interaction with the server as much as possible.
But when I first discussed the approach with David Leedy many weeks ago, his requirement was somewhat different. The users of his mobile application would always be connected; they would not be roaming; so connectivity was not an issue and avoiding server-side interaction was not a concern. I am sure his situation is not unique, so I have followed his advice and am going to cover a server-side approach.
The first thing worth noting is on the “user” mobile page itself. I’m going to jump to this because it will impact the changes for the rest of the XPage. Whereas for the client-side approach the default setting of resetContent=”false” was used, for the server-side approach the mobile page will take the setting resetContent=”true”. As a result, I also need to change the dominoDocument datasource settings. Because resetContent is true, I need to ensure the mobile page knows which document I’m dealing with when I switch to the value picker and come back. So the action property is “editDocument” instead of “newDocument” and the documentId is set to “#{viewScope.documentId}”.
As a result, there need to be two changes to the New User button and the links in the view of existing users. The first is that I’m not using the queryString and don’t have to forceFullRefresh. So the “Move To App Page” simple action just switches to the “user” mobile page. The second change is I need to set viewScope.documentId – to null on the New User button (code shown below) and to the current entry’s ID in the view.
On the Submit button on the user page, I then need to clear viewScope.documentId.
For the Select State button, previously I used Client-Side JavaScript to switch to the stateSelector mobile page. I’m assuming good connectivity, so I use a Server-Side event – again the “Move To App Page” simple action.
The final change is on the link for each state. Again, I’m assuming good connectivity, so using the “Move To App Page” simple action to switch back to the user page. I’m also executing Server-Side JavaScript to run getComponent(“inputText3”).setValue(state.getColumnValue(“Key”)). So I’m setting the value directly in the component before switching back to the mobile page. Because it’s in the same XPage, I can do that.
So the differences are very minor, but all highlighting the different approach – the first avoids server-side events as much as possible, the second embraces them. I’ve attached the code below, and if you want to compare them, I would strongly recommend that after you add the XPage to the sample application, you go to the Project Explorer view and navigate to the two XPages. Select them both (holding down Ctrl), right-click and select Compare With – Each Other….
