Embed Size (px)
Citation preview
Product architectureby Royi Benyossef
Failures and lessons learnt
Android developer since 2009Tech community activist, speaker and founderMentor at * acceleratorGoogle expert since 2013Developer relations manager Samsung Next Tel-Aviv
Introduction Royi Benyossef
Introduction Samsung Next Tel-avivCommunity (free-for-all, no strings attached) Investment:
Early stage SW & SaaS startupsSeasoned entrepreneursDeep tech - IoT, AR/VR, cyber, DL, ML, CV,
bots, cloud etc.
Community (free-for-all, no strings attached) Investment (SW & SaaS startups & entrepreneurs) For more information:- samsungnexttlv.com- [email protected]
Introduction Samsung Next Tel-aviv
Prolog
Prolog
Vidmind:Introduction
Prolog
Vidmind:- End-to-end OTT TV
platform
Introduction
Prolog
Vidmind:End-to-end OTT TV platform- Standard backend & clients
Introduction
Prolog
Vidmind:End-to-end OTT TV platform- Standard backend & clients
+ AOSP STB
Introduction
Prolog
Vidmind:End-to-end OTT TV platform- Standard backend & clients
+ Android “based” set-top box
Introduction
Prolog
AOSP STBMe @ Vidmind:
Introduction
Prolog
AOSP STBMe @ Vidmind:
- From Android tech. leader
Introduction
Prolog
AOSP STBMe @ Vidmind:
From Android tech. leader- To Android clients
group manager
Introduction
Prolog
AOSP STBMe @ Vidmind:
From Android tech. leader- To Android clients
group manager(In charge W/ design, dev, arch. & prod.)
Introduction
Prolog
See what we didAgenda
Prolog
See what we didTalk about what went wrong and why
Agenda
Prolog
See what we didTalk about what went wrongSay what we learned from our issues
Agenda
Prolog
See what we didTalk about what went wrongSay what we learned from our issuesShow how we attempted to “fix it”
Agenda
Prolog
See what we didTalk about what went wrongSay what we learned from our issuesShow how we attempted to “fix it”Disclose how that panned out
Agenda
Prolog
See what we didTalk about what went wrongSay what we learned from our issuesShow how we attempted to “fix it”Disclose how that panned outRepeat
Agenda
Chapter 1To be young and hopeful
Chapter 1
One app (launcher) What we did
Chapter 1
One app (launcher)Each “screen” was in a transparent activity
What we did
Chapter 1
One app (launcher)Each “screen” was in a transparent activityRoot app handled video and OpenGL gallery
What we did
Chapter 1
One app (launcher)Each “screen” was in a transparent activityRoot app handled video and OpenGL galleryOn-prem and manual build machine
What we did
Chapter 1
One app (launcher)Each “screen” was in a transparent activityRoot app handled video and OpenGL galleryOn-prem and manual build machine Using proprietary APIs for “special” features
What we did
Chapter 1
Apk size was enormous What we later found
Chapter 1
Apk size was enormous (mostly bad for dev)
What we later found
Chapter 1
Apk size was enormous (mostly bad for dev)UX did not work as the designers asked
What we later found
Chapter 1
Apk size was enormous (mostly bad for dev)UX did not work as the designers askedCodebase became an unmanageable mess
What we later found
Chapter 1
Apk size was enormous (mostly bad for dev)UX did not work as the designers askedCodebase became an unmanageable mess:
> Builds took time and manpower
What we later found
Chapter 1
Apk size was enormous (mostly bad for dev)UX did not work as the designers askedCodebase became an unmanageable mess:
Builds took time and manpower> No QA automation
What we later found
Chapter 1
Apk size was enormous (mostly bad for dev)UX did not work as the designers askedCodebase became an unmanageable mess:
Builds took time and manpowerNo QA automation> Stability was terrible
What we later found
Chapter 1
Apk size was enormous (mostly bad for dev)UX did not work as the designers askedCodebase became an unmanageable mess:
Builds took time and manpowerNo QA automationStability was terrible> Runtime memory was too
much
What we later found
Chapter 1
Apk size was enormous (mostly bad for dev)UX did not work as the designers askedCodebase became an unmanageable mess:
Builds took time and manpowerNo QA automationStability was terrible> Runtime memory was too
much
What we later found
Max runtime =
~2 hours
Chapter 1
Apk size was enormous (mostly bad for dev)UX did not work as the designers askedCodebase became an unmanageable messQA was impossible
What we later found
Chapter 1
We can’t look at this as a normal application
What we learned from it
Chapter 1
We can’t look at this as a normal applicationWe need to seek other implementations
What we learned from it
Chapter 2Throwing a tantrum
Chapter 2
One appWhat we (almost) did
Chapter 2
One app Implemented entirely in OpenGL
What we (almost) did
Chapter 2
OpenGL development is long and hard
What we later found
Chapter 2
OpenGL development is long and hardOpenGL wrappers are meant for games
What we later found
Chapter 2
We have to go back!!!What we learned from it
Chapter 3Minimum changes
Chapter 3
Activities became apps What we did
Chapter 3
Activities became apps (1 per screen + launcher)
What we did
Chapter 3
Activities became apps (1 per screen + launcher)Added a “sticky” service
What we did
Chapter 3
Activities became apps (1 per screen + launcher)Added a “sticky” service Communication (w/ interfaces):
- App to service
What we did
Chapter 3
Activities became apps (1 per screen + launcher)Added a “sticky” service Communication (w/ interfaces):
App to service- Service to app
What we did
Chapter 3
Activities became apps (1 per screen + launcher)Added a “sticky” service Communication (w/ interfaces)Pseudo MVC
What we did
Chapter 3
Activities became apps (1 per screen + launcher)Added a “sticky” service Communication (w/ interfaces)Pseudo MVC* Still using OpenGL gallery
What we did
Chapter 3What we didActivities became apps (1 per screen + launcher)Added a “sticky” service Communication (w/ interfaces)Pseudo MVC* Still using OpenGL gallerySTB HW and FW updated to improve UX
Chapter 3What we didActivities became apps (1 per screen + launcher)Added a “sticky” service Communication (w/ interfaces)Pseudo MVC* Still using OpenGL gallerySTB HW and FW updated to improve UX (Incl. Android API upgrade)
Chapter 3
Services do not live foreverWhat we later found
Chapter 3
Services do not live forever (= instability)
What we later found
Chapter 3
Services do not live forevercomplex development process
What we later found
Chapter 3
Services do not live forevercomplex development process
(= 10 files to add a method)
What we later found
Chapter 3
Services do not live forevercomplex development processAll proprietary APIs changed behavior
What we later found
Chapter 3
Services do not live forevercomplex development processAll proprietary APIs changed behavior
(= needed massive code changes)
What we later found
Chapter 3
Services do not live forevercomplex development processAll proprietary APIs changed behaviorCode maintainability issues
What we later found
Chapter 3
Services do not live forevercomplex development processAll proprietary APIs changed behaviorCode maintainability issues+ builds (still) took time and manpower
What we later found
Chapter 3
Services do not live forevercomplex development processAll proprietary APIs changed behaviorCode maintainability issues+ builds (still) took time and manpower+ No QA automation
What we later found
Chapter 3
Services do not live forevercomplex development processAll proprietary APIs changed behaviorCode maintainability issues+ builds (still) took time and manpower+ No QA automation
= QA was impossible
What we later found
Chapter 3
No more OpenGLWhat we learned from it
Chapter 3
No more OpenGLWe need to work with Android, not against it
What we learned from it
Chapter 3
No more OpenGLWe need to work with Android, not against itWe need a great UX that works on Android
What we learned from it
Chapter 3
No more OpenGLWe need to work with Android, not against itWe need a great UX that works on AndroidBuild and QA automation are a must
What we learned from it
Chapter 3
No more OpenGLWe need to work with Android, not against itWe need a great UX that works on AndroidBuild and QA automation are a mustFeature encapsulation is a must
What we learned from it
Chapter 3
No more OpenGLWe need to work with Android, not against itWe need a great UX that works on AndroidBuild and QA automation are a mustFeature encapsulation is a mustEffective code sharing is a must
What we learned from it
Chapter 4This has to work!
Chapter 4
Maven + jenkins based build machine
What we did
Chapter 4
Maven + jenkins based build machineAppium + Espresso + JUnit automation
What we did
Chapter 4
Maven + jenkins based build machineAppium + Espresso + JUnit automationHAL
What we did
Chapter 4
Maven + jenkins based build machineAppium + Espresso + JUnit automationHAL (Hardware Abstraction Layer)
What we did
Chapter 4
Maven + jenkins based build machineAppium + Espresso + JUnit automationHAL (Hardware Abstraction Layer) Func. based encapsulation
What we did
Chapter 4
Maven + jenkins based build machineAppium + Espresso + JUnit automationHAL (Hardware Abstraction Layer) Func. based encapsulation App dependency management
What we did
Chapter 4
Far faster implementationWhat we later found
Chapter 4
Far faster implementationReduced inter-team dependency
What we later found
Chapter 4
Far faster implementationReduced inter-team dependency allowed us to:
- Increase group size to ~35
What we later found
Chapter 4
Far faster implementationReduced inter-team dependency allowed us to:
Increase group size to ~35- Work in 5 locations (4
countries)
What we later found
Chapter 4
Far faster implementationReduced inter-team dependencyDesigners were happy with the UX
What we later found
Chapter 4
Far faster implementationReduced inter-team dependencyDesigners were happy with the UXImproved performance and stability
What we later found
Chapter 4
Far faster implementationReduced inter-team dependencyDesigners were happy with the UXImproved performance and stabilityImproved work cycle and transparency
What we later found
Chapter 4
Far faster implementationReduced inter-team dependencyDesigners were happy with the UXImproved performance and stabilityImproved work cycle and transparencyHW&FW agnostic product:
What we later found
Chapter 4
Far faster implementationReduced inter-team dependencyDesigners were happy with the UXImproved performance and stabilityImproved work cycle and transparencyHW&FW agnostic product:
> Faster integ. for demos -> easier sale
What we later found
Chapter 4
Far faster implementationReduced inter-team dependencyDesigners were happy with the UXImproved performance and stabilityImproved work cycle and transparencyHW&FW agnostic product:
Faster integ. for demos -> easier sale
> Increased bargaining power with OEMs
What we later found
Summary
Summary
Work better not harderWhat we learned from it
Summary
Work better not harderAutomate as much as possible
What we learned from it
Summary
Work better not harderAutomate as much as possibleWork with your system, not against it
What we learned from it
Summary
Work better not harderAutomate as much as possibleWork with your system, not against it
(HW, SW, FW and people)
What we learned from it
Summary
Work better not harderAutomate as much as possibleWork with your system, not against itNever be afraid to start over (if you can)
What we learned from it
“We should be building great things. Things that Don’t yet exist”
Royi Benyossef samsungnexttlv.com
Hope you liked itThanks for listening!
Royi Benyossef
