Experience on building PWA using Flutter

When we start a project for mobile use, we have several possible solutions. From the native application to the website, through the use of hybrid technologies, the choice is quite wide. Each solution has its pros & cons, and the choice often depends on the nature of the application to develop as well as the user experience we want to offer.

The Supply teams of ADEO Leroy Merlin tackled these same questions when developing three applications. In this article, focusing on one of these applications, we present the context, the decisions and the solution that has been built and tested, the problems encountered and the next steps considered.

Use Cases and Constraints

In the context of the Supply Chain Digital Platform (SCDP), Instore Operation Domain (ISO), we have chosen in 2020 to develop new digital products internally. The aim was to build a base for store logistics, global to all ADEO Business Units (BU) in the world and for a park of more than 500 target stores. In compliance with five ADEO drivers (UX First, Open Agile Product, Modular Architecture, ADEO as inner platform and Pragmatic Business partner), we have therefore built a strategy around the three main Architecture Building Blocks of store logistics:

• receipt of goods: Receiv’it
• inventory management: Stock It Easy
• preparation of customer orders: Pick&Go

2020 context: Pick&Go product MVP

At this time, we took two main assumptions for the choice of our stack. We wish to find a solution to avoid the intricacies of native Android, by choosing a technology offering a layer of abstraction, and share a common UX and libraries within ADEO (authentication, article sheet, Design System, etc.).

So we decided on Flutter technology.

Flutter is an open source project allowing, at the start of our projects, to develop cross-platform mobile applications (iOS and Android), from a single source code developed in Dart.

The mobile teams already had experience in developing applications for the various Leroy Merlin BUs (France, Italy, Brazil, Russia, etc.).

The objective of a single application used by the different BU of the group poses several problems during the design and development of the product.

• The diversity of Android smartphones used within these BU is significant and would require an additional workload for the development teams.
• The deployment of new versions of the application is more or less easy depending on the BU. Indeed, some of them do not use any MDM (Mobile Device Management) or use one differently. This difference in usage generates quite substantial times for the deployment of a new version of native applications, which impacts the agility of the team: complicated rollback to perform, more tests to be planned, …

A native Flutter development was perhaps not the optimal solution, due to the points previously mentioned. But it made it possible to start using existing modules and libraries. The development continued until the deployment of the application.

2021 context: International deployment of Pick&Go.

The Pick&Go application was therefore quickly deployed quite widely in four BUs: Leroy Merlin France, Italy, South Africa and Poland (around 200 stores). A little later it was deployed in LM Spain.

Following this large-scale deployment of the application, and unfortunately without too much surprise, we quickly noticed and confirmed the limits of the model:

• Fragmentation of versions installed in production between BU and within the same BU
• Issues related to the use and management of MDM Workspace One in a few BUs

We have decided to review our strategy in order to limit the problems mentioned above and to explore the web track. At that time, the reality of the deployments confirmed this intuition. In the rest of the article, we will discuss the different options available to us, and explain in detail the technology used.

Solutions not adopted

In the mobile world, when we have to design an application, we have several possibilities:

• Native application developed for Android and/or iOS.
• Hybrid Application, with a single code, being able to generate two applications for both platforms. We can mention, for example, solutions such as Xamarin, Cordova or even… Flutter.
• Progressive Web App (PWA) type application using web technologies: HTML, CSS and JavaScript

As a reminder, a PWA is a web application on steroids, using in particular new Web APIs to improve the mobile experience. We can mention for example:

• The service worker to manage the offline mode of static and dynamic requests
• The Manifest file allowing, with other criteria, to make a website installable
• The notifications…

We invite you to read the article that we have already published on this subject.

If you have correctly understood the critical points of the team (collaboration with an existing native, and heterogeneity of the fleet of devices across the BU), the three solutions were not acceptable and/or optimal.

Except if….Flutter soon announces that Flutter Web (project in beta at the time) is now ready for production, and thus usable within Leroy Merlin. Which will be done in March 2021 with the release of Flutter 2. Perfect Timing. This would make it possible to keep the same code base, not to start all over again by adapting the deployment method.

https://medium.com/flutter/flutter-web-support-hits-the-stable-milestone-d6b84e83b425

What benefits did we get?

Thanks to this technical solution, the migration of our existing Flutter application to PWA mode was not hard. There were some minor adjustments on the graphical components to adapt to the Web and the type of deliverable changed.

Quickly adopted, our next-generation application has already solved most of the previous problems, indeed new ones that we did not expect.

• As we are based on a web deployment, the rollback of the application in the event that a regression is detected, is a process known and mastered for a long time by our teams.
• On this same deployment mode, we are sure that our users have the latest version of the application. For readers familiar with PWAs, we might wonder how the update of the cache of static resources is managed following a new deployment; the application simply forces the user to refresh his PWA to retrieve the new version .
• Our application is now easily shareable via the use of its URL.

But have we encountered any limitations? Here are 3 preconceptions we can read on the internet, and our experience about them

• The UX of a Flutter PWA is not optimal because it does not respect the rules of Android and iOS platforms? This was not a problem for us, because one of our main goal was to use the global ADEO Design System of Adeo on all our products.
• Flutter being a fairly recent technology, the experience and skill development of the developer could be complicated? Within ADEO, we did not feel this. Thanks to the support of passionate Flutter experts, the rise in skills was quite rapid, and all the Android and/or IOS (Swift) developers became autonomous quite quickly.
• Again because of its youth, the Dart ecosystem may not be large enough? This may have been the case at the start of the project, but not for the past 10 months. Indeed, following Flutter 2, the open source ecosystem and the functionalities added directly by Google make it possible to cover all the needs of our applications.

In addition, internal innersource projects are being developed to remedy any shortcomings.

In fact, we have omitted a major obstacle that has stood in our way. A functional need was missing during the development of our application (missing or not having the quality required for our project): the possibility of scanning barcodes: central application functionality since scanning is a critical gesture in the logistics world.

Scan and Scandit module

Store logistics require a systematic scanning gesture, in order to verify that the product is the right one and to facilitate its traceability. Example on customer order picking:

For the use of the camera, this required the use of different non-paying libraries between native and web. At this level, the native scanning functions in APK mode are very efficient. To advance on a first web version, our team has developed an image interpretation module. But it was too slow: almost 3 seconds of latency on average was not acceptable from the business point of view.

In order to offer another viable solution, we have initiated an A/B testing process by offering two PWA-compatible scanning Proof of concept (POC) prototypes.

• POC1: Scan management via a native application (Flutter), communicating with the PWA via a Custom Scheme system.
• POC2: Scandit implementation in web mode, with a test license

Below are the results of these two POCs.

POC1: Native Application and communication via Custom Scheme

• Complex technical deployment always needs an MDM.
• Complex user experience: lack of fluidity in use
• If the user does not install the PWA, different tabs may be created during operation, which can impact the device performance as well as power consumption (repeated scanning activity at large scale, continuously, all day long …)

POC2: Scandit in web mode

• Scandit has already been validated by another team but in native mode, in various comparative scan studies.
• Web-ready but not yet proven at the time. Many adjustments were required before obtaining satisfactory responsiveness when integrated into our applications.
• Unrivaled scanning responsiveness in terms of recognizing the variety of barcode types (color, small size, standards, QR code) in stores and in all types of field conditions (low light, quality of light, device camera, vertical/horizontal position, etc.)

Solution chosen: Scandit web

The solution was deployed to one store in Bologna in January and February 2022 with a few test licenses to prove performance under real store production conditions. Management of degraded barcode cases, labels of different colors. Coupled with the ease of deployment to all users.

What are the next steps ?

The project is far from the end: we have to face other technical challenges.

The first challenge is to think about the data caching architecture that we want to implement in our application. Indeed, depending on the criticality of the data, its update frequency, as well as the need to be resilient to various network conditions, the choice of the caching pattern (cache first, network first, stale-while-revalidate, …) is often a hot topic in the PWA world.

As the migration of the APK application to PWA has not been completed, deployment is still necessary in other BU (South Africa, France, Italy and Poland), which may create new technical issues to solve.

But the good news is that PWA for mobile use has become the norm for our products in the domain. StockItEasy, the second digital product in charge of in-store inventory management, followed the Pick&Go example by being implemented directly in PWA. The 3 new mobile applications have been successfully deployed in our Italian Pilot store. The deployability of the latter has never been easier for development teams and access to the application by users has been disconcertingly easy to which they are not used (Scan QR Code and Enjoy your App)

In addition, PWA entered our global Tech Radar as a technology that can be adopted by the entire ADEO group.

That is the end of our article. We hope you enjoyed it.

Let’s give big kudos to all the authors of this article: Thomas Gobert , Emmanuel Demey and Peter Chan

We’ll be very happy to discuss this topic with you. Join us on LinkedIn: Thomas Gobert, Youssef Boussaboun & Richard Buttin.

And, who knows, maybe you could join our amazing team? Here are some jobs listing from ADEO services.