210 likes | 334 Views
Coursework 2 implementation options. Chris Greenhalgh G54UBI / 2011-03-02. Contents. Target device( s ) Implementation options Supported: Google AppInventor , HTML/JS, PhoneGap , Android Java (native) App Unsupported: Titanium mobile, other native app Sensor options Summary.
E N D
Coursework 2 implementation options Chris Greenhalgh G54UBI / 2011-03-02 Chris Greenhalgh (cmg@cs.nott.ac.uk)
Contents • Target device(s) • Implementation options • Supported: Google AppInventor, HTML/JS, PhoneGap, Android Java (native) App • Unsupported: Titanium mobile, other native app • Sensor options • Summary Chris Greenhalgh (cmg@cs.nott.ac.uk)
Target device(s) • Android is the only supported target platform • Freely available tools • Freely available emulators Chris Greenhalgh (cmg@cs.nott.ac.uk)
Implementation options… Supported Unsupported Titanium mobile Other native app • Google AppInventor • HTML/JS Browser App • PhoneGap • Android native (java) app Chris Greenhalgh (cmg@cs.nott.ac.uk)
Option 1: Google AppInventor • Creates simple Android apps • Drag’n’Drop UI builder • Scratch-like visual programming • Web tool plus local tools (JNLP) • Requires Google account http://appinventor.googlelabs.com/about/ Chris Greenhalgh (cmg@cs.nott.ac.uk)
Option 2: HTML/JS Browser App • Dynamic web pages • HTML layout • CSS styling • JavaScript behaviour • Compatible with many devices • Limited low-level/sensor access • Various tool(s) • E.g. Eclipse Chris Greenhalgh (cmg@cs.nott.ac.uk)
Option 3: PhoneGap • Converts HTML/JS apps to installable phone apps • Compatible with many devices • Better low-level/sensor access • Option for native extensions • Requires app build • Eclipse for Android http://www.phonegap.com/ Chris Greenhalgh (cmg@cs.nott.ac.uk)
Option 4: Android Native (Java) App LIMITED SUPPORT • Creates Android apps • OO Java framework specific to Android • Limited DnD UI builder • Complete access to device APIs, sensors, … • Requires Eclipse IDE plus Android SDK and Eclipse plugins • Only suitable for experienced developers http://developer.android.com/ Chris Greenhalgh (cmg@cs.nott.ac.uk)
Other option: Titanium Mobile NOT SUPPORTED • Creates mobile apps • All programming in Javascript • Custom (native) widgets • Converted to installable App (similar to PhoneGap) • Compatible with Android and iPhone • Good low-level/sensor access • Option for native extensions • Simple desktop GUI project management/build tool • plus your own choice of JS editor http://www.appcelerator.com/products/titanium-mobile-application-development/ Chris Greenhalgh (cmg@cs.nott.ac.uk)
Other option: Other native app NOT SUPPORTED • E.g. iPhone/iOS • Creates app for that target • Platform-specific development • Complete access to device APIs, sensors, … • Platform-specific tools Chris Greenhalgh (cmg@cs.nott.ac.uk)
Implementation Summary Easier 1 Limited options for region logic 2 By switch to map app (no overlay) Easy transition Chris Greenhalgh (cmg@cs.nott.ac.uk)
Sensor options Supported Unsupported Remote sensors Interactive/installation Photo Continuous camera input Network scanning Bluetooth, WiFi NFC / RFID • GPS • Lat/long • Regions • Compass • Accelerometer • 2D barcode • Remote sensors • Environmental Chris Greenhalgh (cmg@cs.nott.ac.uk)
GPS lat/long • Outdoor position • Requires view of sky • Typically 5m accuracy • Updates once/second • Takes up to a minute (sometimes more) to get initial “fix” Chris Greenhalgh (cmg@cs.nott.ac.uk)
A note on network location providers • iPhone and Android also support location from network information • GSM cell, WiFi networks • Requires network lookup (online) • Very rough position • 10s metres (urban) – 1000s metres (rural) Chris Greenhalgh (cmg@cs.nott.ac.uk)
GPS regions • Classification of GPS position in terms of “meaningful” regions • E.g. “near the statue” • Depends on GPS fix & accuracy • Classified at run-time • Requires region geometry to be pre-specified Chris Greenhalgh (cmg@cs.nott.ac.uk)
Compass • Many phones contain a 1, 2 or 3-D magnet flux compass • Gives approximate orientation (heading) • Affected by nearby ferrous objects • Native Android apps may get pitch and roll as well as heading (azimuth) Chris Greenhalgh (cmg@cs.nott.ac.uk)
Accelerometer • Monitors 3D acceleration of device • Acceleration = rate of change of velocity • Gravity = 9.8ms-2 (down) Chris Greenhalgh (cmg@cs.nott.ac.uk)
2D Barcode • Several standards for encoding data (esp. URLs) as 2D barcodes • E.g. QR Code • Supported by standard reader apps using camera • E.g. ZXing for Android • Can be generated and placed to identify • Specific objects • Places • People http://www.cs.nott.ac.uk/~cmg/ Chris Greenhalgh (cmg@cs.nott.ac.uk)
Remote sensors • Network access to remote sensors • E.g. Phidget Single Board Computer w. • Embedded in environment* • E.g. Temperature, humidity, light • Interactive installation • E.g. Touch, distance, pressure, force, … pressure Rotation light IR Distance Voltage Touch sonar IR Reflective current Vibration ID distance Motion (PIR) temperature Force Slider NOT SUPPORTED Temp & humidity Magnetic Mini-joystick * One set of sensors will be installed at the edge of the CS Atrium for test/development
Sensor summary 1: requires ZXing app 2: a work-around might be possible using an alternative app (TBD) 3: requires bridging service (for AppInv specifically as WebTinyDB) 4: remote sensors are outside the emulator (emulating the remote sensors is another matter) Chris Greenhalgh (cmg@cs.nott.ac.uk)
Conclusion • First: • Identify the target platform (default Android) • Identify the implementation approach you will use • Taking account of technical skills/background plus interests and platform capabilities • Identify the sensor(s) that you will use • Bear in mind emulator support and your options for access to real device(s) • Scope/refine your coursework 2 concept accordingly Chris Greenhalgh (cmg@cs.nott.ac.uk)