SlideShare a Scribd company logo
SDK best practices
Rebecca Hamelsdorf
13/9/2017
Hi!!
What is SDK
What is SDK?
what is SDK?
• SDK is a software development kit
• It’s a programing package that helps developers
to builds application for a specific platform.
• Typically it includes one or more API
Why?
Why do we need to develop an SDK?
Business need
Why do we need to develop an SDK?
But not for business reasons..
Why do we need to develop an SDK?
Business need
Internal use
Internal use..
Code reuse
Abstraction/black box
Why do we care about code reuse
● Saves time & money
Why do we care about code reuse
● Saves time & money
● Easier to maintain and change
Why do we care about code reuse
● Saves time & money
● Easier to maintain and change
● Solving bugs in a single place instead of bugs
all over the place
Developing SDK check list
1. Define the service for your SDK users
2. Plan your public API
3. Plan your internal code architecture
4. Code:)
5. Sample app + docs
6. Packaging
7. Ship!
Developing SDK check list
❏ Define the service for your SDK users
❏ Plan your public API
❏ Plan your internal code architecture
❏ Code:)
❏ Sample app + docs
❏ Packaging
❏ Ship!
Developing SDK check list
1. Define the service for your SDK users
2. Plan your public API
3. Plan your internal code architecture
4. Code:)
5. Sample app + docs
6. Packaging
7. Ship!
Plan your public API…
Public API is the contract between the app developer and
SDK developer.
you’re officially an API designer!
Plan your public API…
Put in your mind that the developer that integrate your sdk is
not sitting next to you..
Plan your public API…
Keep it:
Easy to learn- design for “stupid” developers
Plan your public API…
Keep it:
Easy to learn
Easy to use (even without docs!!), easy to integrate.
Someone did it really easy..
Plan your public API…
Keep it:
Easy to learn
Easy to use (even without docs!!), easy to integrate.
Hard to misused!
Plan your public API…
Keep it:
Easy to learn
Easy to use (even without docs!!), easy to integrate.
Hard to misused!
Custom exceptions
Custom Exception
class ServerURLException extends RuntimeException {
public ServerURLException(String message) {
super(message);
}
}
Custom Exception
class ServerURLException extends RuntimeException {
public ServerURLException(String message) {
super(message);
}
}
static void isUrlValid(String serverURL) {
if( isNullOrEmpty(serverURL) || !isValidUrl(serverURL))
{
throw new ServerURLException(“Server URL is invalid or empty");
}
}
Plan your public API…
Keep it:
Easy to learn
Easy to use (even without docs!!), easy to integrate.
Hard to misused!
Custom exceptions
No confusing constructors - use builder pattern, static
factory pattern etc.
Builder pattern
public class User {
private final String firstName; //required
private final String lastName; //required
private final int age; //optional
private final String phone; //optional
private final String address; //optional
...
}
Builder pattern
public User(String firstName, String lastName) {this(firstName, lastName, 0);}
public User(String firstName, String lastName, int age) {this(firstName, lastName, age, "");}
public User(String firstName, String lastName, int age, String phone) {
this(firstName, lastName, age, phone, "");}
public User(String firstName, String lastName, int age, String phone, String address) {
this.firstName = firstName;
this.lastName = lastName;
this.age = age;
this.phone = phone;
this.address = address;
}
Builder pattern
public class User {
private final String firstName; // required
private final String lastName; // required
private final int age; // optional
private final String phone; // optional
private final String address; // optional
private User(UserBuilder builder) {
this.firstName = builder.firstName;
this.lastName = builder.lastName;
this.age = builder.age;
this.phone = builder.phone;
this.address = builder.address;
}
public String getFirstName() {
return firstName;}
public String getLastName() {
return lastName;}
public int getAge() {
return age;}
public String getPhone() {
return phone; }
public String getAddress() {
return address; }
Builder pattern
public class User {
private final String firstName; // required
private final String lastName; // required
private final int age; // optional
private final String phone; // optional
private final String address; // optional
private User(UserBuilder builder) {
this.firstName = builder.firstName;
this.lastName = builder.lastName;
this.age = builder.age;
this.phone = builder.phone;
this.address = builder.address;
}
public String getFirstName() {
return firstName;}
public String getLastName() {
return lastName;}
public int getAge() {
return age;}
public String getPhone() {
return phone; }
public String getAddress() {
return address; }
Builder pattern
public static class UserBuilder {
private final String firstName;
private final String lastName;
private int age;
private String phone;
private String address;
public UserBuilder(String firstName,
String lastName) {
this.firstName = firstName;
this.lastName = lastName;
}
public UserBuilder age(int age) {
this.age = age;
return this;}
public UserBuilder phone(String phone) {
this.phone = phone;
return this;}
public UserBuilder address(String address) {
this.address = address;
return this; }
public User build() {
return new User(this);
}}}
Builder pattern
User.UserBuilder("Jhon", "Doe")
.age(30)
.phone("1234567")
.address("Fake address 1234")
.build();
Plan your public API…
● Keep it:
Easy to learn
Easy to use (even without docs!!), easy to integrate.
Hard to misused!
Custom exceptions
No confusing constructors - use builder pattern, static
factory pattern etc.
Use enums, public static variables when you can.
Plan your public API…
● We don’t choose the min sdk!
we want maximum compatibility
Plan your public API…
● We don’t choose the min sdk!
we want maximum compatibility
● Try to use minimum permissions - it’s hard for the developer
to explain to THEIR users the need for permissions.
Merged Manifest
<?xml version="1.0" encoding="utf-8"?>
<manifest
xmlns:android="http://schemas.android.com/apk/res/android"
package="com.academy.myapp">
<application
android:allowBackup="true"
android:icon="@mipmap/ic_launcher"
android:label="@string/app_name"
android:roundIcon="@mipmap/ic_launcher_round"
android:supportsRtl="true"
android:theme="@style/AppTheme">
<activity android:name=".MainActivity">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category
android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
</application>
</manifest>
Merged Manifest
https://developer.android.com/studio/build/manifest-merge.html
Plan your public API…
● We don’t choose the min sdk!
we want maximum compatibility
● Try to use minimum permissions - it’s hard for the developer
to explain to THEIR users the need for permissions.
● Think carefully - we REALLY don’t want to change it very
often (if at all!) *adding is OK
Developing SDK check list
❏ Define the service for your SDK users
❏ Plan your public API
❏ Plan your internal code architecture
❏ Code:)
❏ Sample app + docs
❏ Packaging
❏ Ship!
Developing SDK check list
1. Define the service for your SDK users
2. Plan your public API
3. Plan your internal code architecture
4. Code:)
5. Sample app + docs
6. Packaging
7. Ship!
Plan your internal code architecture
● Exception handling - the more the merrier :)
Plan your internal code architecture
● Exception handling - the more the merrier :)
● Use the minimum needed third-party libraries
a. we want to keep our SDK light
b. we avoid depending on others
Plan your internal code architecture
● Exception handling - the more the merrier :)
● Use the minimum needed third-party libraries
a. we want to keep our SDK light
b. we avoid depending on others
● Handle missing permission cases, you are not promised
to have them
Plan your internal code architecture
● Be very mindful to data consumption and battery usage!
Plan your internal code architecture
● Be very mindful to data consumption and battery usage!
● Remember your support phase during development:
○ Deprecate - don’t kill!
○ Write logs but don’t spam, use 2 log levels (debug/production)
Developing SDK check list
❏ Define the service for your SDK users
❏ Plan your public API
❏ Plan your internal code architecture
❏ Code:)
❏ Sample app + docs
❏ Packaging
❏ Ship!
Developing SDK check list
1. Define the service for your SDK users
2. Plan your public API
3. Plan your internal code architecture
4. Code:)
5. Sample app + docs
6. Packaging
7. Ship!
Code..
● Remember resource are public by default - hide what
you need hidden.
public.xml
<resources>
<public name="mylib_app_name" type="string"/>
<public name="mylib_public_string" type="string"/>
</resources>
Code..
● Add unique prefix to resources - the developers may
have their own resources that can conflict with yours!
Code..
● Add unique prefix to resources - the developers may
have their own resources that can conflict with yours!
● Test it on different Kind of apps..
Code..
● Add unique prefix to resources - the developers may
have their own resources that can conflict with yours!
● Test it on different Kind of apps..
● you must take the life cycle of the app in consideration!
Developing SDK check list
❏ Define the service for your SDK users
❏ Plan your public API
❏ Plan your internal code architecture
❏ Code:)
❏ Sample app + docs
❏ Packaging
❏ Ship!
Developing SDK check list
1. Define the service for your SDK users
2. Plan your public API
3. Plan your internal code architecture
4. Code:)
5. Sample app + docs
6. Packaging
7. Ship!
Sample app +docs
Provide 2 kinds of docs:
Simple integration instructions + sample app
Api Overview
Sample app +docs
● Provide 2 kinds of docs:
Simple integration instructions + sample app
Api Overview
• Remember Proguard docs
proguard.config
-keep class javax.** { *; }
-keep class org.** { *; }
-keep class twitter4j.** { *; }
Developing SDK check list
❏ Define the service for your SDK users
❏ Plan your public API
❏ Plan your internal code architecture
❏ Code:)
❏ Sample app + docs
❏ Packaging
❏ Ship!
Developing SDK check list
1. Define the service for your SDK users
2. Plan your public API
3. Plan your internal code architecture
4. Code:)
5. Sample app + docs
6. Packaging
7. Ship!
Packaging
Once we had a jar..
What can we do?
We have AAR!
What does aar contain?
The file extension for an AAR file is .aar, actually the file itself is
a zip file containing the following mandatory entries:
/AndroidManifest.xml
/classes.jar
/res/
/R.txt
/public.txt
There are also optional entries :
/assets/
/libs/name.jar
/proguard.txt
/lint.jar
Migrate from AAR to JAR ..
The file extension for an AAR file is .aar, actually the file itself is
a zip file containing the following mandatory entries:
/AndroidManifest.xml
/classes.jar
/res/
/R.txt
/public.txt
step by step..
https://developer.android.com/studio/projects/android-library.html
Developing SDK check list
❏ Define the service for your SDK users
❏ Plan your public API
❏ Plan your internal code architecture
❏ Code:)
❏ Sample app + docs
❏ Packaging
❏ Ship!
Developing SDK check list
❏ Define the service for your SDK users
❏ Plan your public API
❏ Plan your internal code architecture
❏ Code:)
❏ Sample app + docs
❏ Packaging
❏ Ship!
Battery Historian
• Battery Historian is a tool to analyze battery consumers
and events(DOZE mode).
Battery Historian
• Battery Historian is a tool to analyze battery consumers
and events(DOZE mode).
• It uses Android "bugreport" files
Battery Historian
• Battery Historian is a tool to analyze battery consumers
and events(DOZE mode).
• It uses Android "bugreport" files
• Supports Lollipop (API level 21) and later.
Battery Historian
• Battery Historian is a tool to analyze battery consumers
and events(DOZE mode).
• It uses Android "bugreport" files
• Supports Lollipop (API level 21) and later.
• Shows you where and how processes are drawing current
from the battery.
How to build Sdk? Best practices
Battery Historian
• https://developer.android.com/studio/profile/battery-historian.html
• https://github.com/google/battery-historian
Stetho
• Stetho is a very powerful tool for debugging.
• It enables developers have access to the Chrome
Developer Tools feature
http://facebook.github.io/stetho/
Stetho
Questions?

