Getting Android Developers for Your Wearables

Copyright © 2014 CommonsWare, LLC

Getting Android Developers for Your Wearables


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 time required● Little cost 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● Existing apps “just work” with your wearable,

without modification

● Next-Best Thing: Use Stuff They Know● 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● JARs or source-based Android library projects

● Today: Gradle● 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● Practical over philosophical

● Licenses are Brochures● 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

Technology

Transcript of Getting Android Developers for Your Wearables