DEV Community: benz93chung

Improving MySejahtera's Check-out Functionality

benz93chung — Fri, 03 Dec 2021 05:08:12 +0000


The MySejahtera App (picture courtesy of lowyat.net)

Update:
MySejahtera has introduced the "MySJ Trace" feature, which solves the very problem of manual check-outs that this article discusses about, written before said feature was introduced.

MySejahtera is a mobile application developed by the Malaysian Government that serves as a response to curb the COVID-19 pandemic through the facilitation of contact tracing, and vaccination arrangements in hopes to achieve the nation's herd immunity.

It has been essential for the everyday lives of Malaysians and the country's residents during such a time. For one to visit an establishment (restaurant, office, etc), one with the app must check-in upon entrance for as long as the personnel approves of the individual's risk level and vaccination status, and check-out upon exit.

The Issue Of The Check-out Feature


A family vacation was spoiled over something of MySejahtera they are not aware of.

However, it is no stranger to criticism. For one, the check-out feature has received a lot of flak for not being friendly enough for users to check themselves out of locations they're no longer present at.

Therefore, some users, myself included, have even "stayed" in malls or convenience stores for weeks! 😱
Fortunately as of the time of writing, there is no penalty that would be imposed for those who fail to check-out in due course.

As comical as the issue may sound, it has led to the dismay of a family whose mother missed her vacation just because she did not check-out for weeks.

This shines a bad light to the app in question. If the family didn't even think about checking for their mother such a thing, this means there is lack of emphasis for checking out of locations.

This feature needs some work, and in this article we will explore about the issue exactly and think aloud what can be done to make the feature friendlier, let alone more useful.


Local comedian Gajen Nad has succinctly described the issue

Shaking things up

For disclosure, UI/UX is something I am currently learning but not my forte at the moment. What I am about to suggest is based on what I know and what I feel is right. Any open and constructive feedback though is welcome! 😊

With that being said, let's explore the check-out feature and see what we can do differently!

Starting page

Original version


The start screen at the current state at the time of writing.

The starting page seems informative. The user's risk status and vaccination status are displayed at the front.

There is a tile that enables you to check-out your most recent check-in. That is useful, but if it's so important to check out all other check-ins, then we need something here that tells the user how urgent it is to do so.

🆕 Reworked version


The start screen, with a check-out reminder.

Therefore, we can have a reminder at this start screen, reminding user to check-out from locations.

Checking out

Original version


The fact that there is a reminder at the top on how to assess for outstanding check-ins is concerning.	You have to tap upon one of the tiles in the History page to enter the check-in details page in order to check-out.

The app currently provides an avenue for users to assess a history of check-ins, and check-out those they are no longer present at.

But the problem is, the UI as it stands makes this whole experience of checking-out an eyeballing exercise. There is lack of proper distinction between locations in terms of its check-in status (checked-in or checked-out) whatsoever, resulting in an inconvenient experience.

Also, the user has to crawl in to the detail page of a location/check-in history and hit the "Check-out" button one by one.

This flow can make use of some refinement.

🆕 Reworked version


A reworked history page.

What can be done differently here is to split the histories in different tabs, for "checked-in" and "checked-out".
Within the "checked-in" tab, users can check-out each of them on the spot, reducing the walkthrough of individual check-out.

We can also introduce a "Check-out all" button in this tab. Upon click, all check-ins will be checked out.


Checking out from history page.	Checking out all at history page.

Conclusion

Maybe there is a reason why the check-out feature at the time of writing is hard for users to use. To be fair, I would not want to dismiss the developers as lazy in coming up with this feature for at times, it can be the requirements that can lead up to such an experience.

But I believe there has to be a better way of doing it, and to think aloud and start a conversation can be a start for finding such a way.

Thanks for reading!
You can check out my mock-up of the app in the following repository:

benz93chung / pseudosejahtera

A clone of the MySejahtera app, meant to pump some Dart/Flutter muscles as well as exploring what could be done differently.

PseudoSejahtera

A clone of the MySejahtera app, meant to pump some Dart/Flutter muscles as well as exploring what could be done differently.

As seen in my dev.to article!

⚠️ Important ⚠️

This mock-up of an app is NOT developed by the Malaysian Government. It is STRICTLY for educational purposes and is not meant to be used in real world situations.