More Related Content

PDF
To SDK or not to SDK?
PPTX
Maven tutorial
PPTX
Nodejs functions & modules
PPTX
Docker Security workshop slides
PPTX
Exploring the power of Gradle in android studio - Basics & Beyond
PPTX
Unit 1 - TypeScript & Introduction to Angular CLI.pptx
PDF
VueJS Introduction
PPTX
To SDK or not to SDK?
Maven tutorial
Nodejs functions & modules
Docker Security workshop slides
Exploring the power of Gradle in android studio - Basics & Beyond
Unit 1 - TypeScript & Introduction to Angular CLI.pptx
VueJS Introduction

What's hot (20)

PPTX
Metasploit
PDF
Spring Security
PDF
Exploiting Deserialization Vulnerabilities in Java
PPTX
Docker basics
PDF
TypeScript - An Introduction
PPTX
Java/Servlet/JSP/JDBC
PPTX
React Workshop
PPTX
Typescript ppt
PDF
Docker architecture-04-1
PDF
Getting started with Spring Security
PDF
Container Security
PPTX
Getting started with Docker
PPTX
Angular 5 presentation for beginners
PPTX
Integrating Microservices with Apache Camel
PPTX
Containerization & Docker - Under the Hood
PPT
React js
PPTX
Permission in Android Security: Threats and solution
PPT
Docker introduction
PPTX
Introduction to NodeJS
Metasploit
Spring Security
Exploiting Deserialization Vulnerabilities in Java
Docker basics
TypeScript - An Introduction
Java/Servlet/JSP/JDBC
React Workshop
Typescript ppt
Docker architecture-04-1
Getting started with Spring Security
Container Security
Getting started with Docker
Angular 5 presentation for beginners
Integrating Microservices with Apache Camel
Containerization & Docker - Under the Hood
React js
Permission in Android Security: Threats and solution
Docker introduction
Introduction to NodeJS
Ad

