Droidcon 2013: App to App — design & surface local APIs

Ty Smith, Twitter (ex-Evernote) @tsmith

• e.g. Samsung Note S Note app — locally synced with S Note grouping in built-in Evernote
• tapping on a note in Evernote, opens it in S Note; then back button goes back to Evernote

intents

• when sharing content to another activity, need to provide URI permission
• when offering edit, you shouldn’t send your original file
  • the third party might crash, corrupt, etc
• also can’t rely on setResult
• user might hit back and think their changes will be saved
• set last modified — when activity returns can check to see if changed — then offer user to save if they want

content providers

• can provide temporary permissions to access provider in an intent
• can pass through file handles

account manager

• see an example in the open source github app
• can request an authenticated token
• makes accounts visible to user in a standard place
• can do OAuth1 or 2
• has method to refresh OAuth2 token automatically

sync adapter

• does a lot of management for you automatically (network, battery)
• again, can expose to third parties
• can be scheduled & started with cloud messaging
• requires content provider & account manager
• but watch out for all the syncs coming at once
  • especially as networks often send out heartbeats on the hour every hour
  • devices wake up and think: I might as well sync now…
  • Evernote received DDoS load spikes…
• so add a jitter to the sync period (random 1hr -> 1hr5min)
• also add a “wait until” in the sync adapter — do your own checking

bound service

• much stronger contract than others
• other apps need to include your AIDL source code
• example: plugins for DashClock

tips

• testing is hard
  • use mock integrations
  • hard to debug integrations
• add analytics to the lower level components so you know what’s going on
  • might want to consider rate limiting
• use crash reporting (plug for crashlytics, now owned by twitter)