For such situations, you should download and use the MySejahtera app.

Setup

Before trying to run the app locally, run the `build_project.sh` script under the `scripts` folder. This will generate the mocks (for unit test) and retrieve the project dependencies.

View on GitHub

Case Study: Externally rebuilding StatefulWidget

benz93chung — Thu, 04 Nov 2021 09:48:35 +0000

If you have been developing apps on Flutter long enough, chances are you've been making use of a state management tool, like Provider, BLoC, MobX, or the like.

If so, there might be a chance you've stumbled upon a certain problem, whereby a StatefulWidget doesn't choose to update itself upon state change.

This is a pretty specific problem. So in this article, we will walk through the problem and its solution via examples.

If you just want to know the summary, feel free to scroll downwards to the Summary section.

Building the Counter App

Let's start off with the Hello World of Flutter app, the Counter App. For this, we will be using MobX as its state management tool.

counter_store.dart

import 'package:mobx/mobx.dart';

part 'counter_store.g.dart';

class CounterStore = _CounterStore with _$CounterStore;

abstract class _CounterStore with Store {
  @observable
  int sum = 0;

  @action
  void increment() {
    sum++;
  }
}

Whether you are familiar with MobX or not, just understand that we have a store that contains a data member of sum, and a method that adds said data member by 1.

my_home_page.dart

class MyHomePage extends StatelessWidget {
  final counterStore = CounterStore();

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text('Counter'),
      ),
      body: Center(
        child: Observer(
          builder: (_) => StatelessCounterBody(
            value: counterStore.sum,
            onPressedAddButton: counterStore.increment,
          ),
        ),
      ),
    );
  }
}

stateless_counter_body.dart

class StatelessCounterBody extends StatelessWidget {
  final int value;
  final GestureTapCallback onPressedAddButton;

  const StatelessCounterBody({
    Key? key,
    required this.value,
    required this.onPressedAddButton,
  }) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return Column(
      mainAxisAlignment: MainAxisAlignment.center,
      children: <Widget>[
        Text(
          'You have pushed the button this many times:',
        ),
        Text(
          '$value',
          style: Theme.of(context).textTheme.headline4,
        ),
        const Padding(padding: EdgeInsets.all(16.0)),
        FloatingActionButton(
          onPressed: onPressedAddButton,
          tooltip: 'Increment',
          child: Icon(Icons.add),
        ),
      ],
    );
  }
}

This Counter App here is done a bit differently. We've refactored the content as a StatelessWidget with the name of StatelessCounterBody.

From where this StatelessCounterBody is used (my_home_page.dart), once the onPressedAddButton callback is triggered, counterStore.increment() is called to set the store's value. Therefore the wrapping Observer widget will discard the current instance and rebuild a new instance of StatelessCounterBody, where the value of its value parameter is the new value of sum.

Sweet! Works well so far.

Going Reactive, Going Stateful

Now comes a thought, of making a StatefulWidget version of StatelessCounterBody, and we want to call it as StatefulCounterBody.

Why would we want to do that? That's because now we want to make this widget reactive than static.

And yes, setState shall be used for internal rebuilding upon state changes for this widget in mind, because we do not want it to be reliant on other external means to have its state mutated (for example, expecting a certain store of a certain state management tool as its parameter and mutations are done with it).

stateful_counter_body.dart

class StatefulCounterBody extends StatefulWidget {
  final int initialValue;
  final Function(int) onValueIncrement;

  const StatefulCounterBody({
    Key? key,
    required this.initialValue,
    required this.onValueIncrement,
  }) : super(key: key);

  @override
  _StatefulCounterBodyState createState() => _StatefulCounterBodyState();
}

class _StatefulCounterBodyState extends State<StatefulCounterBody> {
  late int _value;

  @override
  void initState() {
    super.initState();

    _value = widget.initialValue;
  }

  @override
  Widget build(BuildContext context) {
    return Column(
      mainAxisAlignment: MainAxisAlignment.center,
      children: <Widget>[
        Text(
          'You have pushed the button this many times:',
        ),
        Text(
          '$_value',
          style: Theme.of(context).textTheme.headline4,
        ),
        const Padding(padding: EdgeInsets.all(16.0)),
        FloatingActionButton(
          onPressed: () {
            setState(() {
              _value++;
              widget.onValueIncrement(_value);
            });
          },
          tooltip: 'Increment',
          child: Icon(Icons.add),
        ),
      ],
    );
  }
}

