Successfully reported this slideshow.

Make Cross Platform Apps that Suck Less

7

Share

Upcoming SlideShare
Phonegap - An Introduction
Phonegap - An Introduction
Loading in …3
×
1 of 52
1 of 52

Make Cross Platform Apps that Suck Less

7

Share

Download to read offline

Description

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

Transcript

  1. 1. Making Cross Platform Apps Suck Less James 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 Dilemma Web Native
  5. 5. Reality
  6. 6. Reality? ft.com LinkedIn Guardian Angry PhoneGap Titanium Appstore Birds
  7. 7. Reality? native Guardian Profanisaurus Facebook UI Gmail LinkedIn Appstore ft.com 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 1 HTML5 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 2 Something 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 platform operating system”
  26. 26. The Pitch • Write UI in Javascript • Native widgets are generated at runtime • iOS & Android @jhugman
  27. 27. JS/Native Bridge Performance 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 Libraries Canvas APIs implemented with 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 Kirin A 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 function calls 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 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. 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. 43. Inspired by node.js • CommonJS Modules • Transparent threading @jhugman
  44. 44. Hello World Would you like to see a demo?
  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. Thanks @jhugman github.com/kirinjs
  52. 52. Follow @KirinJS http://github.com/kirinjs @jhugman

Editor's Notes

  • \n
  • \n
  • \n
  • \n
  • \n
  • Even this is a simplification\n
  • \n
  • 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 &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\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, &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
  • http://www.flickr.com/photos/fussyonion/5880610940/sizes/o/in/photostream/\nKirin was tested on the iOS, and performed well.\nDeveloper weren&amp;#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
  • http://www.flickr.com/photos/twak/5882259852/sizes/o/in/photostream/\n\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
  • Description

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

    Transcript

    1. 1. Making Cross Platform Apps Suck Less James 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 Dilemma Web Native
    5. 5. Reality
    6. 6. Reality? ft.com LinkedIn Guardian Angry PhoneGap Titanium Appstore Birds
    7. 7. Reality? native Guardian Profanisaurus Facebook UI Gmail LinkedIn Appstore ft.com 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 1 HTML5 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 2 Something 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 platform operating system”
    26. 26. The Pitch • Write UI in Javascript • Native widgets are generated at runtime • iOS & Android @jhugman
    27. 27. JS/Native Bridge Performance 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 Libraries Canvas APIs implemented with 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 Kirin A 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 function calls 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 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. 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. 43. Inspired by node.js • CommonJS Modules • Transparent threading @jhugman
    44. 44. Hello World Would you like to see a demo?
    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. Thanks @jhugman github.com/kirinjs
    52. 52. Follow @KirinJS http://github.com/kirinjs @jhugman

    Editor's Notes

  • \n
  • \n
  • \n
  • \n
  • \n
  • Even this is a simplification\n
  • \n
  • 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 &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\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, &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
  • http://www.flickr.com/photos/fussyonion/5880610940/sizes/o/in/photostream/\nKirin was tested on the iOS, and performed well.\nDeveloper weren&amp;#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
  • http://www.flickr.com/photos/twak/5882259852/sizes/o/in/photostream/\n\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
  • More Related Content

    Related Books

    Free with a 30 day trial from Scribd

    See all

    ×