Make Cross Platform Apps that Suck Less


Published on

<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>
TL;DR: Javascript app logic, native UI. And we open sourced it.

<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>

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • Even this is a simplification\n
  • \n
  •\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\n\n
  •\n\nThe &amp;#x201C;HTML5&amp;#x201D; marketing message is getting through. &amp;#x201C;The Web is already cross platform&amp;#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&amp;#x2019;s scrollability\nDavid Kaneda boasting that they spent three weeks getting the scrolling right\ re-implemented it anyway.\n
  • \n
  •\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, &amp;#x201C;an app you won&amp;#x2019;t be proud of&amp;#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 &amp;#x201C;best effort&amp;#x201D; isn&amp;#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
  •\nKirin was tested on the iOS, and performed well.\nDeveloper weren&amp;#x2019;t comfortable with JS.\n\n
  •\nFor glastonbury, with a few large custom components, \nBuy 1, get next ones half price.\n\nWe only have data for Glastonbury 2011.\n
  • \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
  • \n
  • \n
  • Make Cross Platform Apps that Suck Less

    1. 1. Making Cross PlatformApps Suck LessJames Hugman
    2. 2. I am… • an engineer at Future Platforms • We make apps for clients • We’re technology agnostic. i.e. Web, Native, Whatever.@jhugman
    3. 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. 4. Web v Native is a False DilemmaWeb Native
    5. 5. Reality
    6. 6. Reality? LinkedIn Guardian Angry PhoneGap Titanium Appstore Birds
    7. 7. Reality? native Guardian Profanisaurus Facebook UI Gmail LinkedIn Plugins web PhoneGap web Logic native
    8. 8. Glastonbury 2011• “…we want users to love us…”• iPhone, Android, Nokia• Hostile terrain
    9. 9. Consequences • UI should feel native and platform specific • Assume offline@jhugman
    10. 10. Technology Options • HTML app • Something else • Three native apps@jhugman
    11. 11. Approach 1HTML5 is coming!
    12. 12. The promise@jhugman
    13. 13. Executive Summary@jhugman
    14. 14. Executive Summary Bu y o ne g et n FREE! ! !@jhugman
    15. 15. Fundamental problems • Native is closest to native • Different platform metaphors.@jhugman
    16. 16. Webkit Fragmentation • Webkit is everywhere • “No two implementations are alike” — @ppk • Different platform half-lives@jhugman
    17. 17. Lots of work • Developer time getting it just right. • CPU is spent doing UI, not your app.@jhugman
    18. 18. Developer happiness • Endless browser bugs • Less time building features • #ifdef code@jhugman
    19. 19. Addendum • Clients love to pay for web-technologies • but hate the quality@jhugman
    20. 20. Approach 2Something else
    21. 21. What’s left native ? Too expensive UI Not there yet web web Logic native
    22. 22. App Architectures Presentation Layer Application Logic Layer Platform Services Layer
    23. 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. 24. App Architectures Presentation Layer (written in JS, rendered natively) Application Logic Layer (Javascript, SQL, HTTP) Platform Services Layer (Native) “Something Else” app
    25. 25. Titanium“a cross platformoperating system”
    26. 26. The Pitch • Write UI in Javascript • Native widgets are generated at runtime • iOS & Android@jhugman
    27. 27. JS/Native BridgePerformance is I/O Bound Native Button To Native setText() setTextColor() setBackgroundColor() From Javascript onTouchDown onTouchUp onClick
    28. 28. No UI Tooling • No development tooling • No runtime tools@jhugman
    29. 29. Other significant problems • Porting by framework’s best effort • Difficult to take advantage of unsupported API@jhugman
    30. 30. DOM-less Game LibrariesCanvas APIs implementedwith OpenGL
    31. 31. Examples • Game Closure • Impact for iOS • appMobi’s DirectCanvas@jhugman
    32. 32. Observations • Game UI is not Platform UI • also see: Web UI is not Platform UI@jhugman
    33. 33. UI Performance is I/O Bound • Each bundles its own Javascript engine@jhugman
    34. 34. Introducing KirinA new platform
    35. 35. Requirements • Maximise code re-use • Native, platform appropriate UIs • Happy developers & designers • Minimal runtime to download@jhugman
    36. 36. Idealised Architecture Presentation Layer (written in Native) Application Logic Layer (Javascript, SQL, HTTP) Platform Services Layer (Native) Kirin App
    37. 37. Consequences • Platform appropriate UX • Better tooling • Fewer compromises@jhugman
    38. 38. Fewer JS/Native functioncalls Activity configureSpecificButtonWithData_(data) To Native configureSpecificButtonWithData_(data) From Javascript onSpecificButtonClick
    39. 39. Consequences • Can use existing JS Engine in an invisible WebView@jhugman
    40. 40. Priorities • Great performance • Easy to grow • Modular • Easy-to-use Foreign Function Interface@jhugman
    41. 41. Super easy FFINative to Javascript:// In MyScreenActivity.javamScreenProxy.onButtonClick();// In MyScreenUIViewController.m[KIRIN fireEventIntoJS: @”native2jsScreenProxy.onButtonClick()”];// In MyScreen.jsexports.onButtonClick = function () { // do some logic.}
    42. 42. Super easy FFIJavascript to Native:// In MyScreen.jskirin.js2nativeScreenProxy.setText_andSize_(“Hello world”, 15);// In MyScreenActivity.javapublic void setText_andSize_(String message, int size) { // do the thing}// In MyScreenUIViewController.m-(void) setText:(NSString*) message andSize:(NSInteger)size { // do the thing}
    43. 43. Inspired by node.js • CommonJS Modules • Transparent threading@jhugman
    44. 44. Hello WorldWould you like to see ademo?
    45. 45. Back to Glastonbury• What we shipped: • iOS, native only • Qt in JS/QML, with Kirin • Android with Kirin
    46. 46. Outcome• Two apps with Kirin (Android & Qt)• Android app was built in half (50%) the time of either Qt or iOS apps.
    47. 47. Outcome• 100,000+ downloads• Featured in all three app stores• Lots of great reviews• Very happy client• Winning awards
    48. 48. But that’s not all…
    49. 49. Open Sourcing Kirin • Apache Licence • Release early, release often • Looking for feedback • Looking for feature requests@jhugman
    50. 50. Current Status • iOS and Android on Github • Coming… • Android Fragments • Windows Phone 7 • Qt (already implemented)@jhugman
    51. 51.
    52. 52. Follow @KirinJS @jhugman