For the case of StatefulCounterBody, we want it to react to the value changes all in itself. From the outside, the initialValue is to be provided, as well as a callback called onValueIncrement, where in itself returns the updated value upon incrementing.

Changed My Mind

So now, we decided that we want to add another button at the home page, where upon click adds the sum by 5.

counter_store.dart

import 'package:mobx/mobx.dart';

part 'counter_store.g.dart';

class CounterStore = _CounterStore with _$CounterStore;

abstract class _CounterStore with Store {
  @observable
  int sum = 0;

  @action
  void increment() {
    sum++;
  }

  // Newly added!
  @action
  void incrementByFive() {
    sum += 5;
  }
}

Hence, adding incrementByFive() to the store.

Making Use Of That StatefulWidget

my_home_page.dart

class MyHomePage extends StatelessWidget {
  final counterStore = CounterStore();

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text('Counter'),
      ),
      body: Center(
        child: Observer(
          builder: (_) => StatefulCounterBody(
            initialValue: counterStore.sum,
            onValueIncrement: (value) {
              counterStore.sum = value;
            },
          ),
        ),
      ),
      floatingActionButton: FloatingActionButton(
        onPressed: counterStore.incrementByFive,
        tooltip: 'Add by 5',
        child: Icon(Icons.add),
      ),
    );
  }
}

Button added, StatefulCounterBody ready. Let's give it a go.

Nice! Now let's try the newly added button; bottom right.

Wait. Why isn't that working?!

The Fact about StatefulWidgets

Diagram by Flutter Clutter. Check out his article about StatelessWidget vs. StatefulWidget

Whenever a StatefulWidget is constructed, the State first gets created via createState(), then the StatefulWidget is built. As the state changes, while the StatefulWidget gets discarded and rebuilt, (internally via setState() or externally via Observer, BlocBuilder, etc.), the State remains.

For our case, as counterStore.incrementByFive() was called and the Observer tries to externally rebuild a new instance of StatefulCounterBody, the instance was rebuilt, but the State persisted.

That is because we are yet to add something that informs the StatefulWidget to look out for the differences between the old and the new instances that should affect the state.

Art Thou Updated?

@override
void didUpdateWidget(covariant StatefulCounterBody oldWidget) {
  super.didUpdateWidget(oldWidget);

  if (oldWidget.initialValue != widget.initialValue) {
    _value = widget.initialValue;
  }
}

Therefore, the lifecycle method we can make use of is didUpdateWidget().

If there's a difference between the previous instance and the new instance, then it should update the state with that of the new instance accordingly.

Brilliant! It now works! :D

Summary

If you have problems trying to externally rebuild a StatefulWidget with Observer, BlocBuilder or by however rebuilding is done in other state management tools, then the widget has to know how to be aware of updating its State accordingly if there's found to be differences between the old and the new instance by using the didUpdateWidget() lifecycle method.

DEV Community: benz93chung

Improving MySejahtera's Check-out Functionality

The Issue Of The Check-out Feature

Shaking things up

Starting page

Original version

🆕 Reworked version

Checking out

Original version

🆕 Reworked version

Conclusion

benz93chung / pseudosejahtera

A clone of the MySejahtera app, meant to pump some Dart/Flutter muscles as well as exploring what could be done differently.

PseudoSejahtera

A clone of the MySejahtera app, meant to pump some Dart/Flutter muscles as well as exploring what could be done differently.

As seen in my dev.to article!

⚠️ Important ⚠️

This mock-up of an app is NOT developed by the Malaysian Government. It is STRICTLY for educational purposes and is not meant to be used in real world situations.

For such situations, you should download and use the MySejahtera app.

Setup

Before trying to run the app locally, run the build_project.sh script under the scripts folder. This will generate the mocks (for unit test) and retrieve the project dependencies.

Case Study: Externally rebuilding StatefulWidget

Building the Counter App

Going Reactive, Going Stateful

Changed My Mind

Making Use Of That StatefulWidget

The Fact about StatefulWidgets

Art Thou Updated?

Summary

Before trying to run the app locally, run the `build_project.sh` script under the `scripts` folder. This will generate the mocks (for unit test) and retrieve the project dependencies.