Implementing offline mode in a fleet management app | How we do IT #1

00:00 → 00:02

Why would you even bother implementing offline mode in

00:02 → 00:04

your mobile application?

00:04 → 00:08

Well, there are cases in which offline functionalities do make a difference.

00:08 → 00:11

Let's take a closer look at one of them.

00:15 → 00:18

I'm Aleksandra, Senior Content Marketing Specialist at Merixstudio,

00:18 → 00:21

and this is how we do it.

00:21 → 00:24

In this series, we present you with specific design and development

00:24 → 00:28

challenges and explain how we deal with them at Merixstudio.

00:28 → 00:31

Every case discussed here is based on our own experience and

00:31 → 00:33

projects we've worked on so far.

00:33 → 00:37

This episode will focus on an example of a fleet management

00:37 → 00:39

software created for a US based company.

00:39 → 00:43

The application helps fleet managers organize all the claim

00:43 → 00:44

related information.

00:44 → 00:46

Drivers use it on a daily basis as well.

00:46 → 00:48

Before hitting the road,

00:48 → 00:51

they perform routine vehicle inspections by filling out the

00:51 → 00:52

forms within the application.

00:52 → 00:56

The key features are related to reporting an accident and

00:56 → 00:58

filling out the insurance form.

00:58 → 01:01

And that's where the main challenge arises.

01:01 → 01:05

The lack of network coverage is a common problem for drivers on the road.

01:05 → 01:08

That's why implementing a functional offline mode is key

01:08 → 01:11

for business operations in this very case.

01:11 → 01:13

What offline features are essential here?

01:13 → 01:18

How to implement them to ensure seamless app operation and high usability.

01:18 → 01:21

See how we do it at Merixstudio.

01:21 → 01:25

Let me quickly cover the main challenges related to the

01:25 → 01:27

implementation of the offline mode.

01:27 → 01:31

First of all, driver needs to log in to the application.

01:31 → 01:33

That's no big deal when the connection is good, right?

01:33 → 01:35

But when it's not, well,

01:35 → 01:38

just imagine a situation when the user needs to fill out the

01:38 → 01:42

form and finds out they've been logged out of the app.

01:42 → 01:44

We can't let that happen, can we?

01:44 → 01:47

Secondly, we need to find a perfect solution for data

01:47 → 01:49

synchronization.

01:49 → 01:52

Let me describe to you yet another driver's nightmare.

01:52 → 01:55

Imagine an accident happened in the middle of nowhere.

01:55 → 01:58

The driver fills out the insurance form,

01:58 → 02:01

answers all the questions, uploads pictures and so on.

02:01 → 02:06

The entire process takes over half an hour and that's a lot of time.

02:06 → 02:09

When the driver is about to send the information to the fleet manager,

02:09 → 02:13

their bad Internet connection crashes the application.

02:13 → 02:16

The entire form needs to be filled out again from scratch.

02:16 → 02:18

Frustrating, isn't it?

02:18 → 02:21

Let me go on with yet another challenge.

02:21 → 02:23

By now, you know that drivers not only describe the

02:23 → 02:26

situation, but also attach photos.

02:26 → 02:29

Uploading a large file may take ages.

02:29 → 02:33

However, compressing it is not always the best idea either.

02:33 → 02:35

When you need to prove some damage,

02:35 → 02:38

having a good quality photo at hand may be a deal breaker.

02:38 → 02:42

And lastly, we need to solve the location related issues.

02:42 → 02:43

When an accident happens,

02:43 → 02:47

we need to collect accurate data about its location.

02:47 → 02:50

Of course, this can be fixed later on,

02:50 → 02:53

but the more accurate data the driver sends at the scene of

02:53 → 02:56

the accident, the better for the insurance company.

02:56 → 03:00

Okay. So let's start addressing these challenges one by one.

03:00 → 03:03

Paweł, our senior mobile developer and engineering