Similar to How to build Sdk? Best practices (20)

PDF
Api design
PPTX
Practices and Tools for Building Better APIs
PPT
Api desgin
PDF
Dev Learn Handout - Session 604
PPTX
Developer Friendly API Design
PPTX
How to define an api
PPT
How to design effective APIs
PDF
How To Design A Good A P I And Why It Matters G O O G L E
PPTX
Building a REST API for Longevity
PDF
ApiDesign
PDF
API design
PDF
Keynoteof A P I
PDF
How to design good api
PDF
How to Design a Good API and Why it Matters.pdf
PPTX
Adobe Acrobat Pro DC 2025.001.20432 Crack + Serial Key
PDF
Adobe Acrobat Pro DC 2025.001.20432 Crack free Download
PDF
apidevelopment-250316174151-ce087222-250328054658-db40e0f2.pdf
PDF
Adobe Acrobat Pro DC 2025.001.20432 Crack free Download
PDF
Adobe Acrobat Pro DC 2025.001.20432 Crack free Download
PPTX
Adobe Acrobat Reader Download Free - 2025.001.20432
Api design
Practices and Tools for Building Better APIs
Api desgin
Dev Learn Handout - Session 604
Developer Friendly API Design
How to define an api
How to design effective APIs
How To Design A Good A P I And Why It Matters G O O G L E
Building a REST API for Longevity
ApiDesign
API design
Keynoteof A P I
How to design good api
How to Design a Good API and Why it Matters.pdf
Adobe Acrobat Pro DC 2025.001.20432 Crack + Serial Key
Adobe Acrobat Pro DC 2025.001.20432 Crack free Download
apidevelopment-250316174151-ce087222-250328054658-db40e0f2.pdf
Adobe Acrobat Pro DC 2025.001.20432 Crack free Download
Adobe Acrobat Pro DC 2025.001.20432 Crack free Download
Adobe Acrobat Reader Download Free - 2025.001.20432
Ad

