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