<p>This presents a framework we built when making the Glastonbury 2011 app for iOS, Android and Qt. We looked at the available options, and found them wanting. </p>
<p>
TL;DR: Javascript app logic, native UI. And we open sourced it.
</p>
<p>And it works. The Glastonbury 2011 app was well received, featured in the app stores we released for, and is now winning awards.</p>
2. I am…
• an engineer at Future Platforms
• We make apps for clients
• We’re technology agnostic. i.e. Web,
Native, Whatever.
@jhugman
3. Story Arc
• A public service announcement
• A big client, a big job
• A painful flashback
• Experiments yield a surprising result
• The future looks bright.
@jhugman
38. Fewer JS/Native function
calls
Activity
configureSpecificButtonWithData_(data)
To Native
configureSpecificButtonWithData_(data)
From Javascript
onSpecificButtonClick
39. Consequences
• Can use existing JS Engine in an
invisible WebView
@jhugman
40. Priorities
• Great performance
• Easy to grow
• Modular
• Easy-to-use Foreign Function
Interface
@jhugman
41. Super easy FFI
Native to Javascript:
// In MyScreenActivity.java
mScreenProxy.onButtonClick();
// In MyScreenUIViewController.m
[KIRIN fireEventIntoJS:
@”native2jsScreenProxy.onButtonClick()”];
// In MyScreen.js
exports.onButtonClick = function () {
// do some logic.
}
42. Super easy FFI
Javascript to Native:
// In MyScreen.js
kirin.js2nativeScreenProxy.setText_andSize_(“Hello world”, 15);
// In MyScreenActivity.java
public void setText_andSize_(String message, int size) {
// do the thing
}
// In MyScreenUIViewController.m
-(void) setText:(NSString*) message andSize:(NSInteger)size {
// do the thing
}
http://www.flickr.com/photos/fussyonion/5880808440\n\nBy definition: great utility, great UX \n12 Square Kilometers\n140 thousand people\n65 stages\n1800 acts\n5 days\n
\n
3 Native apps ruled out for cost reasons.\n
As is the year of the linux desktop\n
Reproduced with permission\nhttp://www.flickr.com/photos/twhume/4483467749/sizes/l/in/photostream/\n
http://www.flickr.com/photos/calliope/4220716666/sizes/o/in/photostream/\n\nThe &#x201C;HTML5&#x201D; marketing message is getting through. &#x201C;The Web is already cross platform&#x201D;\n
Nearly right may not be good enough.\nUncanny Valley.\n
There is no release cycle, or version numbers. OEMs take a snapshot, then fix the bugs.\n\nWebKit is not the solution to every problem.\nWe focus on web content, not complete solutions to every imaginable technology need.\n\n
Joe Hewitt&#x2019;s scrollability\nDavid Kaneda boasting that they spent three weeks getting the scrolling right\nFT.com re-implemented it anyway.\n
\n
http://www.flickr.com/photos/diversey/4246410590/sizes/o/in/photostream/\n\nBut also great for prototyping.\nNot commissioned with the users in mind.\n
\n
\n
\nPlatform Services layer is not application specific.\n
A Familiar web stack.\n
A Familiar web stack.\n
\n
* provides Javascript wrappers around native widgets\n * minimal differences in APIs between platforms\n * good device APIs.\n
ListViews / UITableViewControllers\nMemory Leaks\nDifferent to get right. \n
* Interface Builder, or layout editors.\n* No resource selection framework, no 9-patches/slices. No auto selecting retina images\n* Layout is all calculated by the developer using widths and heights.\n\nNot good enough, but great for internal enterprise apps (like Swing)\n
The design of the app is compromised, &#x201C;an app you won&#x2019;t be proud of&#x201D;.\n\nYou end up writing lots of native code anyway\n\n(Like any cross platform UI solution) there is always a lead handset. Almost always this is iOS.\n\nSometimes this &#x201C;best effort&#x201D; isn&#x2019;t always appreciated by Android users.\nUnsupported API e.g. quite a lot of the CoreAnimation, because it is difficult to replicate on Android.\n\n\n
Quick on this section.\n
Impact is a proprietary game engine.\nExperiment was successful, but abandoned, and now uses the appMobi Direct Canvas.\n\n
Getting around the uncanny valley problem.\nThe web did a very similar thing when browser meant desktop.\nCurrent winds seem to be shifting in this direction. (i.e. html apps not being native)\n
Enormous runtime overhead. Hello World on Titanium 5+ megabytes. Kitchen Sink is 12M\n10% of Android owner will balk at 0.5 meg.\n\nFUNDAMENTAL PROBLEM\n
\n
\n
The presentation layer is written per app, per platform.\nThe application logic is written once per app.\n\nThe native presentation layer talks to JS logic layer only when necessary.\n
\n
Fewer, fatter calls through the FFI\nThis is a deliberately trivial example. setListData would be a better example.\nRaw events are processed natively\nApp Specific events\n
\n
\n
\n
\n
Modular javascript good for memory, performance and testing.\nNative Screen Lifecycle events are sent to the screen module.\nThe JS assembly is packaged by a nice build script.\n
\n
http://www.flickr.com/photos/fussyonion/5880610940/sizes/o/in/photostream/\nKirin was tested on the iOS, and performed well.\nDeveloper weren&#x2019;t comfortable with JS.\n\n
http://www.flickr.com/photos/rightee/4359372/sizes/l/in/photostream/\nFor glastonbury, with a few large custom components, \nBuy 1, get next ones half price.\n\nWe only have data for Glastonbury 2011.\n
Version 0.5\nDocs and demos are not upto scratch\nNot enough services for iOS.\nAlso looking for contrib.\nVery early: little or no documentation other than the source code, and a demo app. \nExpect this to change.\n
Qt may come later (depending on demand).\nAndroid much more mature, more services too.\nWindows Phone 7 will almost certainly be targeted.\n\n\n\n