Pebble Meetup London

There’s a definite buzz in the air around watches this week — with the Apple Watch due for pre-order tomorrow and Pebble Time just finished its Kickstarter…

Here’s my notes from tonight’s Pebble Meetup — a big turnout of mostly developers and lots of people interested in building new apps.

pebble & evernote

Damian Mehers (@DamianMehers), Senior Software Engineer, Wearables, Evernote

• have to wait for iOS app to be released for store to be updated (?)
• initially limited to 120 bytes in messages sent to watch
  • bigger messages allowed now
• Evernote app pages data into watch (using most recently used caches)
• attaches a data structure to each window
• had to implement an Evernote sync engine in Javascript…
  • using local storage
• timeline allows contextually relevant info
  • possible to query timeline to join with other info?
• want to get wearable use to be partly subconscious
  • making use of the basal ganglia :-)
• to keep a pebble timeline continually updated, need something running continually
  • JS in Pebble app doesn’t

pebble time & new SDK

Matthew Tole (@MatthewTole), Pebble Developer Evangelist

• colors all have names :-)
• PNG & APNG (animated) support (auto-conversion of GIF files)
• AppFaces — 3.0 launch only for system apps
  • a peek into your app’s current status
• pebble drawing commands
  • will have conversion from SVG — some kind of extension of GPath
  • define an SVG in a cyclical form — easy to morph to new forms

timeline

• will have built-in calendar & weather support
• can have actions
  • initially just open app with parameter
  • but will allow more later
• can push notifications through server-side web api

new designs

• encouraged to make all apps backwards compatible
• recommended to stick each screen to one or two colours

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)