Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Convert to new editor

This section presents the Totara Mobile architecture.

Goals

The architecture is set up to designed to achieve the following goals:

  • To provide a responsive and user-centric experience that suits the latest mobile trends

  • Customisable and flexible use cases for Partners

  • Aligns with Totara business rules 

  • Easy to maintain software

  • Communicable between developers with different skills

    developers

Architecture breakdown

The main parts of the architecture are:

  • UI components:

      The

    The tangible UI elements, screens, controls, etc. These should have the ability to work in different contexts (e.g. course_list works in different screens and use cases).

  • User workflows: Workflows encoded on how the user interacts with the UI elements as well as background components. This includes the navigation routing using

    react navigation

    the React Navigation library.

  • Webservices: Services that allow external interaction with the Totara Mobile plugin. This is done using the Apollo Client.

  • Storage:

     Location where the app maintain

    The location where the data state of the app is maintained, and

    persists

    where persistent data

    . The persisting happens using AsyncStorage and one

    is stored. Data persistence uses AsyncStorage. One of the main libraries for Redux

    is 

    is redux-persist.

App code layout

The code for the mobile app will be organised in has the following way.file structure:

  • @totara/

    action

    actions: Redux actions for Redux Store.

  • @totara/auth:

    Authentication screens, flows and related utils. This code might be moved to /core shortly

    Contains the authentication screens, their tests, functions and utilities files.

  • @totara/components: These are the generic

    none specific

    UI elements that are used throughout the app (e.g. buttons, panels, etc.). These components are pure and stateless or have only a local state.

  • @totara/core:

    This folder contains

    Contains essential components and utils for the app authentication and other critical flows.

  • @totara/features:

    This is a particular feature of the app such as:
  • root (Javascript): The specific screen components that contains the feature. It is also at this level which appropriate container to show on particular device screens capability are included (e.g. small phone, extra large phone, tablets, etc.). This uses Javascript only instead of Typescript. 
  • API (Typescript): Where data centric and background code lives

    Features of the app eg current learning, find learning, profile notifications, and downloads. Each feature folder includes (at least) that feature's main containers:

    • api: Graphql queries and mutations.

    • tests: Unit tests for that specific feature.

    • e2e: Automated UI test scripts for that specific feature.

  • @totara/lib: Code for functions/helpers and non-styling constants that are used across different areas.

    In other words, this is the place where we put utilities and utils files

    This is the location for shareable functions and utils files.

  • @totara/locale: Module for internationalisation.

  • @totara/reducers: Redux reducers for Redux Store.

  • @totara/theme: Code theming and UI.

  • @totara/types: Types, schema, and domain model of the mobile app.

Note

@totara/lib can't depend on features. In addition, also one feature can't cannot directly depend on another feature. Make That makes the interface clear on a per-module basis. , e.g. lib is for function calls, features are for routing info , etcand so forth.

Mobile scope modules

Below you will find more information about some of the different parts is additional information regarding components of the app architecture. 

@totara/

...

actions

This is where you will find big features of the app, with complete screens. You can see how the app is broken into logical features. In line with react convention the containers in this package are: 

...

module presents all the actions that the redux store can offer.

  • inputs: Actions params, e.g. session and resources payloads

  • outputs: store mutations in which the data is changed according to the actions 

@totara/auth

This module contains all the components for authentication set-up. Native, webview, and browser authentication screens are located here.

  • inputs: Authentication params (URLs, auth function, etc.) and auth credentials

  • outputs: Authentication screens and related utilities and functions

@totara/components

This is where you can find module contains reusable react components that are not feature-specific, these . These are components that can be used across all features.

  • Inputs: React props containing; data, style and methods

  • Outputs: React elements, components via HOC

Warning

Please note the following restrictions: 

  • Must not directly get data from the API

    ,

    . The caller must use the API and pass via props.

  • Must not directly access the theme

    ,

    . The caller must use either theme or local style and pass the style to the component.

  • Must use methods to manipulate data on the caller.

@totara/

...

features

This is where you can access components, library and reusable styles.

  • Inputs: Theme configuration and provider
  • Outputs: React components/elements that are themed, style parameters

@totara/lib 

Here you can find module contains major features of the app, with complete screens. Note how the app is broken into logical features.

In line with react convention, the containers in this package are:

  • Inputs: Navigation params and API access through GraphQL queries and subscriptions, as well as Totara dependency

  • Outputs: Navigation params to other features, user interaction and GraphQL mutations

@totara/lib 

This module contains reusable code for data manipulation, calculation etc, etc. that can be used app-wide. 

Note

Avoid making this This is not a dumping ground of code.  Reconsider if this package should exist, it's a simple mechanism to just import a module but can be prone to abuse. These are helpful files that are used by other layers of the application.

  • Inputs: Function params

  • Outputs: Return values/objects

Warning

Please consider the following restrictions:

  • Must be able to run different JS

    runtime, react native or node

    runtimes e.g. React Native, Node, etc.

  • Must only depend on restricted libraries that are very stable like moment

    , lodash, etc.

    e.g. Lodash

@totara/locale

This module introduces components and procedures for locale and internationalisation.

  • inputs: Locale params, locations and language settings

  • outputs: Reusable high order component to initiate the app locale

@totara/reducers

This module presents all the reducers that the redux store can offer

  • inputs: Redux store state and actions types and payloads

  • outputs: reduction of the store according to the actions

@totara/theme

This is where you can access components, libraries and reusable styles.

  • Inputs: Theme configuration and provider

  • Outputs: React components/elements that are themed, style parameters

@totara/types

This is the location for module contains the data structure of the app, constants, etc.

  • Inputs: None

  • Outputs: Types, objects, etc.

Warning

Please note the following restriction:

  • Must only depend on language features of

    Type/Java script only

    Typescript/Javascript

Dependency graph

This is an overview of the main modules found in the mobile code and the notable third party libraries.


...