Skip to content

Home

Jump to bottom
Ken Manheimer edited this page Jan 25, 2013 · 18 revisions

Table of Contents

SpiderOak Mobile Client Development Orientation

In the interest of helping others take on development of this application, we'll be including details and pointers that we found useful in our own effort, beyond the installation and basic development instructions found in the app repository's README.md. We do assume some acquaintance with the fundamental web elements - HTML5, Javascript, CSS, HTTP, JSON, and so forth.

Early building and debugging instructions assume a Mac development platform.

Fundamental Infrastructure

The SpiderOak Storage Server Web API
The app is client of the SpiderOak storage servers via this API.
Web Storage API JSON Data Structures structures
Representative examples of some of the JSON data to expect from the server.
Backbone.js
An MVC / MVVM framework for javascript applications, we build our architecture around it.
Jasmine.JS and Sinon.JS
Jasmine provides a Behavior-driven development (BDD) software test-driven development framework, and Sinon provides a spying, stubbing and mocking library that complements Jasmine for easy construction of tests. Testing Backbone applications with Jasmine and Sinon provides an excellent introduction.

Establishing The Development Environment

Install the sources by cloning the repository: 

   git clone [email protected]:SpiderOak/SpiderOakMobileClient.git

See the distribution's README.md.

  • Install the facilities listed in the "Requirements" section (and follow the links for details about these facilities).
  • Follow the steps in the "Getting started" section to install the internal facilities.
npm install
npm follows the package specifications in package.json .
bower install
Bower obeys the distribution root .bowerc file to install the ingredients specified in the components.json file into the www/components directory.

Running and Testing the App

Grunt is our operations command facility. grunt.js in the top of the distribution provides the recipes for its tasks. Automation with grunt is also key to our continuous integration setup, at Travis CI.

  • grunt --help lists the recipe tasks and other options.
  • grunt test run the tests in a headless webkit browser (Phantom JS)
  • grunt debug_ios [Mac only; requires recent Xcode]) run the code in the iOS simulator
  • grunt debug_android like debug_ios, but for android [not yet implemented?]

Development Workflow Model

We like the github-flow development model. Our continuous integration facility will notify us promptly (and irritatingly (-: ) about errors in the master. Our aim is to avoid them, so that anyone can fork the master at any time for a working copy of the app.

Essentially:

  • Do all work in a feature branch specifically for that work
    • Frequently push your feature branch to the origin, so nothing is lost if your workstation fails
    • Periodically merge updates to the origin/master to your branch, if your work lasts a while
  • When ready to merge, submit a pull request. This enables others to review your changes, which is suitable for everything except very small changes.
  • When the changes are well assured, someone resolves the pull request and the feature becomes a part of the master.
Clone this wiki locally