Tuesday 4 October 2011

Over The Air 2011: Exploding the Gap Between Web and Native

James Hugman - Engineer at Future Platforms @jhugman

  • Web vs Native is a false dilemma
    • the answer is: it depends, or it’s both
  • often a lot of display in UI
  • story of the glastonbury app
    • Orange app for iPhone, Android and Nokia
  • three/four phases of content:
    • before (and before embargo)
    • during
    • after
  • lots of data
    • 3000 bands, 65 stages – timings could change

experimentation & research

  • assumed offline and native UI
  • but native was too expensive for three platforms
  • how do you make native in web technologies?
    • every phone has a different web view
    • Android users don’t like seeing iPhone UX
    • and Android back button can exit app if you’re not careful
    • there is no release cycle of WebKit
      • manufacturers just take the trunk and fix bugs
    • dev and cpu time spent getting UI just right
  • Titanium: write your UI in Javascript, render natively
    • ListViews either don’t look right, or leak memory
    • doesn’t always deal with latest design patterns – can’t override platform-specific behaviours
  • Impact for iOS: javascript talks to OpenGL
    • experimental & proprietary
    • morphed into appMobi’s DirectCanvas
  • game{closure}
    • pre-alpha – HTML5
    • also node.js
    • debug your mobile app and your browser app all in the same browser
  • but Game UI is not platform UI
    • easier to make cross-platform game UI as the UI is brand-specific, not platform specific
  • important to get events passing between rendering and UI logic
    • all frameworks bundle their own Javascript engine
    • Android users don’t like big apps – Titanium hello world is 6Mb!

new platform

  • Kirin requirements:
    • native, platform appropriate UIs
    • minimal download
  • design:
    • native UI
    • JS application logic
    • native platform
  • advantages:
    • raw events processed natively
    • only app-specific events passed through to app
  • “the keyhole”
    • instantiate an invisible web-view
    • build proxies for objects
    • javascript calls into native and the other way
  • modular javascript using CommonJS
    • each screen has its own module (one file each)
  • threading using asynchronous APIs, inspired by node.js
  • native-specific features available as services
    • e.g. Location, SQL, Network access
    • same Javascript to native bridge
    • JS just uses a require(...)

releasing as open source

  • available now on github
  • as a 0.5 release
  • apache license
  • looking for feedback
  • iOS and Android only at the moment (Qt coming later)
  • Windows Phone 7 might come later

Q&A

  • testing & debugging:
    • build script runs node.js
      • so can include unit tests at build time with assert
      • have console access
      • no actual debugger
  • why port model code – isn’t it simple?
    • but if using database on device, then model not so portable (Core Data doesn’t port well)
  • porting pain? scaling to iPad?
    • most of pain was electronic programme guide
    • download & syncing

No comments: