Hello 👋🏼 I’m Farid Inawan, one of the Co-Founders and the Principal Engineer at JALA. In this moment, I'm happy to inform you that we’ve just released the latest version of JALA App, which is version 1.4.0 🎊 Ta-Da! Apart from it, I’d like to share the story about the “excitement” and the “drama” behind the development process of this latest version of JALA App.
We at JALA are committed to be the “End-to-end Solutions to Increase Shrimp Farm Productivity and Efficiency”. JALA App can be said to be quite unique, most of its users are shrimp farmers. Since shrimp farming is commonly practiced close to the shore, it is challenging for us to develop an app that can work in areas with inadequate communication infrastructure, such as those with limited signal strength and internet connectivity. Therefore, an app that can be used offline is essential, and JALA App has this unique feature.
With the offline mode feature in JALA App, the complexity to develop the app rises. Over the past year, the app can be used, but there are many issues that often occur, which include:
And so begins the story of JALA App Rewrite.
⚠️Warning! Before opting to rewrite, make sure that the existing app can still perform normal functions, and, in my opinion, make sure that the person who leads the Rewrite project understands everything. The one who knows how difficult it will be to continue development with such a code base. If you can focus, 1-3 months may be enough.
We are not alone; several other applications do rewrite as well.
Everything will rewrite in the end 😅 But it’s not always like that, depending on the condition.
To illustrate, JALA App is built with the React Native framework. We have several options given the existing obstacles:
However, with only three mobile engineers who had never worked with Flutter, it was decided that we rewrite using the existing framework since there are layered problems, both in structure and performance. Hopefully, with a more proper structure, the development can be done quicker and the performance can follow.
React Native has matured lately with several performance updates, even during development, there was a major release 0.70 which used new Architure, Fabric, and so on. Catching up on performance with Flutter.
Checkout this tweet by @almouro
That tweet is quite interesting. We tried to update to version 0.70, but it led to chaos 😭 Turns out many libraries are not yet supported and it needs to build C++ for each library. The storage required for development is greater than 3GB 😅 It’s not suitable for the current team. It’s still ineffective for version 0.70 and there are still many pros and cons to its performance. There are already 0.71.1 as of today. So, fellow developers, before upgrading, consider if the library used supports or not. We decided to upgrade from 0.62 to v0.67, which is the default from the most recent Ignite when doing Rewrite.
It's common knowledge that React Native feels heavy when navigating. We have the option of migrating the library to React Native Navigation. We’ve tried to migrate to React Native Navigation and found it to be faster. However, it was after more than one month that the flaws became apparent. React Native Navigation relies on speed by creating a new Fresh Activity on each page, but the updated state on page B does not update to page A and must be handled manually. With these limitations, it appears that the development would be difficult, so we revert to React Navigation, but we upgrade it from v5 to v6. v6 by default has activated React Native Screens which uses native screen performance.
NativeBase is one of the comprehensive UI libraries and has existed since the early days of React Native. We use this library to solve the inconsistent display issue. However, in terms of implementation, the performance drops compared to other libraries. We are still using it for the time being, though, because the “resolve props” feature in components into styles can make developers more productive.
Aside from that, we also use the React Native Web library. To be honest, it’s really useful for the development process because it can be run in a browser, so there’s no need to build for devices and thus saving development time.
We did rewrite about ~130 pages, each with its own unique function. We also revamped the design’s implementation to be pixel perfect so it's more convenient for eyes.
Both Redux and MobX are data storage libraries, but with MobX State Tree library, it is easier for us developers to organize data. We used Redux to store data in previous versions of the app, where individual data was stored based on functions. For example, when we navigate from pond A to pond B, we still use the same storage data but it is replaced with new data. In MobX State Tree, we save the state like a tree. For example, when changing pond navigation, we only need to switch which branch we want to display without reloading the data.
This indirectly improves the performance of JALA App since it previously always loaded data from the database. In fact, with all of the upgrades now in place, this one thing has the most impact on the latest app performance.
We are creating the latest version with automation testing in mind by adding testID on all buttons and pages, so that when we release the next update, it will have passed the automation test.
Clearly not "one last thing", though.
QA vs Developer
One of the results after rewrite:
Indeed, not all the results are good. Here are the results:
|Score Performance while Navigating||Old||New|
|1. Home -> List Ponds (15s)||30||62|
|2. List Ponds -> List Measurements (25s)||31||41|
|3. Scroll List Measurements (10s)||85||50|
|4. Home -> List Monitoring (15s)||57||61|
|5. Scroll List Monitoring (10s)||99||78|
|6. Home -> List Shrimp Prices (10s)*||76||63|
|7. Scroll List Shrimp Prices (10s)*||81||59|
|8. List Shrimp Prices - Detail Shrimp Price (10s)*||95||83|
*The price list for the initial shrimp prices that are fetched are different. In the old version, there are 20 that are fetched, while in the new one, there are 100 that are fetched.
Some issues that are mentioned before:
Some have been resolved, leaving only performance which seems like it can be pushed further.
Finally!!! We missed the deadline😅 But at least we have a friend. Just like Gojek says, "Remember Those Deadlines? We Missed Them" 🙈 (cheering myself up)
Are the results achieved in line with initial expectations? We still feel less perfect, but it’s much better than before.
Developers can access JALA’s repo at https://github.com/atnic. There are several open source projects, one of which is react-native-jala-orm, an Object Relational Mapping (ORM) from sqlite which is heavily inspired by Laravel Eloquent.
In the near future, we have prepared features that we will release to make it easier to monitor records and other exciting things.
To all JALA App users, we’d like to thank you very much for still using JALA App until now, and we want to return the favor by delivering the latest version of JALA App.
Criticism and suggestions are very welcomed. Thank you 🙏
Happy Chinese New Year for those who celebrate! “Gong Xi Fa Cai!” 🧧 (hope you get rich soon!) to JALA and all of you.
Well done, team! Thank you very much!
Get notifications on cultivation tips, feature and service updates, as well as JALA's latest activities.