2 Days with Domino 9.0.1 Mobile Controls – And I’m not happy

OK, so today is the 2nd day I've spent with the Mobile controls from Domino 9.0.1. I must say the lack of a 9.0.1 Beta is quite obvious. So some of the "improvements" IBM made to the mobile controls are the addition of onBeforeTransitionIn/Out onAfterTransitionIn/Out. While these events are sorely needed, the implementation IBM chose to use doesn't work is kind-of odd.

So, a brief rundown of the transition events pre 9.0.1. I posted a while back about how to implement these methods in your mobile application. Short version is do a dojo.connect to attach to the needed transition event of an appPage. Then in that function make an RPC call to do any server side processing that might be needed. This initiated the following chain of events:

  • An HTTP POST request was sent that ran the RPC Method
  • The page moved to the destination page
  • onBeforeTransitionIn fired a partialRefresh to refresh the content of the destination page

This series of events still happens, kind-of, just not in that order. The events now process in this order:

  • A partialRefresh of the destination page happens
  • An HTTP POST request is sent that runs the RPC method
  • A dojox.mobile.TransitionEvent is fired which is supposed to move to the destination page

If your content is static and not programmatically determined, this is fine. But otherwise this is all wrong. Why is a partialRefresh firing before the POST? The POST is what determines which markup is to be shown on the destination page. With the partialRefresh happening before the POST these events and almost the components are now useless and it breaks any previous implementations of these events.

There is a work around for the moment that works to a point. The only place I've found that it doesn't work is if there is a dataView on the destination page and the dataView's configuration is programmatically determined (works fine if the configuration values are static). The work around is to add a callback to the RPC call with a partialRefresh of the destination page's first child element. Don't even try and use the events defined on the appPage component. So, if you watch the network traffic you'll see a GET then a POST and then another GET. This does however introduce a pretty good performance hit.

I think it's great that IBM listened to the community and added these events. However, it seems pretty obvious that the community wasn't given the chance to find these issues before the release. I think it also shows that these events weren't tested properly in a real world scenario. I guess if the events were called onBeforeBeforeTransitionIn/Out and onBeforeAfterTransitionIn/Out it would've made a little more sense.

Share This: