Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Best Practices Mobile SDKs_DroidConGreece16

Best Practices Mobile SDKs_DroidConGreece16

Best practices in building mobile SDKs - DroidCon Greece 2016

Emma Tresanszki

July 08, 2016
Tweet

More Decks by Emma Tresanszki

Other Decks in Technology

Transcript

  1. SDK or library ? A library -> chunk of code

    An SDK -> is still a library (often with extra tool applications, data files and sample code)
  2. Why do we need one? Make an existing service or

    API easily usable Offer a mobile specific service
  3. Which dependency ? Developers can’t be trusted to update their

    dependencies? compile 'com.android.support:appcompat-v7:23.0.+' But what has changed? In Gradle, dynamic versions use the + sign:
  4. Dynamic dependencies are evil Dynamic versions add nondeterminism to your

    build. - Behaviour changes - “But it works on my machine” - Difficult to revert Fix it
  5. Versioning - Version numbers are used to encode compatibility for

    the API. - Local store the current version/configurable file - Semantic versioning {major}.{minor}.{bugfix}. - Use stable version instead of beta.
  6. What is .aar ? - /AndroidManifest.xml (mandatory) - /classes.jar (mandatory)

    - /res/ (mandatory) - /R.txt (mandatory) - /assets/ (optional) - /libs/*.jar (optional) - /proguard.txt (optional) - /lint.jar (optional) - I/O 2013
  7. Validation - Fail fast when rejecting invalid params. Actually not

    all the time! - Do not discard future capabilities. - Should be flexible:let the API handle rejections instead.
  8. Library size - Library size: 3rd party dependencies or not

    at all - e.g. libphonenumber in a 2fa phone verification lib ( ~500KB)
  9. Packaging: Permissions - Runtime permissions - Marker selectors - Don’t

    let libraries silently add permissions to your app project/module/build/intermediates/manifests/full/[flavor]/build-type/AndroidManifest.xml.
  10. Keep a changeLOG - Is there a standard changeLOG format?

    - Why should I care? - Why can’t people just use a git log diff? - Minimize the effort by using an “UNRELEASED” section - How bad can it be? - No deprecation - Dates in region-specific formats
  11. Keep a changeLOG What makes a good changeLOG? - Readable

    - Dates YYYY-MM- DD - Group changes ADDED CHANGED DEPRECATED REMOVED FIXED SECURITY
  12. DOCUMENTATION - Copy-paste a working demo. - How much time

    you should hook the dev? - Good API reference - Advanced usage - Changelogs <version number>
  13. Publish to central repo - requirements - Project, description and

    URL - License, Developer and SCM information
  14. References - Automated Gradle project deployment to Sonatype OSS repository

    - Maven Repository Usage Guide - http://www.leveluplunch.com/java/examples/parse-phone-number-from-string/ - http://www.theappguruz.com/blog/integrate-paypal-in-android//dropbox - http://blog.danlew.net/2015/09/09/dont-use-dynamic-versions-for-your-dependencies/ - https://github.com/olivierlacan/keep-a-changelog - http://skife.org/src/design/libraries/2011/12/14/library_versioning.html