Product architecture is the scheme by which the function of a product is allocated to physical components. The process includes building out a software and hardware product, while simultaneously conducting market research, receiving customer feedback, and developing the hardware, must be an informed and strategic process.In his session Royi will discuss the various architectures that were required for his team to develop in order to achieve different, yet optimal product versions for the Vidmind product. Through each product version, Royi covered where they went wrong and elaborate on what the company did to resolve these challenges in the next version and of course the outcome of each change that was implemented.

1. Product architecture
by Royi Benyossef
Failures and lessons learnt

2. Android developer since 2009
Tech community activist, speaker and founder
Mentor at * accelerator
Google expert since 2013
Developer relations manager SamsungNext Tel-Aviv
Introduction
Royi Benyossef

3. Introduction
Samsung Next Tel-aviv
Community (free-for-all, no strings attached)
Investment:
Early stage SW & SaaS startups
Seasoned entrepreneurs
Deep tech
- IoT, AR/VR, cyber, DL, ML, CV, bots, cloud etc.

4. Community (free-for-all, no strings attached)
Investment (SW & SaaS startups & entrepreneurs)
For more information:
- samsungnexttlv.com
- royi@samsungnext.com
Introduction
Samsung Next Tel-aviv

5. Prolog

6. Prolog
Vidmind:
Introduction

7. Prolog
Vidmind:
- End-to-end OTT TV platform
Introduction

8. Prolog
Vidmind:
End-to-end OTT TV platform
- Standard backend & clients
Introduction

9. Prolog
Vidmind:
End-to-end OTT TV platform
- Standard backend & clients
+ AOSP STB
Introduction

10. Prolog
Vidmind:
End-to-end OTT TV platform
- Standard backend & clients
+ Android “based” set-top box
Introduction

11. Prolog
AOSP STB
Me @ Vidmind:
Introduction

12. Prolog
AOSP STB
Me @ Vidmind:
- From Android tech. leader
Introduction

13. Prolog
AOSP STB
Me @ Vidmind:
From Android tech. leader
- To Android clients group manager
Introduction

14. Prolog
AOSP STB
Me @ Vidmind:
From Android tech. leader
- To Android clients group manager
(In charge W/ design, dev, arch. & prod.)
Introduction

15. Prolog
See what we did
Agenda

16. Prolog
See what we did
Talk about what went wrong and why
Agenda

17. Prolog
See what we did
Talk about what went wrong
Say what we learned from our issues
Agenda

18. Prolog
See what we did
Talk about what went wrong
Say what we learned from our issues
Show how we attempted to “fix it”
Agenda

19. Prolog
See what we did
Talk about what went wrong
Say what we learned from our issues
Show how we attempted to “fix it”
Disclose how that panned out
Agenda

20. Prolog
See what we did
Talk about what went wrong
Say what we learned from our issues
Show how we attempted to “fix it”
Disclose how that panned out
Repeat
Agenda

21. Chapter 1
To be young and hopeful

22. Chapter 1
One app (launcher)
What we did

23. Chapter 1
One app (launcher)
Each “screen” was in a transparent activity
What we did

24. Chapter 1
One app (launcher)
Each “screen” was in a transparent activity
Root app handled video and OpenGL gallery
What we did

25. Chapter 1
One app (launcher)
Each “screen” was in a transparent activity
Root app handled video and OpenGL gallery
On-prem and manual build machine
What we did

26. Chapter 1
One app (launcher)
Each “screen” was in a transparent activity
Root app handled video and OpenGL gallery
On-prem and manual build machine
Using proprietary APIs for “special” features
What we did

27. Chapter 1
Apk size was enormous
What we later found

28. Chapter 1
Apk size was enormous (mostly bad for dev)
What we later found

29. Chapter 1
Apk size was enormous (mostly bad for dev)
UX did not work as the designers asked
What we later found

30. Chapter 1
Apk size was enormous (mostly bad for dev)
UX did not work as the designers asked
Codebase became an unmanageable mess
What we later found

