Advantages and limitations of PhoneGap for sensor processing Gabor Paller
[email protected] Sfonge Ltd. http://www.sfonge.com
Alternative application models for Android ● ●
●
Basic Android application model → Java-based Well-hidden in the Android Native Development Kit (NDK) → there is a native application model too Application models based on other languages have been proposed but have been rarely deployed
Browser as mobile application runtime ●
Browser is already acting as mobile application runtime ●
●
●
Just check out the zillions of “how to optimize your website for mobile” articles
There were some efforts to make the web application model the main application model on other platforms → Bada, Tizen (both very silent recently) → Firefox OS is making headlines now. Meanwhile, a modest tool adopted the web model widely and is in production: PhoneGap
From the helicopter ●
●
●
●
With PhoneGap, you create traditional, installable applications PhoneGap does not change the operating system in any way, it acts like a library embedded into the application A PhoneGap application is implemented mainly in web technologies: HTML, JavaScript, JQuery Promises: ● ●
Lower the cost of mobile development by employing millions of web programmers Improve the portability of applications by making the web model the greatest common denominator (which it is for web sites)
Test programs mentioned in this presentation are available here: http://www.sfonge.com/forum/topic/ droidcon-tunis-2013-presentation-advantages-and-limitations-phonegap-sensor-processing-t
White paper that this presentation is based on is available here: http://www.sfonge.com/epaper/ performance-context-aware-algorithms-implemented-web-technologies (Both require free registration to Sfonge site)
PhoneGap project This directory is our playground
PhoneGap library Displayed first
index.html
Main stylesheet in css subdirectory Main page starts here
Loads PhoneGap Loads application-specific code Invokes application-specific initialization
index.js ●
Application initialization: var app = { initialize: function() { ... },
●
First listen to onDeviceReady events: var self = this; document.addEventListener('deviceready', self.onDeviceReady, false);
●
Start invoking PhoneGap functions after the onDeviceReady event was fired: onDeviceReady: function() { ... },
index.js (2) ●
In onDeviceReady, initialize your UI
...
var shakes = document.getElementById("shakes"); app.shakeCounter = 0; shakes.innerHTML = app.shakeCounter.toString(); ●
… start listening for lifecycle events ... document.addEventListener('pause', app.onPause, false); document.addEventListener('resume', app.onResume, false);
●
… and device events (sensor, in our case) this.accelerometerWatchID = navigator.accelerometer.watchAcceleration( this.onSuccess, this.onError, { frequency: 50 });
index.js (3) ●
And then you can handle sensor events: onSuccess: function(acceleration) { var currentTimeStamp = acceleration.timestamp; var x = acceleration.x; var y = acceleration.y; var z = acceleration.z; … }
Brief interlude on context-aware applications
Context-aware applications ●
●
Context-aware applications are characterized by their capability of adapting to changes in their environment. More precisely: ● ●
●
Capture environmental changes Decide whether the change is relevant enough to adapt Adapt the behavior if the change is relevant
Architecture: sensor adapters ●
Sensor adapters ●
Process the input from probes in the environment
●
Simple: listener to operating system events
●
Complicated: signal-processing algorithm for a builtin gyroscope sensor
Architecture: decision logic ●
Decision logic ●
Rule engine that works on sensor adapter outputs and produces application adaptation decisions
●
Simple: a set of “if” statements
●
Complicated: rule inference engine.
Architecture: adaptation logic ●
Adaptation logic ●
●
●
Makes sure that the high-level context variables produced by the decision logic affect the application logic in an application-specific way. Simple: set of “if” statements built into the application logic Complicated: dynamic component system
Consequence of the application model ●
●
If the sensor adapter processing is offloaded to specialized co-processors or native code, the application model has no impact (no special processing requirements) If the application code includes sensor adapter processing then the application model better provide efficient execution because sensor processing may be CPU-intensive
Example application ●
Very simple shake detector
●
Based on the accelerometer input ●
High-pass filtering to remove effects of slow motions, e.g. walking
●
Peak detector to extract shake signal
●
“Application adaptation”: simply count
Recap: gravity and motion acceleration
Recap: Absolute value ● ●
x, y, z: acceleration vector components g – value of the gravity acceleration (can be approximated as 10)
a= √x + y + z −g 2
2
2
5 shakes Direction reverses
Movement starts: accelerating Final deceleration
Recap: Separating movements in the frequency domain Walking
Shaking Walking Walking+shaking
Hz 64-point Fast Fourier Transform performed at samples 50 and 200
Applying the filter
4 shakes can be reliably recognized
Filter in our example ●
6th-order IIR filter (N=6, 12 additions and 12 multiplications per sample) N
N
i =0
i =1
y n=∑ a i x n−i−∑ bi y n−i
Measurement ●
●
Two implementations: Java and web technology (PhoneGap). Measurement: ●
Phone is restarted
●
Nexus S, about 50 Hz sampling rate
●
App is started, sampling is started
●
Wait 10 sec
●
●
Connect with “adb shell” and launch the “top” command Record the CPU% column
Results: ●
●
CPU consumption: ●
Java implementation: 1%
●
PhoneGap implementation: 9%
Battery consumption: ●
●
●
PhoneGap : 0.1218%/min → 7.3 %/hour → about 13 hours of battery life Java: 0.072%/min →4.32%/hour → about 23 hours of battery life
60% more consumption, 40% less battery life
PhoneGap “plugins” ● ●
●
PhoneGap is built on the plugin concept Its own services are also built as plugins and you can define your own Plugins are implemented as whatever is “native” in the environment, in case of Android in Java
PhoneGap plugin ●
Plugin class: public class SamplingServiceAdapter extends CordovaPlugin { … }
●
Plugin commands: public boolean execute(String action, JSONArray args, CallbackContext callbackContext) { if (action.equals("start")) { … }
●
Register your plugin in res/xml/config.xml
Callbacks ●
Use CallbackContext to initiate a callback: PluginResult result = new PluginResult(PluginResult.Status.OK, this.getStepCountJSON(count)); result.setKeepCallback(true); callbackContext.sendPluginResult(result);
●
The result must be in JSON: JSONObject r = new JSONObject(); r.put("count", count);
●
Which conforms in JSON to: { count: 2 }
From the JS side ●
Sending a command from JS: cordova.exec(this.onShake,this.onError,"Shake","start",[]);
●
Receiving a callback from native: onShake: function(s) { var count = s.count; // Remember the JSON format we generate! … }
Plugin result ●
●
With plugin implementation, the CPU load is comparable to native implementation (about 1%, within measurement error) No surprise here: if you check the code, you will see that “CPU-intensive” tasks are implemented similarly to the Java version.
So what about the “web model”? ●
Web model is great for some types of applications (if you have the competence) ●
●
These are typically UI-intensive applications when some data is presented to the user and we are then expecting user interaction
Try to handle moderately “CPU-intensive” tasks in the web model and you will be in for an unpleasant surprise ●
CPU load is directly translated to battery life and I haven't even talked about memory footprint
My advice ●
●
●
If you are an experienced web developer, go for the web model and implement your apps in the web model, you will have quick success Always consider, whether you have “CPUintensive” tasks – those that happen often and require non-trivial calculations When you are considering a web application platform, always look for native extension possibility, just in case. If there is none, beware.
Questions?
