Phonegap Bridge – File System CIS 136 Building Mobile Apps 1

Building greatness Starting your app project 2

Building Greatness 3

Ideas 4  Bill Splitter  Money tracker  Where I his it  Saving passwords  Storyteller  Quiz/Flash Card  Alcohol App (driving below the legal limit)  Diary  Garden growth  Song Lyrics  Name that Tune  Bus Info  Golf Scores

Before you begin 5  Define parameters for the app  Narrows down the scope  Formulates ideas for wireframes  Guidelines for its functions  Understand what it needs to accomplish

Pre-Development Q&A Question Answer 6  What is the app called?  Who will use the app?  Why will they use the app?  What are the key features of the app?  My favorite Locations  Anyone, but probably people over the age of 10  To see some of my favorite spots and maybe visit them as well  Map overview with pins showing locations I tag; popups describing why they are my favorites, a button to indicate they agree with the choice

Pre-Development Q&A Question Answer 7  What technologies are required to implement the apps’ features  GPS, a database somewhere, probably some user tracking

Outcome of Q&A 8  Design ideas and details  Icons to use  Color scheme  Platforms to target  Scope creep  Administrative side to app  Add new places  Take pictures  Add data fields A place to start

MVP 9  Minimum viable product  Approach development with an eye on iteration  Develop critical pieces  Develop necessary functions  Defines the “blurry” line between a timely, cost-effective release vs. a release catering to desired audience that is a money pit and overly complex

Handling scope creep 10  Audience wont care about administrative side  Consuming outputs  Less moving parts  Speed through development faster with a more “lean” first version  Less time needed to product the app  Gauge overall interest in the app

Don’t toss in the towel 11  Create a “parking lot”  A place to save the great ideas for the next version  Include elements that come to mind for marketing, sales, etc.  Plan for the “next big feature”  Calendarize the nex big offering

User Stories 12  Helpful to understand the user experience  What the user will hear, see, do while interacting with the app  Won’t overlook key features  Describe who is doing what, and what the result is  Single sentences that dictate a small aspect of the intended functionality

User Story Example 13  As a user of the My favorite Locations app, I can login to the app using my address and a password. Once logged in I can scroll through ha list of places that are displayed and pick any of them. When I pick one, I can see a picture of the place and some information about it, including an address. If I click on the address, it will load the map on my phone so I can get directions to go there

Architectural definition 14  Clear blueprint for what needs to be developed  Consists of an:  Overview [here you provide a high level description of what the app will do, who will use it and why they will use it]  Walkthrough [Here you insert bulleted items representing the steps of operation from the moment the user taps the app’s icon. Branching logic should be represented here as well as clear paths to events and important input and output from the app. This will most likely be the largest part of the document] 

Architectural definition (cont.) 15  Databases [Client-side – this is where you define data that will be used by the app. Tables should include ID, key and value] [Server side – define the tables and fields that will be used, as well as the web services{proxy} for moving the data back and forth  Web Services [Here you can provide a breakdown of web services your app will use – service: what it does inputs: what it expects for data outputs: what it returns for data]

Storage Options 16

Storage Options 17  Many storage API’s  Local Storage  Web storage, simple storage, session storage  Based on key/value pairs  WebSQL (android, blackberry, iOS)  full-featured database tables accessed via SQL queries  IndexedDB (windows, blackberry)  more features than LocalStorage but fewer than WebSQL  HTML5  Plug-in Based  File API - allows you to cache data on the local file system  Downloader - Downloads files to persistant Storage  SQLLite - use more storage and provides more flexibility than the standard Web SQL database

Local Storage 18

Local Storage 19  Permanent – localStorage() method  Data is saved even when app is closed  Temporary – sessionStorage() method  Data is not saved when app is closed

Methods 20 Works off of key/value pairs  Note: can serialize data using json.Stringify method  Set a key - Returns the name of the key at the specified position  var keyName = window.localStorage.key(0);  Set an item - Assigns a keyed item's value  window.localStorage.setItem("key", "value");  Get an item - Returns the item identified by the specified key  var value = window.localStorage.getItem("key");  Remove an item - Removes the item identified by the specified key  Window.localStorage.removeItem("key");  Clear - Removes all of the key/value pairs  Window.localStorage.clear();

21 // Wait for device API libraries to load document.addEventListener("deviceready", onDeviceReady, false); // device APIs are available function onDeviceReady() { window.localStorage.setItem(“hobby", “sailing"); var keyname = window.localStorage.key(0); // keyname is now = “hobby" var value = window.localStorage.getItem(“hobby"); // value is now = “sailing“ var value2 = window.localStorage.getItem(keyname); // value is now = “sailing" window.localStorage.removeItem(“hobby"); window.localStorage.setItem(“hobby2", “riding"); window.localStorage.clear(); // localStorage is now empty }