If you have an existing Web-based application that has been developed for a typical desktop PC that is always connected to the Internet, you can be fairly certain that it will not work nicely as an M-Business channel without some major changes.
One approach to finding out what needs to be reworked is to create a channel for the application as it exists, then synchronize and see what does not work. You can use the checklist below as a guide to specific things to look for.
Login is problematic.
You always have to synchronize twice—once to log in, and then once more to get updated pages. You can solve this by increasing the timeout value for cookies coming from mobile users. On a connected desktop, 20 minutes without user activity might be a reasonable time to expire a cookie. On a mobile device that synchronizes periodically, the expiration time for cookies should be set to just a little more than the normal time between synchronizations. If the same Web server will be receiving requests from both desktop and mobile users, use the HTTP headers to distinguish between these groups and set cookies accordingly.
Logout links will exit.
If you have a logout link within the application, your users will simply never get the application. As M-Business Server spiders through the links within your channel's Link Depth, encountering a logout link causes a logout. So you must remove all logout links.
Pages linked to through JavaScript will not be downloaded.
Locate any links implemented through JavaScript and replace them with regular HTML <a href=...> links.
Pop-up windows implemented through JavaScript will not be available.
You will have to redo these as <div> units that can be hidden and displayed by JavaScript.
Links that should open in a new window open in same window.
If this is a problem, add a prominent link to return to the previous page.
Synchronizing is painfully slow, some pages are not downloaded, or size of downloaded content is much larger than expected.
Take a close look at your channel Web site design, in terms of your Link Depth and Follow Offsite Links settings. You may need to redesign your site so that you can set a Link Depth value that does get all the important pages but does not bring in unnecessary pages. If you have Follow Offsite Links set to Yes, you can design your site so that your links offsite pages return only the specific pages that you link. See Preventing download of unwanted pages with Follow Offsite Links.
Some channel pages are not downloaded.
There are a variety of possible causes for individual pages not being available. See Channel troubleshooting and debugging tips.
Application state is indeterminate—application logic locks up.
If your application depends on values stored in cookies to determine what the user can do next, these values are not available on device. To maintain an application state, you will have to store values locally. See Maintaining the application state.
Record updates must be submitted as forms with session state information. Forms by nature are contextless. We have found that users will typically submit the prior values and the current values to understand the state of the device at the time of last synchronization and the proposed values. An application will then compare the prior values with the current values from the back-end and, if they are the same, the conclusion is that the back-end has not been modified and the application can safely apply the modifications from the device. Otherwise, there is the potential for a conflict.
Data that should be available is not, unless user synchronizes again.
Any data that needs to be available without requiring the user to synchronize again must be stored on the device. See the chapter for the on-device data solution you are using:
External style sheets do not work.
External style sheets are not supported. In most cases, M-Business Client will do an acceptable job of page rendering on the mobile device without style sheets. Where CSS is critical, as in use with JavaScript to hide and display elements, you will have to convert any CSS external style sheets into internal style sheets or in-line markup.
Users must scroll horizontally to see full content.
Content designed for desktop browsers frequently fixes page width at somewhere around 500 pixels, to control some aspect of the layout. On a mobile device. you have to let M-Business Client render the page to fit the device screen and find other solutions to layout issues that the fixed width solved on the desktop.
Some pages look too cluttered on the mobile device.
With a much smaller screen, come of the content that seemed important enough to include in the desktop version simply isn't worth including in the mobile version. Look for things you can leave out because they aren't really that critical.
Some pages are just too big on the mobile device.
With a much smaller screen, vertical scrolling can become a problem on a mobile device when it was not a problem on the desktop. You can either add frequent links to the top of the page, or split the page into multiple, shorter pages.
Some pages look OK on one mobile platform, but not on another.
If allowing M-Business Client to render pages still leaves some pages looking bad on some platforms, consider optimizing the content of those pages for different platforms.
Selecting from long list or setting date/time is awkward when form is on small screen.
If the smaller screen size makes selecting an item from a long list awkward, implement the List Viewer widget—see Using the List Viewer. If your calendar pop-up to help specify a date doesn't work well in the small screen, implement the Date/Time Picker widget—see Using the Date/Time Picker.
| Send feedback about this page using email. | Copyright © 2008, iAnywhere Solutions, Inc. |