The development community needs to get into more of a reuse mindset, so that recommended patterns and snazzy UIs get reused, not rewritten.

1.
Droidcon UK 2010
Android Reuse Models

2.
Why Reuse?
● #1Way to Improve Overall App Quality
– Establish solid patterns once, reuse often
● FasterTime to Market for Developers
● Sign of Solid Ecosystem and Community

3.
Three Reuse Models
● The APK
● The JAR
● The Android Library Project

4.
APK
● Expose API
– Content Provider
– AIDL
– Intents (broadcasts, IntentService, etc.)
● Benefit
– Only form of “reuse” at the app level =
integration

5.
APK
● Challenges
– What if it is not installed?
● Semi-solution: bootstrap JAR with clean local API
plus APK detection and installation assist
● What happens if user uninstalls?
– Coarse-grained integration
● No frameworks, no widgets, etc.

6.
JAR
● Expose Class Library
– No different than traditional JARs
– Developers integrate via libs/ and build path
● Benefits
– Classic, battle-tested technique
– Pretty easy to package up
● Eclipse or jar command

7.
JAR
● Challenges
– Cannot include Android resources in JARs
● Would need to distribute separately, rely on
developer to unpack into project
– Resource IDs determined by hosting project
● Requires reflection or pass-the-ID-via-API
● Might run into namespace collisions

8.
Library Project
● Recent Addition to Android DevTools
● Purposes
– Enable free/paid apps from (mostly) single code
base
– Support reuse...sorta

9.
Library Project
● Basic Steps
– Create a library project (Eclipse or android
create lib-project)
– Create a demo project and/or test project
– Put reusable code, resources in library project
– Use demo/test project(s) to confirm it works
– Distribute it...somehow...

10.
Library Project
● Benefits
– Can distribute resources
– Apparently Google's model going forward (LVL)
● Challenges
– Cross-library resource collisions
– Binary-only (vs. distributing source code)
– How to distribute it

11.
Library Projects
● Avoiding Resource Name Collisions
– Prefix your resource names with something
distinctive (yet, preferably, not crazy long)
● Filenames for standard resources
● android:name attributes for “values” resources
– JARs: Use reflection and caching for resource ID
lookups
● E.g., ParcelHelper from CWAC-Parcel

12.
Library Projects
● Binary-Only Library Projects
– Your library project is normal, with source code
– Packaging
● Create JAR from bin/classes/
● Put JAR in ZIP file's libs/
● Put rest of non-source library project stuff in ZIP in
proper directories
● Result: ZIP'd library project sans source

13.
Library Projects
● Distribution Options
– ZIP/TAR
● Necessary for the binary-only option
● Could also be used for regular project as well
– Version Control Repository
– Maven

14.
WhatTo Distribute
● License
● Documentation
● Demo Project
– Extends documentation with running code
● Clear Information
– Support channels
– How to get upgrades

15.
A HomeTo Call Our Own
● What's Needed: Components Catalog
– Entries per component with consistent
metadata, links to distribution artifacts
– Good search interface
– Web 2.0/social hooks (tagging, rating, sharing,
tweeting, etc.)
– Ecosystem hooks (proprietary components?)
– Goal: “go-to” place for reuse

16.
WhereTo Learn More
● Android Developer Documentation
– Android library projects, with or without Eclipse
● Android Parcel Project
– Tips, tools, conventions for reuse
– andparcel.com
● Standard Java Knowledge Bases
– JARs, Maven, Ant, etc.

17.
Recap
● ReuseWill Help All Long-Term
– Higher-quality apps help users and the overall
ecosystem
– Faster-written apps help developers
● CanYou Contribute?
– Write (sell?) components
– Component catalog site