Version 23 (modified by Fran Boon, 12 years ago) ( diff )


Mobile Portal

Table of Contents

  1. Status

Provide a simple portal for access from devices with low bandwidth/screen sizes/ CPU.

  • should also support Touch events

This acts like the '/m' version of popular websites.


Theme which works well on both Desktops & Mobiles:

We need to :

  • Detect that a mobile device is being used
  • Provide an optimised screen size & navigation
    • Could use the existing RESTlike CRUD controller's ?format=plain to generate lightweight forms.
  • Work on low-bandwidth/high latency



jQuery Mobile

Bandwidth savers:

Use far-future cache expiration headers. This will prevent the browser from having to send a conditional GET request. Try to limit HTML pages to 25.6KB or less if you want them to be cached, since the previous tests showed that this limit—imposed by iOS 3.2 on the iPad—was the lowest HTML resource limit of the devices tested. Keep CSS and JS components under 1MB. Of course, 1MB is enormous and your components should be much smaller than this, but don’t bother splitting a component into separate requests for the sake of cacheability unless its size approaches 1MB. Consider using the HTML5 application cache if it’s important that your components persist in the cache for a long time, or across power cycles.

Mobile Emulators:

Status boolean is populated by a quick check on the Browser in models/

  • Currently disabled as unused & slows system down

session.s3.browser Storage of capabilities is populated by a detailed check on the Browser in models/

These can be used to direct to appropriate pages - e.g. assess/create goes to assess_short_mobile

The values to be populated in session.s3.browser has to be set in features (an instance of storage) in models/ under definition of populate_browser_compatibility() function.

Could we have a Mobile Theme which we activate for Mobile Users?:

Note: See TracWiki for help on using the wiki.