Compass App: Activities screen, error handling and logs

[miquelbeltran]

This PR introduces the Activities screen, handling of errors in view models and commands, and logs using the dart logging package.

Activities

• The screen loads a list of activities, split in daytime and evening activities, and the user can select them.
• Server adds the endpoint /destination/<id>/activitity which was missing before.

Screencast provided:

Screencast.from.2024-07-29.16-29-02.webm

Error handling

UI Error handling:

In the screencast you can see a SnackBar appearing, since the "Confirm" button is not yet implemented.
The saveActivities Command returns an error Result.error(), then the error state is exposed by the Command and consumed by the listener in the ActivityScreen, which displays a SnackBar and consumes the state.

Functionality is similar to the one found in UI events - Consuming events can trigger state updates from the Android architecture guide, as the command state is "consumed" and cleared.

The Snackbar also includes an action to "try again". Tapping on it calls to the failed Command execute() so users can run the action again.

For example, here the saveActivities command failed, so error is true. Then we call to clearResult() to remove the failed status, and show a SnackBar, with the SnackBarAction that runs saveActivities again when tapped.

    if (widget.viewModel.saveActivities.error) {
      widget.viewModel.saveActivities.clearResult();
      ScaffoldMessenger.of(context).showSnackBar(
        SnackBar(
          content: const Text('Error while saving activities'),
          action: SnackBarAction(
            label: "Try again",
            onPressed: widget.viewModel.saveActivities.execute,
          ),
        ),
      );
    }

Since commands expose running, error and completed, it is easy to implement loading and error indicator widgets:

Screencast.from.2024-07-29.16-55-42.webm

As side node, we can easily simulate that state by adding these lines in any of the repository implementations:

    await Future.delayed(Durations.extralong1);
    return Result.error(Exception('ERROR!'));

In-code error handling:

The project introduces the logging package.

In the entry point main_development.dart the log level is configured. Then in code, a Logger is creaded in each View Model with the name of the class. Then the log calls are used depending on the Result response, some finer traces are also added.

By default, they are printed to the IDE debug console, for example:

[SearchFormViewModel] Continents (7) loaded
[SearchFormViewModel] ItineraryConfig loaded
[SearchFormViewModel] Selected continent: Asia
[SearchFormViewModel] Selected date range: 2024-07-30 00:00:00.000 - 2024-08-08 00:00:00.000
[SearchFormViewModel] Set guests number: 1
[SearchFormViewModel] ItineraryConfig saved

Other changes

• The json files containing destinations and activities are moved into the app/assets/ folders, and the server is querying those files instead of their own copy. This is done to avoid file duplication but we can make a copy of those assets files for the server if we decide to.

TODO Next

• I will implement the "book a trip" screen which would complete the main application flow, which should introduce a more complex "component/use case" outside a view model.

Pre-launch Checklist

• I read the Flutter Style Guide recently, and have followed its advice.
• I signed the CLA.
• I read the Contributors Guide.
• I updated/added relevant documentation (doc comments with ///).
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-devrel channel on Discord.

[ericwindmill]

nit / nonblocking comment:
I've recently learned about UnmodifiableListView, and I think this is the perfect place to use it :)

  /// List of daytime [Activity] per destination.
  UnmodifiableListView<Activity> get daytimeActivities => UnmodifiableListView(_daytimeActivities);

[miquelbeltran]

I will give it a try!

[ericwindmill]

One higher level consideration for the future: Should String's that are displayed in UI be put in a class somewhere as constants?

All my comments are nits, and otherwise it looks good to me.

[miquelbeltran]

One higher level consideration for the future: Should String's that are displayed in UI be put in a class somewhere as constants?

All my comments are nits, and otherwise it looks good to me.

Agreed, I will do that for the next PR

[miquelbeltran]

I have created a class Dimens in ui.core.theme.

This is a sealed class that has two implementations, one for mobile and one for desktop.

The method Dimens.of(context) allows code access either of the two depending on the screen size using MediaQuery.sizeOf(context).

These dimensions are now used to define the common vertical and horizontal spacing of the app between UI components, but also to screen borders, so the desktop application has a larger margin around it:

[miquelbeltran]

One higher level consideration for the future: Should String's that are displayed in UI be put in a class somewhere as constants?

I have created an AppLocalization class under ui/core/localization/ which works with a LocalizationsDelegate. It implements a hardcoded map of strings similar to what we can find in the Flutter docs, just that this is only in English.

Maybe I missed a String or two, but works as a base for future localizations if we want to ;)

[ericwindmill]

LGTM, feel free to merge at your leisure!