Over The Air 2011: The FT Web app - We've Got a Website for That

Andrew Betts, Assanka @triblondon

• An app is:
  
  • responsive design
  • responsive to human interface (mouse, keyboard, touchscreen, TV remote, …)
• The Daily app is now generating less than 50 tweets a day (and still going down)
  
  • Down from over 200
• iPad web app also works on other devices
  
  • not just tablets – phones too
  • currently only accessibly on iPad
  • works on Android & QNX but not released yet
  • Android imminent, QNX a few months
• server serves the same code to all devices
  
  • client does customisation and caches as much as it can
  • so can go offline and still access pages
• FT web app
  
  • 8 months with 3 people
  • then additional 4 months with same people to get Android & Playbook

issues

• flowed columns and flowing text around fixed elements
  
  • adobe webkit fork has great flow additions - but not available on devices
  • css3 template layouts – but again not supported
  • so have to measure content and cut it into positioned containers using Javascript
• content balancing
  
  • always show a whole number of items across the width
  • done by classifying devices into four groups according to screen size
    
    • small, medium, large, large wide
• podcast pages
  
  • want to keep playing audio even when move to another page
  • put audio player at the top of the DOM, so not altered
  • entire app is in a single page – just swap content in and out
• swiping between sections
  
  • continuous carousel made out of three divs
  • middle one is always the current
  • outer ones are preloaded as required
  • implemented swipes using touch gestures
  • have to do your own gesture interpretation
    
    • distinguish between slow drags and flings

tools

• playbook has remote web debugging
• WeinRE can do similar, but can’t debug Javascript
• TouchScroll allows you to keep headers fixed and snap to columns when swiping across
• web debugging proxies (e.g. Charles)
• use desktop for layout, but real device for interaction (swiping)

discoveries

• people use native apps differently
  
  • they tap lightly and fast
  • the web browser waits for fast taps in case there’s a double tap to zoom
  • if you don’t want double tap to zoom
  • Assanka made fastclick

offline access

• launching app offline
  
  • need to specify URLs in app manifest
  • if you change a single file, all of the manifest needs to be re-downloaded
  • store as little as possible
  • the more you store, the longer your app will take to launch
  • iOS manifest is buggy – you can get name conflicts with other webapps
    
    • so make sure you give your manifest a custom name
  • development is hell – things get cached the whole time
    
    • instead, add a comment that changes every minute (for dev)
    • still leaves you time to refresh a few times to check the cacheing
• manifest is no good for editorial content
  
  • local storage is much faster than SQLite
  • so if you only access by key then use it
  • you need permission to store > 5Mb
  • strategy:
    
    • launch app from web, just store <= 5Mb and prompt to save to home screen
    • saved from home screen, immediately ask for 50Mb and never ask again
  • images downloaded from server as base64 encoded strings
    
    • can combine images into single requests
    • and can then gzip the whole thing
    • stored in local SQLite
    • rendered into DOM as a data: URI
    • base64 transfer also avoids operator image recompression!
• analytics
  
  • can’t use Google analytics
  • log user actions into local DB
  • POST the log when requesting updated content
  • on the server, rewrite the log into an Apache format access log

unresolved issues

• SSL security: no browser chrome, so no browser padlock
  
  • trusted, because we tell you…
• Social media integration – OAuth in separate window doesn’t work
  
  • have to reload completely when return to app
• offline adverts:
  
  • not technically hard, but ad server companies don’t know how to deal with them
  • can’t retract the ad
  • can’t measure clicks
  • can’t click through at all…
• automated QA – selenium doesn’t really work
  
  • ended up using lots of people and lots of devices

platforms

• Android is by far the poorest web environment when compared with iOS and QNX
  
  • mainly due to lack of hardware-accelerated CSS transitions
  • so FT have a native Android app which has a single native component – the gallery to enable swiping
  • the rest of the app is HTML/CSS/JS
• QNX has a native app too, but only to have a home screen icon and to provide distribution

Q&A

• upset Apple?
  
  • probably not – FT are specific market
• differences between web app and native
  
  • web has more sections than native ever had
  • web app preloads content, so people swipe more often
  • as a result web app gets much more interaction
• is not appearing in the app store an issue?
  
  • yes, but instead making tactical native apps
  • e.g. FT Top 100 Companies – tells users if you want the full edition, go to the web app

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

