Skip to end of metadata
  • Created by Former user, last modified by Former user on Aug 09, 2021
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

This section presents the Totara Mobile architecture.

Goals

The architecture is set up 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 different skills developers

Architecture breakdown

The main parts of the architecture are:

  • UI components:  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 library
  • Webservices: Services that allow external interaction with Totara Mobile plugin. This is done using Apollo Client
  • Storage: Location where the app maintain the data state of the app and persists data. The persisting happens using AsyncStorage and one of the main libraries for Redux is redux-persist

App code layout

The mobile app will be organised in the following way.

  • @totara/action: Redux actions
  • @totara/auth: Authentication screens, flows and related utils. This code might be moved to /core shortly
  • @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 local state
  • @totara/core: This folder 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
  • @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
  • @totara/reducers: Redux reducers
  • @totara/theme: Code theming and UI
  • @totara/types: Types, schema, and domain model of the mobile app

@totara/lib can't depend on features, also one feature can't directly depend on another feature. Make the interface clear on a per module basis. e.g. lib is function calls, features are routing info, etc.

Mobile scope modules

Below you will find more information about some of the different parts of the app architecture. 

@totara/features

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: 

  • 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/components

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

  • Inputs: React props containing; data, style and methods
  • Outputs: React elements, components via HOC

Please note the following restrictions: 

  • Must not directly get data from API, caller must use the API and pass via props
  • Must not directly access theme, caller must use either theme or local style and pass the style to component
  • Must use methods to manipulate data on the caller

@totara/theme

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 reusable code for data manipulation, calculation, etc. that can be used app wide. 

Avoid making this 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. 

  • Inputs: Function params
  • Outputs: Return values/objects

Please consider the following restrictions:

  • Must be able to run different JS runtime, react native or node, etc.
  • Must only depend on restricted libraries that are very stable like moment, lodash, etc.

@totara/types

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

  • Inputs: None
  • Outputs: Types, objects, etc.

Please note the following restriction:

  • Must only depend on language features of Type/Java script only
  • No labels