More from Vitali Pekelis (20)

PDF
Droidkaigi2019thagikura 190208135940
PDF
Droidkaigi 2019
PPTX
Google i o &amp; android q changes 2019
PPTX
Android Q 2019
PPTX
Advanced #6 clean architecture
PPTX
Advanced #4 GPU & Animations
PDF
Advanced #2 networking
PPTX
Advanced #2 threading
PPTX
Advanced #1 cpu, memory
PPTX
All the support you need. Support libs in Android
PPTX
Di &amp; dagger
PPTX
Android design patterns
PPTX
Advanced #3 threading
PPTX
Mobile ui fruit or delicious sweets
PPTX
Lecture #4 c loaders and co.
PPTX
Session #4 b content providers
PPTX
Advanced #2 - ui perf
PDF
Android meetup
PPTX
Android design lecture #3
PPTX
From newbie to ...
Droidkaigi2019thagikura 190208135940
Droidkaigi 2019
Google i o &amp; android q changes 2019
Android Q 2019
Advanced #6 clean architecture
Advanced #4 GPU & Animations
Advanced #2 networking
Advanced #2 threading
Advanced #1 cpu, memory
All the support you need. Support libs in Android
Di &amp; dagger
Android design patterns
Advanced #3 threading
Mobile ui fruit or delicious sweets
Lecture #4 c loaders and co.
Session #4 b content providers
Advanced #2 - ui perf
Android meetup
Android design lecture #3
From newbie to ...

Recently uploaded (20)

