Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Like this presentation? Why not share!

Android: Reuse Models

on

  • 2,607 views

From Droidcon UK 2010

From Droidcon UK 2010

Statistics

Views

Total Views
2,607
Views on SlideShare
2,607
Embed Views
0

Actions

Likes
1
Downloads
31
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Android: Reuse Models Android: Reuse Models Presentation Transcript

    • Droidcon UK 2010 Android Reuse Models    
    • Why Reuse? ● #1 Way to Improve Overall App Quality – Establish solid patterns once, reuse often ● Faster Time to Market for Developers ● Sign of Solid Ecosystem and Community    
    • Three Reuse Models ● The APK ● The JAR ● The Android Library Project    
    • APK ● Expose API – Content Provider – AIDL – Intents (broadcasts, IntentService, etc.) ● Benefit – Only form of “reuse” at the app level = integration    
    • 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.    
    • 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    
    • 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    
    • Library Project ● Recent Addition to Android Dev Tools ● Purposes – Enable free/paid apps from (mostly) single code base – Support reuse...sorta    
    • 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...    
    • 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    
    • 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    
    • 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    
    • 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    
    • What To Distribute ● License ● Documentation ● Demo Project – Extends documentation with running code ● Clear Information – Support channels – How to get upgrades    
    • A Home To 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    
    • Where To 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.    
    • Recap ● Reuse Will Help All Long-Term – Higher-quality apps help users and the overall ecosystem – Faster-written apps help developers ● Can You Contribute? – Write (sell?) components – Component catalog site