Website:Mobile

From WormBaseWiki
Revision as of 15:16, 19 June 2014 by Sibyl (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

A Backbone.js + jQuery Mobile app for accessing the Wormbase database through its RESTful API.

Directory Structure

wormbase-mobile
├── index.html
├── config.xml
├── css
│   ├── images
├── images
├── js
│   ├── collections
│   ├── libs
│   ├── mobile.js
│   ├── models
│   ├── routers
│   └── views
└── templates
    ├── app
    └── classes

Libraries and dependencies

  • Backbone.js to aid application structure, routing
  • Underscore.js for templating and other utilities
  • Require.js for modular separation of components
  • Require.js Text Plugin to enable external templates
  • jQueryMobile + jQuery for DOM manipulation, mobile helpers
  • Backbone Fetch Cache - modified by me - https://github.com/antonio0/backbone-fetch-cache - used for the purpose of caching of recently viewed elements. My fork allows to keep track of when cache records have been created and last accessed.
  • Spin.js - http://fgnass.github.io/spin.js/ - to make the spinners inside Widget Boxes
  • Pluralization JS library - http://oranlooney.com/js-plural/

Note: This application needs to be run on a HTTP server in order to use external templates.

Use of WormBase REST API

Widgets are requested in text/html format, the response goes through an "enhancer" function which adapts all the links to work within the mobile application, then a few changes to the DOM of each Widget are made in order to make them responsive and improve performance on mobile devices. Those changes are explained on the Widgets Porting page.

For widgets whose structure on mobile devices would need to be implemented in a radically different way, there is the possibility of creating a custom widget by putting a template file into the templates folder (e.g. templates/classes/gene/overview.html). In this case the Widget is requested in JSON format and its fields are available within the template using a 'fields' identifier.

Structure

The App follows a variation of the Model View Controller design pattern. As in all Backbone.js applications, there is no controller because the logic that operates the app is in the View.

The components of the app are the following.

Router

A comprehensive list of all the possible routes that have been implemented so far can be found on the Router page.

Collections

Collections can be thought as list of models. They also handle fetching of data from the server. The detailed list can be found in the Collections page.

Models

There are only a few models for the website as most of the data structures are dynamically constructed using the WormBase API. Consult the Models page for a more detailed list.

Views

Views handle the logic of the app. Each view is associated with a DOM element (some are pages, others are sub-elements of them) and a Model or a Collection. They can be seen as nested elements each of those handling input/output for some part of a web page:

   App View
   |-- Home View
   |-- History View
   |-- Search Page View
   |------ Search Results View
   |---------- Search Result Entry View
   |-- Object View
   |------ Widgets Panel View
   |------ Widgets Area View
   |---------- Widget View
   |-- Browse Species View
   |-- Browse Resources View
   |-- Filtered Search View
   |------ Search Results View
   |---------- Search Result Entry View
   |-- About View

Details about each view are on the Views page.

Initialization

As soon as Backbone gets initialised, a "WBMobile" object gets added to the browser's "window" object.

WBMobile is used in order to keep references to:

  • views: a reference to AppView and all other views which directly represent a page (such as HomeView, ObjectView, etc.). References to views which don't represent a page (like WidgetView) shouldn't be kept here in order to avoid name conflicts when a view is used in more than one page (example: Search Results View is used in both Search Page View and Filtered Search View).
  • routers: in this app there is only one.
  • utils: no need to load our own 'utils' library through require.js on each view that makes use of it
  • defaults: some default strings / objects / settings that are often used within the app

Cordova

App Packages are compiled using the service PhoneGap Build. Those packages can be found here: https://build.phonegap.com/apps/544268/builds

The config.xml file has the purpose of defining the parameters that the Cordova compiler will use to generate app packages, such as the name of the app, its description, icon, screen orientation, external access whitelist and much more. Beware that some of this settings may also be platform specific. For a complete list, refer to the PhoneGap developer documetation, http://docs.phonegap.com/en/3.0.0/config_ref_index.md.html#Configuration%20Reference