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