Blibli.com: Android Evolution
Evolution is technically defined as: “a gradual process in which something changes into a different and usually more complex or better form”.
Intro
Blibli.com android app has reached its 4th evolution in its life. Each evolution makes it more complex and better as an app.
Evolution
1st Evolution
When it was born, we planned to build a lite application which only has a home page, product list, product detail, checkout, payment and order detail. We kept this in production until we realize, we didn’t have space to do promotions, flash sales, etc. Since that, we took this down, because the project members have been taken by another project.
2nd Evolution
At that time, we don’t have dedicated person for Android development (we were re-writing blibli.com systems), so we decided to make a launcher, it was built by Titanium, a platform that enables us to build a hybrid mobile application. The thing is, it was only a launcher when we click the app icon, it will open blibli.com web :)))). In this way, if we have a new feature, the development can be only in blibli.com web :))).
This is just the beginning
3rd Evolution
At some point, we decided to write the entire app in native and it started from the scratch, to compete with web features, we need to make it as fast as possible. So, we were ended up with unscalable and unmaintainable code, APIs were being called in Activity-s, Fragments even Dialogs, entire business logic put in single class along with APIs, attributes defined as static so it can be called everywhere, hardcoded strings value, magic numbers, code duplications, un-tested code, etc.
In the early of its evolution, it only has 1 product, it is Retail with a minimalist feature. So, it was like “Okay, we can handle it”, “I know where to change”, but time is running and more features and products were added, such as Digital, Hotel, and Train. Developers need more time to identify and fix production issues. Eventually, we were ended up with bigger unscalable and unmaintainable code.
Until that time, we realized we can’t let this getting bigger and bigger. we have to do something.
4th Evolution
After we realized we have to change but we can’t stop our development, we decided to evolve gradually.
Evolution is gradual process and we do it gradually
— Recursive
All new things (features, classes, attributes, strings) will follow new rules and new tech-stack that we have decided before
Rule:
1. Put in New Package
2. One feature, one package
3. MVP Pattern
4. Naming convention
5. Decrease EventBus usage, use more Interface
6. Styling and Theming
7. Base Classes
8. Unit Test with 80% coverage
9. etc.Tech-Stack:
1. Retrofit2
2. Dagger2
3. RxJava
4. etc.
Before we implement these rules to the project, we made a proof-of-concept from the simplest-but-not-simple-thing. Yes, it is the Splash Screen. After it succeeds, we continue to another existing screen and new features.
With these rules, it made us put more effort in Tech Design phase because we have to decide this thing belongs to this package or that package.
But what about the old code??
With these changes, we made it more scalable and maintainable. How? Example, to increase our traceability we have rule #2 One feature, one package, #3 MVP Pattern, #5. Decrease EventBus usage, use more Interface, for readability we have rule #4 Naming convention and tech-stack #2 Dagger2, for reducing boilerplate we have rule #6 Styling and Theming and #7 Base Classes and tech-stack #3 RxJava, etc…
But this is not the end. We got a new problem, remember we still have old-package which contains shit.
We still had the unscalable and unmaintainable code and requirement never stop. We are adding a little thing, then add a little thing again, then add little thing again, until the shit becomes BIGGER…
Not only that, technology is growing so fast. Example when we started the 4th evolution; Kotlin, LiveData, Room, ViewModel, etc. don’t exist. When those technologies came to realization, we have to update our code with those technologies. Slowly, our code felt like a mess, many standards, many updates, many code bases. (old-package, new-package, new-package with update).
This situation makes us work faster and smarter than a normal human since our target is to take down the old-package and complete the new-package, we have to do rewrite during bugfix timeline.
For us the developers, this is very challenging and helps us to LEARN MANY THINGS, as an eager-learner and tech-enthusiast, we love doing this. You must be aware, there are many things in Blibli.com android application that needs to be improved and updated.
So, if you are an eager-learner and tech-enthusiast who wants to be a part of its 5th Evolution, please contact me via email :)
