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
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.
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.
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!
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
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!
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!
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/