31. Chapter 1
Apk size was enormous (mostly bad for dev)
UX did not work as the designers asked
Codebase became an unmanageable mess:
> Builds took time and manpower
What we later found

32. Chapter 1
Apk size was enormous (mostly bad for dev)
UX did not work as the designers asked
Codebase became an unmanageable mess:
Builds took time and manpower
> No QA automation
What we later found

33. Chapter 1
Apk size was enormous (mostly bad for dev)
UX did not work as the designers asked
Codebase became an unmanageable mess:
Builds took time and manpower
No QA automation
> Stability was terrible
What we later found

34. Chapter 1
Apk size was enormous (mostly bad for dev)
UX did not work as the designers asked
Codebase became an unmanageable mess:
Builds took time and manpower
No QA automation
Stability was terrible
> Runtime memory was too much
What we later found

35. Chapter 1
Apk size was enormous (mostly bad for dev)
UX did not work as the designers asked
Codebase became an unmanageable mess:
Builds took time and manpower
No QA automation
Stability was terrible
> Runtime memory was too much
What we later found

36. Chapter 1
Apk size was enormous (mostly bad for dev)
UX did not work as the designers asked
Codebase became an unmanageable mess
QA was impossible
What we later found

37. Chapter 1
We can’t look at this as a normal application
What we learned from it

38. Chapter 1
We can’t look at this as a normal application
We need to seek other implementations
What we learned from it

39. Chapter 2
Throwing a tantrum

40. Chapter 2
One app
What we (almost) did

41. Chapter 2
One app
Implemented entirely in OpenGL
What we (almost) did

42. Chapter 2
OpenGL development is long and hard
What we later found

43. Chapter 2
OpenGL development is long and hard
OpenGL wrappers are meant for games
What we later found

44. Chapter 2
We have to go back!!!
What we learned from it

45. Chapter 3
Minimum changes

46. Chapter 3
Activities became apps
What we did

47. Chapter 3
Activities became apps (1 per screen + launcher)
What we did

48. Chapter 3
Activities became apps (1 per screen + launcher)
Added a “sticky” service
What we did

49. Chapter 3
Activities became apps (1 per screen + launcher)
Added a “sticky” service
Communication (w/ interfaces):
- App to service
What we did

50. 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

51. Chapter 3
Activities became apps (1 per screen + launcher)
Added a “sticky” service
Communication (w/ interfaces)
Pseudo MVC
What we did

52. 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

53. Chapter 3
What we did
Activities became apps (1 per screen + launcher)
Added a “sticky” service
Communication (w/ interfaces)
Pseudo MVC
* Still using OpenGL gallery
STB HW and FW updated to improve UX

54. Chapter 3
What we did
Activities became apps (1 per screen + launcher)
Added a “sticky” service
Communication (w/ interfaces)
Pseudo MVC
* Still using OpenGL gallery
STB HW and FW updated to improve UX
(Incl. Android API upgrade)

55. Chapter 3
Services do not live forever
What we later found

56. Chapter 3
Services do not live forever (= instability)
What we later found

57. Chapter 3
Services do not live forever
complex development process
What we later found

58. Chapter 3
Services do not live forever
complex development process
(= 10 files to add a method)
What we later found

59. Chapter 3
Services do not live forever
complex development process
All proprietary APIs changed behavior
What we later found

60. Chapter 3
Services do not live forever
complex development process
All proprietary APIs changed behavior
(= needed massive code changes)
What we later found

61. Chapter 3
Services do not live forever
complex development process
All proprietary APIs changed behavior
Code maintainability issues
What we later found

62. Chapter 3
Services do not live forever
complex development process
All proprietary APIs changed behavior
Code maintainability issues
+ builds (still) took time and manpower
What we later found

63. Chapter 3
Services do not live forever
complex development process
All proprietary APIs changed behavior
Code maintainability issues
+ builds (still) took time and manpower
+ No QA automation
What we later found

64. Chapter 3
Services do not live forever
complex development process
All proprietary APIs changed behavior
Code maintainability issues
+ builds (still) took time and manpower
+ No QA automation
= QA was impossible
What we later found

