nsmeetup-20140806

gistfile1.txt

NSMeetup: Designing Your API Client (@sandofsky)

2014/08/06

500px client example

(in swift)


twitter iOS model layer used in mac client

60 iOS devs twitter team

refactoring sample swift code for most of presentation..

api wrapper
hide implementation details
easy to test and patch
massage cruft

long lived api instance throughout app
nsurlconnection
can cancel (in flight after logging out, etc), throttle, etc

account wrapper
logged in user
signs requests
sandboxes all content

object graph:
view controller account api resources http
account manager singleton off account
logged out account identity, etc.

resources
drop it in your view controller, just works
coordinates with api

models should define all non-trivial logic
view controller doing too much a good sign you need to model it

cell radios:
latency to power it on
when it’s on, it bleeds battery
there are tail windows
radio still connected after request (10s idle then disconnect)
batch api requests, especially analytics
radio will never turn off if you didn’t do this..
wall of shame in iOS 8 for battery hogging
analytics logger object example
flush buffer every x minutes
serialize it so if app quits you can send it next time app opens

refresh streams in background
polling of content
heartbeat method, iterating through items

presenting content on screen (table view cell example):
resources can spit back entities (linked with account)
lazy loading of image
notification sent after loaded, cells have observer

entities:
wraps json for type safety
cocoa niceities
quality of objects, sorting
encapsulate business logic

storage:
rest api request every time instead of storing locally one option, but not best
perceptual performance important
show old content on startup preferable than a blank screen with a spinner
2s delay avg

the cloud is the truth:
migrations are overkill
core data — throw away old data and pull down latest instead
code a reset switch
pick endpoint on server, flat file with a version number
if number increments, client dumps everything and pulls down latest data
have an unarchiving flag
before restoring state, turn on flag saying you want to restore state
after restoration, say everything ok
store everything in cloud!

NSKeyedArchiver
pro: simple
con: slow, limited features
NSCoding protocol
NSData to object graph, can de-dupe circular references
does not scale
all or nothing

SQLite
pro: fast, a real database
con: some assembly required.  don’t know corner cases
FMDB wrapper library recommended
use memory mode for fast performance..but not recommended
syncing pragmas
full by default
verify after every update before continuing
however, won’t lose power in middle of app, all in cloud anyway
still have to bridge gap with real cocoa objects

Core Data
pro: everything you need
con: more than you need
good to learn so you don’t reinvent it with sqlite, etc.
resilient system
object graph, not a database
database used as a backing store
each account has its own managed object context (database)

Do you need an object graph or a database?

Hybrid approach:
NSKeyedArchiver for root (account manager, account)
core data for resources (entities, resources)
keychain for credentials (credentials)

Encrypting backups:
http://support.apple.com/kb/HT4946
when restoring on a new device, if backup wasn’t encrypted, you won’t have any of your keychain items
must have check around unarchiving to see if keychain exists to let user know they have to re-auth
don’t assume whole object graph is ok since keychain might no longer exist

plug for codepath*
teaching swift session 
use NSMeetup for priority
free for individuals

Sample project discussed:
https://github.com/sandofsky/FastPx