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
380
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
隙間時間で爆速開発! Claude Code × Vibe Coding で作るマニュアル自動生成サービス
akitomonam
2
200
手動からの解放!!Strands Agents で実現する総合テスト自動化
ideaws
3
390
経験がないことを言い訳にしない、 AI時代の他領域への染み出し方
parayama0625
0
260
ecspressoの設計思想に至る道 / sekkeinight2025
fujiwara3
12
2.1k
AIを使っていい感じにE2Eテストを書けるようになるまで / Trying to Write Good E2E Tests with AI
katawara
3
1.9k
CSPヘッダー導入で実現するWebサイトの多層防御:今すぐ試せる設定例と運用知見
llamakko
1
270
分散トレーシングによる コネクティッドカーのデータ処理見える化の試み
thatsdone
0
270
M365アカウント侵害時の初動対応
lhazy
7
5.1k
激動の時代、新卒エンジニアはAIツールにどう向き合うか。 [LayerX Bet AI Day Countdown LT Day1 ツールの選択]
tak848
0
610
Kiroから考える AIコーディングツールの潮流
s4yuba
1
420
FAST導入1年間のふりかえり〜現実を直視し、さらなる進化を求めて〜 / Review of the first year of FAST implementation
wooootack
1
190
なぜAI時代に 「イベント」を中心に考えるのか? / Why focus on "events" in the age of AI?
ytake
2
810
Featured
See All Featured
Agile that works and the tools we love
rasmusluckow
329
21k
Practical Orchestrator
shlominoach
189
11k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
50
5.5k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
44
2.4k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
110
19k
The Invisible Side of Design
smashingmag
301
51k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.6k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
What’s in a name? Adding method to the madness
productmarketing
PRO
23
3.6k
How GitHub (no longer) Works
holman
314
140k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
Code Reviewing Like a Champion
maltzj
524
40k
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