PDF
Why TechBuilder is the Future of Pickup and Delivery App Development (1).pdf
PDF
Nekopoi APK 2025 free lastest update
PPTX
ISO 45001 Occupational Health and Safety Management System
PPTX
Agentic AI Use Case- Contract Lifecycle Management (CLM).pptx
PDF
Odoo Companies in India – Driving Business Transformation.pdf
PPT
Introduction Database Management System for Course Database
PDF
Addressing The Cult of Project Management Tools-Why Disconnected Work is Hold...
PPTX
L1 - Introduction to python Backend.pptx
PPTX
history of c programming in notes for students .pptx
PDF
Claude Code: Everyone is a 10x Developer - A Comprehensive AI-Powered CLI Tool
PPTX
Oracle E-Business Suite: A Comprehensive Guide for Modern Enterprises
PPTX
Transform Your Business with a Software ERP System
PDF
T3DD25 TYPO3 Content Blocks - Deep Dive by André Kraus
PDF
How Creative Agencies Leverage Project Management Software.pdf
PPTX
Lecture 3: Operating Systems Introduction to Computer Hardware Systems
PPTX
ManageIQ - Sprint 268 Review - Slide Deck
PDF
PTS Company Brochure 2025 (1).pdf.......
PPTX
CHAPTER 12 - CYBER SECURITY AND FUTURE SKILLS (1) (1).pptx
PDF
Softaken Excel to vCard Converter Software.pdf
PPTX
Introduction to Artificial Intelligence
Why TechBuilder is the Future of Pickup and Delivery App Development (1).pdf
Nekopoi APK 2025 free lastest update
ISO 45001 Occupational Health and Safety Management System
Agentic AI Use Case- Contract Lifecycle Management (CLM).pptx
Odoo Companies in India – Driving Business Transformation.pdf
Introduction Database Management System for Course Database
Addressing The Cult of Project Management Tools-Why Disconnected Work is Hold...
L1 - Introduction to python Backend.pptx
history of c programming in notes for students .pptx
Claude Code: Everyone is a 10x Developer - A Comprehensive AI-Powered CLI Tool
Oracle E-Business Suite: A Comprehensive Guide for Modern Enterprises
Transform Your Business with a Software ERP System
T3DD25 TYPO3 Content Blocks - Deep Dive by André Kraus
How Creative Agencies Leverage Project Management Software.pdf
Lecture 3: Operating Systems Introduction to Computer Hardware Systems
ManageIQ - Sprint 268 Review - Slide Deck
PTS Company Brochure 2025 (1).pdf.......
CHAPTER 12 - CYBER SECURITY AND FUTURE SKILLS (1) (1).pptx
Softaken Excel to vCard Converter Software.pdf
Introduction to Artificial Intelligence

