![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.
}](https://image.slidesharecdn.com/jameskirin-droidcon-final-for-slideshare-111010045652-phpapp02/85/Make-Cross-Platform-Apps-that-Suck-Less-41-320.jpg)
Make Cross Platform Apps that Suck Less
- 1. Making Cross Platform Apps Suck Less James Hugman
- 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
- 4. Web v Native is a False Dilemma Web Native
- 5. Reality
- 6. Reality? ft.com LinkedIn Guardian Angry PhoneGap Titanium Appstore Birds
- 7. Reality? native Guardian Profanisaurus Facebook UI Gmail LinkedIn Appstore ft.com Plugins web PhoneGap web Logic native
- 8. Glastonbury 2011 • “…we want users to love us…” • iPhone, Android, Nokia • Hostile terrain
- 9. Consequences • UI should feel native and platform specific • Assume offline @jhugman
- 10. Technology Options • HTML app • Something else • Three native apps @jhugman
- 11. Approach 1 HTML5 is coming!
- 14. Executive Summary Bu y o ne g et n FREE! ! ! @jhugman
- 15. Fundamental problems • Native is closest to native • Different platform metaphors. @jhugman
- 16. Webkit Fragmentation • Webkit is everywhere • “No two implementations are alike” — @ppk • Different platform half-lives @jhugman
- 17. Lots of work • Developer time getting it just right. • CPU is spent doing UI, not your app. @jhugman
- 18. Developer happiness • Endless browser bugs • Less time building features • #ifdef code @jhugman
- 19. Addendum • Clients love to pay for web-technologies • but hate the quality @jhugman
- 21. What’s left native ? Too expensive UI Not there yet web web Logic native
- 22. App Architectures Presentation Layer Application Logic Layer Platform Services Layer
- 23. App Architectures Presentation Layer (Sencha, JS, SASS, CSS, HTML) Application Logic Layer (Javascript, requirejs, Backbone, SQL, HTTP) Platform Services Layer Webview Native PhoneGap plugins PhoneGap App
- 24. App Architectures Presentation Layer (written in JS, rendered natively) Application Logic Layer (Javascript, SQL, HTTP) Platform Services Layer (Native) “Something Else” app
- 25. Titanium “a cross platform operating system”
- 26. The Pitch • Write UI in Javascript • Native widgets are generated at runtime • iOS & Android @jhugman
- 27. JS/Native Bridge Performance is I/O Bound Native Button To Native setText() setTextColor() setBackgroundColor() From Javascript onTouchDown onTouchUp onClick
- 28. No UI Tooling • No development tooling • No runtime tools @jhugman
- 29. Other significant problems • Porting by framework’s best effort • Difficult to take advantage of unsupported API @jhugman
- 30. DOM-less Game Libraries Canvas APIs implemented with OpenGL
- 31. Examples • Game Closure • Impact for iOS • appMobi’s DirectCanvas @jhugman
- 32. Observations • Game UI is not Platform UI • also see: Web UI is not Platform UI @jhugman
- 33. UI Performance is I/O Bound • Each bundles its own Javascript engine @jhugman
- 34. Introducing Kirin A new platform
- 35. Requirements • Maximise code re-use • Native, platform appropriate UIs • Happy developers & designers • Minimal runtime to download @jhugman
- 36. Idealised Architecture Presentation Layer (written in Native) Application Logic Layer (Javascript, SQL, HTTP) Platform Services Layer (Native) Kirin App
- 37. Consequences • Platform appropriate UX • Better tooling • Fewer compromises @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 }
- 43. Inspired by node.js • CommonJS Modules • Transparent threading @jhugman
- 44. Hello World Would you like to see a demo?
- 45. Back to Glastonbury • What we shipped: • iOS, native only • Qt in JS/QML, with Kirin • Android with Kirin
- 46. Outcome • Two apps with Kirin (Android & Qt) • Android app was built in half (50%) the time of either Qt or iOS apps.
- 47. Outcome • 100,000+ downloads • Featured in all three app stores • Lots of great reviews • Very happy client • Winning awards
- 48. But that’s not all…
- 49. Open Sourcing Kirin • Apache Licence • Release early, release often • Looking for feedback • Looking for feature requests @jhugman
- 50. Current Status • iOS and Android on Github • Coming… • Android Fragments • Windows Phone 7 • Qt (already implemented) @jhugman
Editor's Notes
- #2: \n
- #3: \n
- #4: \n
- #5: \n
- #6: \n
- #7: Even this is a simplification\n
- #8: \n
- #9: 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
- #10: \n
- #11: 3 Native apps ruled out for cost reasons.\n
- #12: As is the year of the linux desktop\n
- #13: Reproduced with permission\nhttp://www.flickr.com/photos/twhume/4483467749/sizes/l/in/photostream/\n
- #14: http://www.flickr.com/photos/calliope/4220716666/sizes/o/in/photostream/\n\nThe “HTML5” marketing message is getting through. “The Web is already cross platform”\n
- #15: Nearly right may not be good enough.\nUncanny Valley.\n
- #16: 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
- #17: Joe Hewitt’s scrollability\nDavid Kaneda boasting that they spent three weeks getting the scrolling right\nFT.com re-implemented it anyway.\n
- #18: \n
- #19: 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
- #20: \n
- #21: \n
- #22: \nPlatform Services layer is not application specific.\n
- #23: A Familiar web stack.\n
- #24: A Familiar web stack.\n
- #25: \n
- #26: * provides Javascript wrappers around native widgets\n * minimal differences in APIs between platforms\n * good device APIs.\n
- #27: ListViews / UITableViewControllers\nMemory Leaks\nDifferent to get right. \n
- #28: * 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
- #29: The design of the app is compromised, “an app you won’t be proud of”.\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 “best effort” isn’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
- #30: Quick on this section.\n
- #31: Impact is a proprietary game engine.\nExperiment was successful, but abandoned, and now uses the appMobi Direct Canvas.\n\n
- #32: 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
- #33: 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
- #34: \n
- #35: \n
- #36: 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
- #37: \n
- #38: 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
- #39: \n
- #40: \n
- #41: \n
- #42: \n
- #43: 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
- #44: \n
- #45: http://www.flickr.com/photos/fussyonion/5880610940/sizes/o/in/photostream/\nKirin was tested on the iOS, and performed well.\nDeveloper weren’t comfortable with JS.\n\n
- #46: 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
- #47: http://www.flickr.com/photos/twak/5882259852/sizes/o/in/photostream/\n\n
- #48: \n
- #49: 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
- #50: 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
- #51: \n
- #52: \n