03:03 → 03:06

manager, will help me explain all the technicalities.

03:06 → 03:10

So, Paweł, what can we do about the process of logging in?

03:11 → 03:12

We have a few options here.

03:12 → 03:16

The easiest one is to set a longer expiration time for an access token.

03:16 → 03:19

It basically means that the user will be logged in for a very long time.

03:19 → 03:21

But this solution won't do in all cases.

03:21 → 03:24

Certainly not in those where sensitive data is stored in the

03:24 → 03:28

application and we have to make the user authenticate each time.

03:28 → 03:31

For example via a PIN code or biometric data like face recognition.

03:31 → 03:35

In this case sensitive insurance data is stored in the application.

03:35 → 03:37

So we decide to protect it with a PIN code.

03:37 → 03:41

We decide on this solution to make sure it will work well on all devices.

03:43 → 03:46

Okay. And how about synchronization?

03:46 → 03:50

How to avoid failure in filling out and sending the insurance form?

03:50 → 03:53

In this case, we enable the user to access and fill out the form without

03:53 → 03:54

Internet connection.

03:54 → 03:58

All the data the user provides is stored locally on the device.

03:58 → 04:00

Then when the Internet connection is stable or more

04:00 → 04:03

preferable when the user is connected to the WiFi,

04:03 → 04:05

the data is synchronized and sent to the server.

04:05 → 04:08

We also introduce here some important features that improve

04:08 → 04:09

the app usability.

04:09 → 04:13

First of all, we let user decides whether the photos or videos attached will

04:13 → 04:14

be compressed or not.

04:14 → 04:17

Images can be saved as JPEG or JPEG two thousand files.

04:17 → 04:19

Following the MVP release,

04:19 → 04:21

we can simplify the structure of the data sent to the server

04:21 → 04:24

and get rid of sending large JSON files.

04:24 → 04:26

It will be useful when the app grows and the need for

04:26 → 04:28

gathering much more data is more burning.

04:28 → 04:30

For example, numerous GPS information.

04:30 → 04:34

Secondly, we can implement a solution that will convert speech to text.

04:34 → 04:36

This feature will save drivers a lot of time.

04:36 → 04:40

Certain transcription errors that may occur will not be a big problem.

04:40 → 04:42

The completed form is still being checked by the fleet

04:42 → 04:45

operator before it is sent to the insurance agency.

04:48 → 04:50

Let's move on to the last solution.

04:50 → 04:53

How are we going to solve the problem of sending the location

04:53 → 04:55

without the Internet access?

04:55 → 04:57

Here we also have different solutions to choose from.

04:57 → 05:01

Firstly, can decide on integration with a third party company that will

05:01 → 05:03

provide us with telemetry monitoring.

05:03 → 05:05

This is what we'll do in the project in question as we

05:05 → 05:08

believe this data will be the most accurate.

05:08 → 05:09

But we could do it in a simple way.

05:09 → 05:12

We could strike the GPS location and send it in the

05:12 → 05:13

case of an accident.

05:13 → 05:16

Another solution is related to data synchronization but

05:16 → 05:18

implemented in a different way that I've mentioned before.

05:18 → 05:21

In this case, the app would run-in the background and launch at

05:21 → 05:22

certain time, for example,

05:22 → 05:25

every hour and then sync your data and location.

05:25 → 05:28

In this case, when the Internet connection is low,

05:28 → 05:30

it's crucial to properly prepare the data structure to

05:30 → 05:32

keep it as light as possible.

05:32 → 05:33

Thank you, Pawel,

05:33 → 05:37

for making the introduction of the offline mode sound like a breeze.

05:37 → 05:40

Now you should be ready to make your mobile application work

05:40 → 05:42

both online and offline.

05:42 → 05:44

Thank you for joining us today,

05:44 → 05:47

and don't forget to check out the rest of our content devoted

05:47 → 05:49

to mobile app development.