Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Building stable and flexible libraries
Search
Keishin Yokomaku
December 17, 2014
Technology
1
3k
Building stable and flexible libraries
Keishin Yokomaku
December 17, 2014
Tweet
Share
More Decks by Keishin Yokomaku
See All by Keishin Yokomaku
One screen, many BottomSheets
keithyokoma
0
390
LazyColumnのitemがViewPortの中で占める領域の割合を知りたい
keithyokoma
0
650
Build apps for Cars
keithyokoma
0
520
Save the state
keithyokoma
0
570
Either in Kotlin
keithyokoma
0
580
持続的なアプリ開発のためのDXを支える技術
keithyokoma
2
5.2k
Make the objects serializable with kotlinx.serialization
keithyokoma
0
5.1k
Kotlin で書く Gradle Custom Tasks
keithyokoma
0
540
DX Improvements
keithyokoma
3
400
Other Decks in Technology
See All in Technology
激動の時代、新卒エンジニアはAIツールにどう向き合うか。 [LayerX Bet AI Day Countdown LT Day1 ツールの選択]
tak848
0
620
Gemini in Android Studio - Google I/O Bangkok '25
akexorcist
0
100
AI人生苦節10年で会得したAIがやること_人間がやること.pdf
shibuiwilliam
1
230
帳票構造化タスクにおけるLLMファインチューニングの性能評価
yosukeyoshida
1
190
少人数でも回る! DevinとPlaybookで支える運用改善
ishikawa_pro
5
1.9k
OpenTelemetry の Log を使いこなそう
biwashi
5
1.1k
Kiroから考える AIコーディングツールの潮流
s4yuba
2
540
FAST導入1年間のふりかえり〜現実を直視し、さらなる進化を求めて〜 / Review of the first year of FAST implementation
wooootack
1
210
地域コミュニティへの「感謝」と「恩返し」 / 20250726jawsug-tochigi
kasacchiful
0
110
【CEDEC2025】現場を理解して実現!ゲーム開発を効率化するWebサービスの開発と、利用促進のための継続的な改善
cygames
PRO
0
510
마라톤 끝의 단거리 스퍼트: 2025년의 AI
inureyes
PRO
1
170
【CEDEC2025】LLMを活用したゲーム開発支援と、生成AIの利活用を進める組織的な取り組み
cygames
PRO
1
2k
Featured
See All Featured
Optimising Largest Contentful Paint
csswizardry
37
3.4k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
130
19k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.8k
Rails Girls Zürich Keynote
gr2m
95
14k
A better future with KSS
kneath
238
17k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Designing for Performance
lara
610
69k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.8k
Agile that works and the tools we love
rasmusluckow
329
21k
Why You Should Never Use an ORM
jnunemaker
PRO
58
9.5k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
50
5.5k
Transcript
Building stable and flexible libraries @KeithYokoma - Drivemode, Inc. potatotips
#12
KeithYokoma Keishin Yokomaku Drivemode, Inc. Android Engineer GitHub: https://github.com/KeithYokoma e-Book:
http://amzn.to/1mZNydv
Agenda • Stability • Flexibility
Make libraries STABLE
Make libraries STABLE • Entity class declaration • Multi-thread compatibility
• Lifecycle management
Make libraries STABLE • Entity class declaration • Don’t •
Do void setToken(String token, String type, String refresh, long by); void setToken(AccessToken token);
Make libraries STABLE • Entity class declaration • Hard to
remember the type of args • Not Type-Safe(ref. Effective Java) void setToken(String token, String type, String refresh, long by);
• Entity class declaration • Easy to remember the type
of args • Type-Safe void setToken(AccessToken token); Make libraries STABLE
Make libraries STABLE • Multi-thread compatibility • Synchronization • Immutable
entity • Thread pool and callback lifecycle • Singleton implementation
Make libraries STABLE • Multi-thread compatibility • Synchronization • “synchronized”
block • Synchronization utils(CyclicBarrier, …) • Atomicity(AtomicInteger, …) • “volatile” field
Make libraries STABLE • Multi-thread compatibility • Immutable entity •
Immutable entity is thread safe
Make libraries STABLE • Multi-thread compatibility • Thread pool and
callback lifecycle • Reduce thread initialization cost • Align callback lifetime with “Context” • Do NOT callback to dead object
Make libraries STABLE • Multi-thread compatibility • Singleton implementation •
Be aware of “Lazy Initialization”
// NOT thread safe!! public class Singleton { private static
Singleton sInstance; public static Singleton getInstance() { if (sInstance == null) { sInstance = new Singleton(); } return sInstance; } } Case Study Multi-thread compatibility
Make libraries STABLE • Multi-thread compatibility • Singleton implementation •
“synchronized” block • Double checked locking • Initialization on demand holder
private static Singleton sInstance; public static synchronized Singleton getInstance() {
if (sInstance == null) { sInstance = new Singleton(); } return sInstance; } Case Study Multi-thread compatibility
private static volatile Singleton sInstance; public static Singleton getInstance() {
if (sInstance == null) { synchronized (Singleton.class) { if (sInstance == null) { sInstance = new Singleton(); } } } return sInstance; } Case Study Multi-thread compatibility
static class Holder { public static final Singleton SINGLETON =
new Singleton(); } public static getInstance() { return Holder.SINGLETON; } Case Study Multi-thread compatibility
Make libraries STABLE • Lifecycle management • Object lifetime alignment
Make libraries STABLE • Lifecycle management • Object lifetime alignment
• Lifecycle methods of various “Context” • onCreate/onDestroy • onStart/onStop, onResume/onPause
Make libraries STABLE • Lifecycle management • Object lifetime alignment
• Naming convention • add/remove, register/unregister • start/finish, initialize/destroy
Make libraries FLEXIBLE
Make libraries FLEXIBLE • Annotations vs Listeners • Customizable resources
• Split package by domain
Make libraries FLEXIBLE • Annotations ✓ Fast and easy development
for client ✓ Automatic code generation(with apt) ✗ Slow(both runtime and apt takes time) ✗ Hard to dig into library itself
Make libraries FLEXIBLE • Listeners ✓ Faster than annotations(runtime) ✓
Simple architecture ✗ Client should maintain the lifetime
Make libraries FLEXIBLE • Annotations and Listeners • Do NOT
call methods of dead object
• Customizable resources • If the library has UI resources…
• Theme should be customizable • What about layout resources? Make libraries FLEXIBLE
• Customizable resources • At least you need to… •
Define ID resources that the library uses • Otherwise layout may not be customized Make libraries FLEXIBLE
Make libraries FLEXIBLE • Split package by domain • Avoid
exceeding 65k method limit • Less effort to strip out codes not used
Make libraries FLEXIBLE • Split package by domain • e.g.
Guava • guava, guava-gwt, guava-annotations, … • e.g. Google Play Services 6.5 • play-services, play-services-wearable, …
–Joshua Bloch “Never make the client do anything the library
can do for the client.”
Building stable and flexible libraries @KeithYokoma - Drivemode, Inc. potatotips
#12