FarmSmart App: How We Fell in Love with Flutter.

Respect the refactoring process.


(image credit: Cai Cardenas)

FarmSmart were looking for an app that communicated ‘essential, sustainable and climate-smart farming knowledge’ to smallholder farmers across the globe. They approached us with their partner Amido (https://amido.com/). We jumped at the chance to work on the project and collaborate closely with our favourite London based Agency.

The FarmSmart app had all the characteristics we typically look for when embarking on a new project -  real world utility, a positive message, and it also offered us a technical challenge. We had been looking for a client that was willing to take a leap of faith on a technology that we had been desperate to try out, Google’s Flutter framework. Luckily for us, the partners and founders of FarmSmart were forward-thinking and saw the immense value that this new technology could bring to their app and thus gave us the green light to experiment.

Getting started with Flutter

As it was an entirely new technology to us, getting to grips with the best approach to adopt was initially one of the most difficult challenges we had faced. It soon became clear that the project would need extra care and attention to guarantee its success. If there’s one crucial lesson that we learned about the app development process during our FarmSmart project, it’s to never be afraid of refactoring!

After the first month of development, we decided to restructure the development team so that Lee, Founder of We Are Mobile First, could also venture into the trenches. With most traditional approaches, there is an established development community to fall back on who can offer detailed guidance and share proven ways to structure and organise your code. As Flutter is still so new, we weren’t able to rely on our trusty network for support and we were thus learning on the job! 

Even in an internal context, we have clear ways of working that allow us to start projects quickly and keep on top of the complexity of the product as it develops. We have pipelines and patterns to follow which allow additional developers to onboard with new projects with ease and our apps tend to follow the same rules each time and thus have a cohesive look. Our entire internal process was re-configured when working with Flutter as we had no coding standard and no recommended design pattern to follow. 

This led to some initial decisions that, in hindsight, were suboptimal. For example, we initially chose to pursue the Redux design pattern despite having little to no experience with it because it had been recommended by a few developers starting out with Flutter. It seemed like a good solution as it was well-structured and very functional but it quickly became apparent that the pattern was fighting against the Flutter framework itself. Functionality that was built into the framework was either being replicated or bypassed entirely (namely state). 


(One of our QA test runs, sped-up to show all of the features)

The refactoring process

If we had more time to acclimatize to it, this maybe would’ve proved to be a good approach but, two months in, we made the decision to refactor with an MVVM pattern (Bloc) that we knew worked well. This pattern is now emerging as one of the most popular and recommended approaches from the Flutter community which leads me to believe that we made the right call. 

Major refactors this far into the project are, understandably, often discouraged but looking back it would’ve been a real mistake to carry on as we were. After this initial misstep, the pressure was on to quickly prove the platform to the client and to do so in even less time! 

We soon started to turn a corner, learning lots of new things along the way, and we began to fall in love with Flutter. After two months of using the framework, we started to realise that we were now working at the same pace as we would’ve been when using the native tools that we had relied upon for the last decade. This was surprising and opened up a whole new world of potential for us in terms of our future productivity. 

What were the benefits of using Flutter for this project? 

We’ve talked about wanting to explore Flutter but what were the benefits of Flutter with regards to the FarmSmart project? 

1. Performance

It’s designed to produce 60fps apps. Due to the unique, efficient way Flutter’s rendering engine works, its apps easily support older OS versions and run efficiently on older devices too. 

This worked well for the app's intended user base.


2. Cross-platform support

A killer feature! 

Flutter uses a single codebase for both Android and iOS which thus reduces the development cost.


3. Rapid development

Hot reload of the app on the fly during the development process means it's extremely quick to implement user interfaces. The declarative and modern language also meant less complex code.


4. Future promise

Support for web and desktop applications is now in Beta with the potential to cover Android, iOS, desktop and web from a single codebase and unified approach, thus reducing team size and reducing cost.


Firebase support

FarmSmart is an excellent example of an app that would have been impossible to build just a few years ago on a small startup budget. 

By leveraging the technology of one of the tech behemoths, we effectively got to use their top tier engineers on our startup project. The FarmSmart app thus makes heavy use of the suite of Google software that they’ve been building over the last few years. This is a truly amazing time to be building digital products!

Let’s talk about the backend of the project - the service that runs in the cloud to support the application’s functions, stores the user profiles and allows for the addition of new content.

FarmSmart’s backend is powered by Firebase - another suite of Google-branded technology. Firebase has grown over the years to include just about everything you will need to power a modern mobile application.

The most interesting element of Firebase for us is Firestore. 

This product allows you to create an app around a data model and receive real-time, streamed updates as the data model is manipulated. This means you can have a fully reactive system all the way from the backend to the frontend. When data is changed in the cloud, the change is instantly pushed to any clients that are currently connected. This highlights some groundbreaking differences from the traditional poll/pull approach. For example, pull to refresh can be eliminated since the change can be pushed from the server and trigger an automatic reload of the affected screen. 

Admittedly, you do have to consider more on the UI side of things with this approach - like not having the screen scroll without the user interacting when the updates come in. This effectively means, however, that apps act like a shared Google Doc where changes are reactive and shown to the user as they happen (if that’s what you choose to do in the app as you're ultimately in control of when to release the changes). Firestore also abstracts the intermediary formatting so implementations can basically skip a step of translation and receive the data in a convenient form, much like what you would get post-JSON-parser in traditional approaches. 

The Firebase suite also offers cloud functions. These functions can be triggered on HTTP requests, direct client calls using the client SDK, or events in the Firebase system, like the powerful database change event. Using these functions, you can build almost any system imaginable. As the system is functional and reactive, elements can have good separation and are inherently scalable and reusable. 

The FarmSmart app contains a lot of content that needs to be created and uploaded to the system by content creators with minimal technical knowledge. In order to save time, we decided to try out a CMS for Firestore called ‘Flamelink’. Flamelink is a backend web application that populates a set structure in the Firebase Firestore product. This gave us an excellent MVP solution out of the box. 

We did, however, feel that we could improve upon the content creation pipeline if we built a custom CMS - something that Flutter would allow us to do for the first time in our company history.  However, since it met the minimum requirements, we decided to stick with the ready-made solution for now.

///

The FarmSmart app seeks to empower and educate farmers across the globe. Its development process most certainly served to empower and educate us in terms of how we will be moving forward with development from here on out. 

The FarmSmart app is available via the Google Play store.

Read more about our adventures with Flutter - Benefits of Flutter: mobile-first development with Flutter.

Ready to invest in our mobile app development services? Email us at hi@wearemobilefirst.com.