iOSDev UK: Beyond NSLog

Tim Isted, @timisted

NSLog, XCode and gdb

• useful macros for logging:
  • __FILE__ (full path)
  • __LINE__
  • __FUNCTION__ (and __PRETTY_FUNCTION__)
• NSStringFromSelector(_cmd) gives you current message
  • Lots of these useful NSString functions, e.g. NSStringFromCGRect
• use macros in log define
  • non-debug version should be something like: TILog(...) do {} while (0)
• XCode preferences > Behaviours
  • Run starts — can choose what displays
• XCode also has a variables view, hidden in the next pane of the debugger
• add breakpoints for exceptions or non-source code by using little plus button at bottom of breakpoints pane
• breakpoints have really useful options
  • log to console on hit (with auto hit count)
  • continue automatically
  • only do stuff on conditions
• gdb commands:
  • s = step = Step In
  • m = Step Over
  • c = Continue
  • p = Print
  • po = Print Object
• debugging Core Data: use [self valueForKey:@"propertyName"]
• can use addresses instead of variable names in po
• can make breakpoints user-specific instead of project-specific

Instruments

• Time Profiler — great for catching infinite loops!
  • shows you time spent at certain places in call stack
  • tick the “Show Obj-C Only” checkbox
  • look for purple user symbols!
• Heap Shot tool find leaks
• quite a few WWDC videos on Instruments

Apple iPhone Tech Talk London 2009: Testing and Debugging Your iPhone Application

Just before this session, I had an interesting discussion with Mike Llewellyn, author of Broadersheet, about unit testing. He uses defensive code with asserts and logging and doesn't think there is enough value in unit testing for mostly UI code.

However, Apple have converted to using unit tests and are making it easy for XCode developers to take advantage of them.

At Kizoom, we’ve used unit tests to test our controller code — ensuring that given a particular input, it goes to the right result view with the appropriate model. This is made easier by using three20 — the result view is identified by a string rather than an object (though using OCMock would let you assert about objects too).

Here’s what Michael Jurewitz jurewitz@apple.com — App Frameworks & Dev Tools Evangelist had to say:

• thousands of tests in Core Data
  • roughly 90% coverage (that’s very impressive — it’s hard to maintain more than 80%)
  • fully test driven from the start
• similarly large amount of tests in WebKit
• Application tests get injected into application and can drive running app

static analysis

• has found and fixed thousands of bugs in Snow Leopard & iPhone OS :-)
• use it to learn and enforce good Cocoa practices
• detects dead stores: unused variables
• see “Run Static Analyzer” in Project properties / Build
  • might not want to have this for all configurations
  • gets picked up by xcodebuild on the command line

organizer

• check the console if you get a crash
• can download app’s data from actual device:
  • check Applications under Summary — your app will have a disclosure arrow

beta testing

• create a distribution certificate in the iPhone portal
• create an adhoc provisioning profile
  • can still use a wildcard identifier
• load it up into XCode
• make a beta testing config
  • duplicate the release config
  • set Code Signing Entitlements to Entitlements.plist (a new file)
  • use appropriate provisioning profile
  • create new Entitlements: set get-task-allow to false
  • disallows debugging
  • if you want people to debug, then send them a debug build…
• build + send zip of build + provisioning profile to beta testers
• they can unzip & drag both to iTunes

crashes

• can get crash log from user — iTunes syncs them
  • Mac & Windows store them in different places, but can find…
  • also available in iTunes Connect
• can get Organizer to symbolicate crash log for you
  • your .app and .dSym must be locatable by Spotlight — so keep them

low memory logs

• see count of pages: each page is 4Kb
• SpringBoard shares memory with your app — it handles presentation on screen
• mediaserverd is iPod
• if you find that something other than your app or SpringBoard is the largest memory user, then file a bug…

other crashes

EXC_CRASH (SIGABRT)

• 0xdeadfa11 — termination due to too much memory
• 0x8badf00d — watchdog timeout

EXC_BAD_ACCESS (SIGBUS)

• objc_msgSend — happens when you message a deallocated object

instruments

• Zombies template — record reference counts & enabled NSZombie detection
  • see extended detail view using rectangle icon at bottom of window
  • shows stack trace for each event
  • can jump through to code view, then jump into XCode editor