App integration: Strategies and Tactics

AnDevCon III

App Integration:
Strategies and
Tactics
Copyright © 2012CommonsWare, LLC

Objective: Add Value
● Add Value for Users
– More functionality without as much
development effort
● Add Value for Third Parties
– Their apps are more valuable when you help
drive their adoption
● Add Value for You
– Reciprocity from third parties

Integration Models
● Peers
– Apps with value independent of yours
– Hard or soft dependencies
● Plugins
– Apps with no value independent of yours


Activities, Implicit Intents
● Make a Generic Request
– ACTION_VIEW, ACTION_SEND, etc.
● User Dictates Terms
– What applications are installed that could handle
it
– What application to use for this particular
request
– What to do with that application

● Making the Selection
– No options? Crash!
– One option? Automatic start, no intervention
– Multiple options?
● Default chooser
● Override chooser (Intent.createChooser())
● ShareActionProvider

● DIY

● DIY
– PackageManager
queryIntentActivities() returns list of
possibilities, given an Intent
– You render resulting List somehow
● Avoiding the No-Options Crash
– Same technique: if list empty,
startActivity() would fail

Activities, Explicit Intents
● Hard Dependency, Declared in Code
– Craft Intent that will only be handled by peer
application
– Use PackageManager
queryIntentActivities() to confirm it
exists (or handle the exception)
– Use with startActivity() /
startActivityForResult()
● Example: Barcode Scanner (ZXing)

UI Integration via Web
● No Activity? How About a Web Site?
– Easy: launch browser on URL with ACTION_VIEW
– More Interesting: Host a WebView
● Pre-fill in forms using
loadUrl(“javascript:...”)
● Warning #1: May be tough to control
● Warning #2: Dependencies on non-public “APIs”


UI Integration via RemoteViews
● Two Apps' UIs Simultaneously
● RemoteViews Host
– Get RemoteViews from third-party
● Broadcast? Remote service?
● Initially, plus changes over time
– apply() RemoteViews into your desired
container


UI Integration via RemoteViews
● Limitations
– Widgets, methods available in RemoteViews
● Solution: DIY replacement data structure
– No direct interaction between apps
● Solution: API accessed via PendingIntents


Integrating Resources
● createPackageContext()
– Returns a Context that will resolve resources
from some other package
– Example Use: theme packs
● APK (possibly paid app) with res0urces representing
theme
● Detect existence using PackageManager
● Use createPackageContext() to retrieve
resources and apply to your UI

Integrating Code
● Option #1: createPackageContext()
– getClassLoader() will return ClassLoader
for accessing classes in other APK
● Use CONTEXT_INCLUDE_CODE in
createPackageContext() call
– Use reflection from there (e.g., loadClass())
to access foreign code


Integrating Code
● Option #2: DexClassLoader
– Given JAR/APK containing dex'd bytecode,
allows you to load classes just like a regular
ClassLoader
● Up to you to get the JAR or APK file


Integrating Code
● WARNING
– You might not know where that code came from
● Code injection attacks
– Executed code runs with your permissions
● May do things you rather wish they would not
– Net: very risky technique


Integration by ContentProvider
● All You Need is a Uri
– And some idea of what the schema is, so you
know what to do with it
● Example: plugins implementing a standard schema
that you require
– Getting the Uri
● Well-known resource name
● Bootstrap API (e.g., broadcast, remote service)


Integration by ContentProvider
● The Permission Proxy
– Problem: Your app needs too many permissions
● Example: Calendar integration
– Solution
● Wrap OS/third-party ContentProvider in one of
yours, with same schema
● Put that ContentProvider in plugin, to isolate
permission
● Check signature to ensure only used by you

Integration by Service
● Command Pattern
– Third Party Supplies Intent Structure
● Action string
● Available extras
– Call startService() as Needed
● Directly
● Via PendingIntent (e.g., AlarmManager)


Integration by Service
● Binding Pattern
– Agreed-Upon AIDL
● Peer: first mover
● Plugin: host defines
– Third Party Implements AIDL Binder
– You Bind and Use


Integration by Broadcast
● Agreed-Upon Action, Ordered vs. Regular
– Peer: first mover
– Plugin: host defines
● One Side Broadcast, Other Side Receives
– Manifest-registered receiver
– registerReceiver()


Discovery Mechanisms
● Hard-Coded
● Discovery via Broadcast
– Host sends a broadcast periodically (first run,
package installed, package removed)
– Peers/plugins reply with broadcast about
capabilities


Discovery Mechanisms
● Discovery via Naming Convention
– Plugins go in com.myfirm.myapp.plugin.*
– Host uses PackageManager to identify
– Further Handshaking
● Well-known resource
● Well-known “narrowcast” via setPackage()


More Stuff to Consider
● Custom Permissions
– Users should get a vote on data sharing
● Integration Library
– JAR to ease third-parties working with your host
● Documentation
– Only way anyone will know what to do
● ...and what you would rather they not do


What the Ecosystem Needs
● Standards
– Community-driven implicit Intent actions
● Scaffolding
– Library projects, templates for creating these
structures
● End-User Discovery
– How do they know what can integrate?


App integration: Strategies and Tactics

Recommended

Recommended

More Related Content

Similar to App integration: Strategies and Tactics

Similar to App integration: Strategies and Tactics (20)

More from CommonsWare

More from CommonsWare (19)

Recently uploaded

Recently uploaded (20)

App integration: Strategies and Tactics