Android: Reuse Models

2,804 views

Published on

From Droidcon UK 2010

Published in: Technology, Education
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,804
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
34
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Android: Reuse Models

  1. 1.     Droidcon UK 2010 Android Reuse Models
  2. 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. 3.     Three Reuse Models ● The APK ● The JAR ● The Android Library Project
  4. 4.     APK ● Expose API – Content Provider – AIDL – Intents (broadcasts, IntentService, etc.) ● Benefit – Only form of “reuse” at the app level = integration
  5. 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. 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. 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. 8.     Library Project ● Recent Addition to Android DevTools ● Purposes – Enable free/paid apps from (mostly) single code base – Support reuse...sorta
  9. 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. 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. 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. 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. 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. 14.     WhatTo Distribute ● License ● Documentation ● Demo Project – Extends documentation with running code ● Clear Information – Support channels – How to get upgrades
  15. 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. 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. 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

×