65. Chapter 3
No more OpenGL
What we learned from it

66. Chapter 3
No more OpenGL
We need to work with Android, not against it
What we learned from it

67. Chapter 3
No more OpenGL
We need to work with Android, not against it
We need a great UX that works on Android
What we learned from it

68. Chapter 3
No more OpenGL
We need to work with Android, not against it
We need a great UX that works on Android
Build and QA automation are a must
What we learned from it

69. Chapter 3
No more OpenGL
We need to work with Android, not against it
We need a great UX that works on Android
Build and QA automation are a must
Feature encapsulation is a must
What we learned from it

70. Chapter 3
No more OpenGL
We need to work with Android, not against it
We need a great UX that works on Android
Build and QA automation are a must
Feature encapsulation is a must
Effective code sharing is a must
What we learned from it

71. Chapter 4
This has to work!

72. Chapter 4
Maven + jenkins based build machine
What we did

73. Chapter 4
Maven + jenkins based build machine
Appium + Espresso + JUnit automation
What we did

74. Chapter 4
Maven + jenkins based build machine
Appium + Espresso + JUnit automation
HAL
What we did

75. Chapter 4
Maven + jenkins based build machine
Appium + Espresso + JUnit automation
HAL (Hardware Abstraction Layer)
What we did

76. Chapter 4
Maven + jenkins based build machine
Appium + Espresso + JUnit automation
HAL (Hardware Abstraction Layer)
Func. based encapsulation
What we did

77. Chapter 4
Maven + jenkins based build machine
Appium + Espresso + JUnit automation
HAL (Hardware Abstraction Layer)
Func. based encapsulation
App dependency management
What we did

78. Chapter 4
Far faster implementation
What we later found

79. Chapter 4
Far faster implementation
Reduced inter-team dependency
What we later found

80. Chapter 4
Far faster implementation
Reduced inter-team dependency allowed us to:
- Increase group size to ~35
What we later found

81. Chapter 4
Far faster implementation
Reduced inter-team dependency allowed us to:
Increase group size to ~35
- Work in 5 locations (4 countries)
What we later found

82. Chapter 4
Far faster implementation
Reduced inter-team dependency
Designers were happy with the UX
What we later found

83. Chapter 4
Far faster implementation
Reduced inter-team dependency
Designers were happy with the UX
Improved performance and stability
What we later found

84. Chapter 4
Far faster implementation
Reduced inter-team dependency
Designers were happy with the UX
Improved performance and stability
Improved work cycle and transparency
What we later found

85. Chapter 4
Far faster implementation
Reduced inter-team dependency
Designers were happy with the UX
Improved performance and stability
Improved work cycle and transparency
HW&FW agnostic product:
What we later found

86. Chapter 4
Far faster implementation
Reduced inter-team dependency
Designers were happy with the UX
Improved performance and stability
Improved work cycle and transparency
HW&FW agnostic product:
> Faster integ. for demos -> easier sale
What we later found

87. Chapter 4
Far faster implementation
Reduced inter-team dependency
Designers were happy with the UX
Improved performance and stability
Improved work cycle and transparency
HW&FW agnostic product:
Faster integ. for demos -> easier sale
> Increased bargaining powerwith
OEMs
What we later found

88. Summary

89. Summary
Work better not harder
What we learned from it

90. Summary
Work better not harder
Automate as much as possible
What we learned from it

91. Summary
Work better not harder
Automate as much as possible
Work with your system, not against it
What we learned from it

92. Summary
Work better not harder
Automate as much as possible
Work with your system, not against it
(HW, SW, FW and people)
What we learned from it

93. Summary
Work better not harder
Automate as much as possible
Work with your system, not against it
Never be afraid to start over (if you can)
What we learned from it

94. “We should be building great
things. Things that Don’t yet
exist”

95. Royi Benyossef
samsungnexttlv.com
Hope you liked it
Thanks for listening!
Royi Benyossef
(royi@samsungnext.com)