How to build Sdk? Best practices

  • 1. SDK best practices Rebecca Hamelsdorf 13/9/2017
  • 5. what is SDK? • SDK is a software development kit • It’s a programing package that helps developers to builds application for a specific platform. • Typically it includes one or more API
  • 7. Why do we need to develop an SDK? Business need
  • 8. Why do we need to develop an SDK? But not for business reasons..
  • 9. Why do we need to develop an SDK? Business need Internal use
  • 11. Why do we care about code reuse ● Saves time & money
  • 12. Why do we care about code reuse ● Saves time & money ● Easier to maintain and change
  • 13. Why do we care about code reuse ● Saves time & money ● Easier to maintain and change ● Solving bugs in a single place instead of bugs all over the place
  • 14. Developing SDK check list 1. Define the service for your SDK users 2. Plan your public API 3. Plan your internal code architecture 4. Code:) 5. Sample app + docs 6. Packaging 7. Ship!
  • 15. Developing SDK check list ❏ Define the service for your SDK users ❏ Plan your public API ❏ Plan your internal code architecture ❏ Code:) ❏ Sample app + docs ❏ Packaging ❏ Ship!
  • 16. Developing SDK check list 1. Define the service for your SDK users 2. Plan your public API 3. Plan your internal code architecture 4. Code:) 5. Sample app + docs 6. Packaging 7. Ship!
  • 17. Plan your public API… Public API is the contract between the app developer and SDK developer. you’re officially an API designer!
  • 18. Plan your public API… Put in your mind that the developer that integrate your sdk is not sitting next to you..
  • 19. Plan your public API… Keep it: Easy to learn- design for “stupid” developers
  • 20. Plan your public API… Keep it: Easy to learn Easy to use (even without docs!!), easy to integrate.
  • 21. Someone did it really easy..
  • 22. Plan your public API… Keep it: Easy to learn Easy to use (even without docs!!), easy to integrate. Hard to misused!
  • 23. Plan your public API… Keep it: Easy to learn Easy to use (even without docs!!), easy to integrate. Hard to misused! Custom exceptions
  • 24. Custom Exception class ServerURLException extends RuntimeException { public ServerURLException(String message) { super(message); } }
  • 25. Custom Exception class ServerURLException extends RuntimeException { public ServerURLException(String message) { super(message); } } static void isUrlValid(String serverURL) { if( isNullOrEmpty(serverURL) || !isValidUrl(serverURL)) { throw new ServerURLException(“Server URL is invalid or empty"); } }
  • 26. Plan your public API… Keep it: Easy to learn Easy to use (even without docs!!), easy to integrate. Hard to misused! Custom exceptions No confusing constructors - use builder pattern, static factory pattern etc.
  • 27. Builder pattern public class User { private final String firstName; //required private final String lastName; //required private final int age; //optional private final String phone; //optional private final String address; //optional ... }
  • 28. Builder pattern public User(String firstName, String lastName) {this(firstName, lastName, 0);} public User(String firstName, String lastName, int age) {this(firstName, lastName, age, "");} public User(String firstName, String lastName, int age, String phone) { this(firstName, lastName, age, phone, "");} public User(String firstName, String lastName, int age, String phone, String address) { this.firstName = firstName; this.lastName = lastName; this.age = age; this.phone = phone; this.address = address; }
  • 29. Builder pattern public class User { private final String firstName; // required private final String lastName; // required private final int age; // optional private final String phone; // optional private final String address; // optional private User(UserBuilder builder) { this.firstName = builder.firstName; this.lastName = builder.lastName; this.age = builder.age; this.phone = builder.phone; this.address = builder.address; } public String getFirstName() { return firstName;} public String getLastName() { return lastName;} public int getAge() { return age;} public String getPhone() { return phone; } public String getAddress() { return address; }
  • 30. Builder pattern public class User { private final String firstName; // required private final String lastName; // required private final int age; // optional private final String phone; // optional private final String address; // optional private User(UserBuilder builder) { this.firstName = builder.firstName; this.lastName = builder.lastName; this.age = builder.age; this.phone = builder.phone; this.address = builder.address; } public String getFirstName() { return firstName;} public String getLastName() { return lastName;} public int getAge() { return age;} public String getPhone() { return phone; } public String getAddress() { return address; }
  • 31. Builder pattern public static class UserBuilder { private final String firstName; private final String lastName; private int age; private String phone; private String address; public UserBuilder(String firstName, String lastName) { this.firstName = firstName; this.lastName = lastName; } public UserBuilder age(int age) { this.age = age; return this;} public UserBuilder phone(String phone) { this.phone = phone; return this;} public UserBuilder address(String address) { this.address = address; return this; } public User build() { return new User(this); }}}
  • 33. Plan your public API… ● Keep it: Easy to learn Easy to use (even without docs!!), easy to integrate. Hard to misused! Custom exceptions No confusing constructors - use builder pattern, static factory pattern etc. Use enums, public static variables when you can.
  • 34. Plan your public API… ● We don’t choose the min sdk! we want maximum compatibility
  • 35. Plan your public API… ● We don’t choose the min sdk! we want maximum compatibility ● Try to use minimum permissions - it’s hard for the developer to explain to THEIR users the need for permissions.
  • 36. Merged Manifest <?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.academy.myapp"> <application android:allowBackup="true" android:icon="@mipmap/ic_launcher" android:label="@string/app_name" android:roundIcon="@mipmap/ic_launcher_round" android:supportsRtl="true" android:theme="@style/AppTheme"> <activity android:name=".MainActivity"> <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </activity> </application> </manifest>
  • 38. Plan your public API… ● We don’t choose the min sdk! we want maximum compatibility ● Try to use minimum permissions - it’s hard for the developer to explain to THEIR users the need for permissions. ● Think carefully - we REALLY don’t want to change it very often (if at all!) *adding is OK
  • 39. Developing SDK check list ❏ Define the service for your SDK users ❏ Plan your public API ❏ Plan your internal code architecture ❏ Code:) ❏ Sample app + docs ❏ Packaging ❏ Ship!
  • 40. Developing SDK check list 1. Define the service for your SDK users 2. Plan your public API 3. Plan your internal code architecture 4. Code:) 5. Sample app + docs 6. Packaging 7. Ship!
  • 41. Plan your internal code architecture ● Exception handling - the more the merrier :)
  • 42. Plan your internal code architecture ● Exception handling - the more the merrier :) ● Use the minimum needed third-party libraries a. we want to keep our SDK light b. we avoid depending on others
  • 43. Plan your internal code architecture ● Exception handling - the more the merrier :) ● Use the minimum needed third-party libraries a. we want to keep our SDK light b. we avoid depending on others ● Handle missing permission cases, you are not promised to have them
  • 44. Plan your internal code architecture ● Be very mindful to data consumption and battery usage!
  • 45. Plan your internal code architecture ● Be very mindful to data consumption and battery usage! ● Remember your support phase during development: ○ Deprecate - don’t kill! ○ Write logs but don’t spam, use 2 log levels (debug/production)
  • 46. Developing SDK check list ❏ Define the service for your SDK users ❏ Plan your public API ❏ Plan your internal code architecture ❏ Code:) ❏ Sample app + docs ❏ Packaging ❏ Ship!
  • 47. Developing SDK check list 1. Define the service for your SDK users 2. Plan your public API 3. Plan your internal code architecture 4. Code:) 5. Sample app + docs 6. Packaging 7. Ship!
  • 48. Code.. ● Remember resource are public by default - hide what you need hidden.
  • 49. public.xml <resources> <public name="mylib_app_name" type="string"/> <public name="mylib_public_string" type="string"/> </resources>
  • 50. Code.. ● Add unique prefix to resources - the developers may have their own resources that can conflict with yours!
  • 51. Code.. ● Add unique prefix to resources - the developers may have their own resources that can conflict with yours! ● Test it on different Kind of apps..
  • 52. Code.. ● Add unique prefix to resources - the developers may have their own resources that can conflict with yours! ● Test it on different Kind of apps.. ● you must take the life cycle of the app in consideration!
  • 53. Developing SDK check list ❏ Define the service for your SDK users ❏ Plan your public API ❏ Plan your internal code architecture ❏ Code:) ❏ Sample app + docs ❏ Packaging ❏ Ship!
  • 54. Developing SDK check list 1. Define the service for your SDK users 2. Plan your public API 3. Plan your internal code architecture 4. Code:) 5. Sample app + docs 6. Packaging 7. Ship!
  • 55. Sample app +docs Provide 2 kinds of docs: Simple integration instructions + sample app Api Overview
  • 56. Sample app +docs ● Provide 2 kinds of docs: Simple integration instructions + sample app Api Overview • Remember Proguard docs
  • 57. proguard.config -keep class javax.** { *; } -keep class org.** { *; } -keep class twitter4j.** { *; }
  • 58. Developing SDK check list ❏ Define the service for your SDK users ❏ Plan your public API ❏ Plan your internal code architecture ❏ Code:) ❏ Sample app + docs ❏ Packaging ❏ Ship!
  • 59. Developing SDK check list 1. Define the service for your SDK users 2. Plan your public API 3. Plan your internal code architecture 4. Code:) 5. Sample app + docs 6. Packaging 7. Ship!
  • 61. What can we do? We have AAR!
  • 62. What does aar contain? The file extension for an AAR file is .aar, actually the file itself is a zip file containing the following mandatory entries: /AndroidManifest.xml /classes.jar /res/ /R.txt /public.txt There are also optional entries : /assets/ /libs/name.jar /proguard.txt /lint.jar
  • 63. Migrate from AAR to JAR .. The file extension for an AAR file is .aar, actually the file itself is a zip file containing the following mandatory entries: /AndroidManifest.xml /classes.jar /res/ /R.txt /public.txt
  • 65. Developing SDK check list ❏ Define the service for your SDK users ❏ Plan your public API ❏ Plan your internal code architecture ❏ Code:) ❏ Sample app + docs ❏ Packaging ❏ Ship!
  • 66. Developing SDK check list ❏ Define the service for your SDK users ❏ Plan your public API ❏ Plan your internal code architecture ❏ Code:) ❏ Sample app + docs ❏ Packaging ❏ Ship!
  • 67. Battery Historian • Battery Historian is a tool to analyze battery consumers and events(DOZE mode).
  • 68. Battery Historian • Battery Historian is a tool to analyze battery consumers and events(DOZE mode). • It uses Android "bugreport" files
  • 69. Battery Historian • Battery Historian is a tool to analyze battery consumers and events(DOZE mode). • It uses Android "bugreport" files • Supports Lollipop (API level 21) and later.
  • 70. Battery Historian • Battery Historian is a tool to analyze battery consumers and events(DOZE mode). • It uses Android "bugreport" files • Supports Lollipop (API level 21) and later. • Shows you where and how processes are drawing current from the battery.
  • 73. Stetho • Stetho is a very powerful tool for debugging. • It enables developers have access to the Chrome Developer Tools feature http://facebook.github.io/stetho/