Getting Android Developers for Your Wearables

Getting Android
Developers for
Your Wearables
Copyright © 2014 CommonsWare, LLC

Developers! Developers! Developers!
●

You Want 'Em
●

●

●

Mass-market wearables: the ones with the most
apps wins
Niche-market wearables: ensure experts are
available as needed

We Got 'Em
●

Android is #1 in shipped devices, markets
dominated, apps... and presumably, developers


No Duh
●

Objective: No Perceived Barriers to Developers
●

●

Little cost required

●

●

Little time required
Little hassle required

IOW, Supporting Your Wearable Should Be a
“No Duh” Decision


No Duh: Not Always Possible
●

Extreme Form Factors
●

●

●

Augmented spectacles (Google Glass, etc.) require
distinct UI from wrist wearables
In turn, requires more development work

Extreme Business Conditions
●

●

You sold your soul to a firm with draconian
distribution and licensing policy
By definition, barriers to developer adoption


Three (Not So) Easy Pieces
●

The APIs

●

The Support Infrastructure

●

The Distribution Possibilities


“If the mountain won't come to Mohammed, then
Mohammed must go to the mountain”
Sir Francis Bacon, 1625


APIs: Existing vs. Custom
●

Existing
●

Find ways to have your wearable appear to
developers as simply part of the Android API
ecosystem
–
–

●

Accessories
Devices

Custom
●

Devise own dedicated API specifically for working
with your wearable


Why Use Existing APIs
●

Ideal: No Changes Required
●

●

Next-Best Thing: Use Stuff They Know
●

●

Existing apps “just work” with your wearable,
without modification
NASCAR drafting, API style

Bonus: Collaboration with Competition
●

Better for smaller mass-market competitors to
band together to get developer attention, compete
on other aspects


Existing APIs: App Widgets
●

Scenario: Wearable with Traditional Screen
●

“Traditional” = “not Glass”

●

Objective: App Adoption with Existing Code

●

Solution: Wearable as App Widget Host


●

App Widgets
●

Interactive bits of Android home screen, published by apps

Google Play Music
TripIt
Ambling Book Player
TuneIn Pro


●

App Widget Characteristics
●

Small UI
–
–

●

As little as 40dp x 40dp
Physical size comparable to wearables

Limited input
–
–

●

Taps on widgets, delivered to app
Scrolling/swiping of widgets, handled by host

Designed for “anywhere access”
–

Surface information without opening app

–

Control background app behavior


●

App Widget Mechanics
●

●

●

●

●

App advertises to OS that app widget(s) available
Home screen allows users to add, move, resize app
widgets
App publishes RemoteViews UI description, which
home screen renders
Home screen receives touch events, forwards select
ones on to the app
Android mediates communications


●

Anything Can Be an App Widget Host
●

Home screen

●

Keyguard

●

Your wearable!


●

Wearable Accessory or Non-Android Device
●

●

●

Your bridge app runs on Android device, serves as
AppWidgetHost
Renders RemoteViews to a bitmap, pushes to
wearable, interprets touch events

Wearable Android Device
●

App “container” for hosting app widgets, exposed
to user as if they are ordinary apps


●

Ideal: App Widgets “Just Work”
●

●

No code changes required

Nearly Ideal: New App Widget UI Layouts
●

●

●

Square versus rectangular
Smaller size and resizeable

Pretty Darn Decent: New App Widget
●

Benefits users of phones/tablets as well


Existing APIs: Other Candidates
●

Remote Playback and MediaRouter

●

DisplayManager and VirtualDisplay

●

Notifications

●

Live Wallpapers and Daydreams

●

MTP/PTP


Custom API: Layer Atop Existing
●

Start with Existing API as Base
●

●

●

E.g., app widgets
Aim to get most (but not all) development for your
wearable to be something familiar

Extend the Protocol
●

●

Additional app widget metadata
Subclass of AppWidgetProvider and additional
broadcasts for other events (e.g., button pushes)


Custom API: Layer Atop Itself
●

Different Strokes for Different Folks

●

High-Level API
●

●

●

E.g., Glass Mirror API
Easy, but limited

Low-Level API
●

E.g., GDK

●

Powerful, but complex

●

High-level API implemented atop low-level API


Custom API: Think New
●

API Design = DX
●

●

Developer eXperience, vs. User eXperience

Consider Modern API Designs
●

●

●

Fluent or “builder-style”
Event-driven, to tie into event buses or RxJava

Easy on the Baggage
●

As few dependencies as possible, lest there be
conflicts


Custom APIs: Think Wrappers
●

Clean JARs/AARs with Clean APIs
●

Versus low-level Intent instructions

●

For Your Protection
–

●

Interface versus implementation

For Developer Sanity
–

Easier for you to validate inputs, throw meaningful
exceptions, etc. to ensure that developers are not
screwing up too bad


APIs: Think Tools
●

Yesterday: Eclipse and Ant
●

●

Today: Gradle
●

●

JARs or source-based Android library projects
JAR or AAR artifacts in Maven-style repositories

Tomorrow: Android Studio
●

Next-generation IDE

●

Uses Gradle for build system


APIs: Think Documentation
●

JavaDocs

●

High-Level Implementation Guides

●

Sample Code and Walkthroughs

●

UI/UX Guidelines

●

Branding Guidelines

●

Distribution Requirements

●

...the more, the merrier!


APIs: Think Licenses. No, Really.
●

Open Source, Where Possible
●

●

Licenses are Brochures
●

●

Practical over philosophical
Indicate to developers how you want the
relationship to be

Hear From Both Sides
●

Legal counsel and “focus group” of customers


Support: StackOverflow, Please
●

Developers are already there

●

Developers will ask questions there
●

…whether you like it or not

●

Adopt a tag

●

Monitor the questions
●

●

●

Email
RSS feed

No infrastructure to maintain


Support: Go Where the Developers Are
●

StackOverflow

●

Google+ Community

●

Specialty Communities for Your Market

●

Augment Only As Needed
●

Collaboration spaces


Support: No Question Left Behind
●

●

Clearly identify where you are providing
support
Answer all legitimate questions
●

●

...even if the answer is “sorry”

Feel free to steer questions to appropriate
locations
●

E.g., issue tracker as Q&A forum


Support: Community as Force Multiplier
●

Ensure community can answer questions too
●

...but make sure that official answers are
identifiable as such

●

Promote a consistent hashtag

●

If swamped, consider two-tier support
●

●

Key community members handling front-line
questions
Escalation process for stuff that stumps the
community experts


Distribution: Self-Fulfilling Prophecy
●

Successful Platforms Get More Apps

●

Successful Platforms Have More Apps

●

Net: Apps Beget Apps

●

Cycle: Virtuous or Vicious?


Distribution: Mind the Store
●

Play Store
●

●

Can you license it?

Own Store
●

●

●

...but what about Play Services?
...but what about enterprise?

Others?


Summary
●

For Small Wearables Firms...
●

●

●

...developers are the mountain
...you are Mohammed

Address All The Pieces
●

APIs

●

Support

●

Distribution


Getting Android Developers for Your Wearables

More Related Content

What's hot (20)

Viewers also liked (6)

Similar to Getting Android Developers for Your Wearables (20)

More from CommonsWare (20)

Recently uploaded (20)

Getting Android Developers for Your Wearables