Raditya Gumay
GOJEK, Lead of Android Developer Experience
Jakarta, Indonesia
Raditya Gumay is a Technopreneur, Software Engineer, and Research. Nowadays, he work at GOJEK indonesa. He also a technical product leader and entrepreneur with a history of designing, developing and commercializing high-polish products that share a focus on user experience innovative.
Raditya also mastering in Machine Learning such Backpropagation Neural Network. You can follow him on Twitter at @r_adiit or keep up with his blog by visiting radityalabs.net. and medium at medium.com/@gumay.raditya.
Area of Expertise
Topics
Kotlin API Transparency for Library Author
API Transparency for Library Authors
As a library author, we sometimes forget about fundamental requirements that need to be available.
In this presentation, I will cover things that need to be set by library authors to make sure the library that they provide has clarity and easy to use.
Agenda
1. Code and Naming Convention
- *OrNull
- *orDefault
- consistency of naming
- get/fetch/read
- set/save/store
2. explictAPI (Kotlin Compiler)
- strictMode
- kotlin binary compatibility
- why we should not omit return type
- clarity
3. Deprecation Stages
4. Rollout Experimental APIs
5. Kotlin Hidden Cost
- Feature Languages
- Impurity (side-effects)
Advance Reactive UI with FlowBinding
This talk highlights the challenges of how engineers could avoid accidentally side-effects on UI programming and embraces unidirectional data flow.
This talks also introduce FlowBinding APIs, which allow us to interact with Android Widget APIs reactively. The talk will address how Kotlin aims to solve this problem with coroutines by providing a unidirectional data flow.
This talk would cover:
- FlowBinding
- Primary and Secondary State
- Unidirectional Data Flow
- Kotlin StateFlow, ShareFlow
Spek for Rock-Solid BDD in Android
As engineer we should have a confidence level when implement feature or even do bug fixes. In term of development process sometimes do test is not easy as we should, changes sometimes also affect to another code. Under the hood good practices for do unit test is also following by good architecture for separation of concern.
In development we commonly do a review code for checking our code is good enough and do static analysis and another acceptable criteria. In practice, this quite challenging as engineer we have to do code review, if the code is not using appropriate design pattern and practice. In other hand as we seen in way of jUnit, they does not have good structure and context for do a grouping code and this make review test quite so hard.
In our case, we use MVP Clean Architecture in our codebases, and using spek make our test much more fun and great!, last but not least spek in different way, they have good context and grouping feature that’s make create test and test review easier.
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top