Skip to content

Architecture

Jump to bottom
Lex Whalen edited this page Oct 17, 2022 · 6 revisions

Following: https://capstone.cse.sc.edu/milestone/architecture/#lectures

  • List all the languages / frameworks / APIs.
  • Explain how the above functions together.
  • List package / build managers.
  • List what each person will work on.
  • Embed images from Design.
  • Wiki page easy to read?

Webapp:

  • Deployment information.
  • VMs?
  • SPA?
  • URLs?
  • REST API documentation?
  • Views of app? Embed images.
  • Database schema?
  • Common queries?

Android app:

  • Release?
  • VMs?
  • Models? (Note how state will be maintained here, ie how will you load the models)
  • Maintain state?
  • DB backend?
  • Common queries?
  • Views of app?
  • Activities and Fragments? Corresponded views? Model Classes?

Languages used

Web:

  • Python (Django):
    • Python’s Django framework is used for the back end of the application. In particular, the Django REST API is used. See Frameworks used for more information.
  • JavaScript
    • JavaScript and its libraries are used for the Front End of the application.
  • HTML
    • HTML is written to generate pages. This includes divisions, headers, paragraphs, or other document elements.
  • CSS:
    • CSS is used to style the pages. We will be using the Bootstrap library to style pages.
  • How they tie together:
    • Django is used to serve data from the web backend server. The web frontend, written in JavaScript (primarily React library), makes requests to the backend for data. The web front end has all of the page organization done via HTML elements, which are styled via Bootstrap.

Mobile:

  • Kotlin:
    • Kotlin is the promoted language for Android Development. All of the development in our Android application is to be done via Android.
  • XML:
    • XML is the language used to style Android pages. It is similar to other languages like HTML.
  • How they tie together:
    • Kotlin provides the data for XML to style, similar to how Django provides the data for Bootstrap to style.

Frameworks used

Web:

  • Django
    • Django is used as the backend of the web application, and used to serve data to any API requests. Thus Django is not only used as the backend for the web app, but also as the server of any data that clients request.
  • React:
    • React components make up the entirety of the frontend web application. Components do everything from making simple forms, such as for the Login and Registration pages, the graphics displaying a user’s data, the community pages, and the homepage.
  • Redux:
  • Django-Rest-Knox:
  • Chart.js
  • Axios:
    • Framework is the link from the frontend to the backend. It fires off requests in response to user actions. For example, a user logging into their account will enter information in to the Login page; Axios takes that data and fires off the POST request check for a valid user, pull the data from the database, and load it into the webpage. Axios framework simplifies requests by creating a promise chain that either retrieves the requested data or returns an error message.
  • Bootstrap:
  • How it ties together:
    • The server serves data via the backend, which is written using the Django framework. Requests are made to Django’s REST API, which will then serve the data in JSON or similar formats. The library used to make requests on the web version is Axios, a simple library that allows easy creation of HTTP requests. The front end is written in the React framework. React allows for reuseable components, whereas Redux allows for the state of these components (attributes associated with the HTML components, for example the name data from a name field in a form) to be more easily manipulated. Django-Rest-Knox provides a way to authenticate requests for data; for instance only logged-in users can make requests for data, and to prove logging in we use tokens provided by Django-Rest-Knox framework. Chart.js is used to style the front end’s graphs.

Mobile:

Package / Build manager

Web:

  • npm
    • Manages packages, dependencies, etc. for the web application.
      • ie:
        • React
        • Redux and Redux-adjacent libraries
        • Axios
        • Knox
  • webpack
    • Builds the dependency graph for the web application.
  • babel
    • The transcompiler to build backwards compatible JS
  • pip
    • Package manager for the web backend; used to download and manage Django, DjangoRESTFramework, and other Django adjacent packages necessary for the web application’s backend.

Mobile:

  • gradle
    • This is the basic kotlin package that is used download and manage files in android. This is necessary for mobile front and backend. This will also be used to configure the deployment of the mobile app.

List what each person will work on:

Deployment:

Web:

  • Heroku
    • “How will you deploy, which hosting provider(s)? Automation? Scripts?”
      • To deploy our app, we will use Heroku as the hosting provider. To supplement this, mySQL will be used as the database. A benefit of Heroku is that we can link our GitHub with Heroku for direct deployment. We will need to make an account on Heroku to allow for this direct deployment.
      • For automation, we plan to make use of GitHub actions, which will automatically test and deploy our app every time we make a push. In order for this to work, we will need to use GitHub Secrets in order to share the credentials between Heroku and GitHub.
      • GitHub actions will let us automate deployment (see [here](https://shashanksrivastava.medium.com/use-github-actions-to-automatically-deploy-your-applications-to-heroku-566ff0637ffb )). We would create a GitHub workflow and register it with Heroku to allow for our changes put on GitHub to be populated into the Heroku hosted site.
    • “Are you using VM’s or Containers?”
      • This application will not be using VMs or Containers.
    • “Is it SPA or traditional?”
      • SPA
    • Front End Views & Respective React Components.
    • Database schema:
      • users Table:
        • Columns (model fields for Django):
          • first_name: Text Field. First name of the user.
          • last_name: Text Field. Last name of the user.
          • username: Text Field. Username of the user.
          • password: Django Password field. Django already has a User model; we will reuse much of the functionality from this, including the password.
          • gender: Select Text Field ( Django allows selectable model fields, ie : Male, Female, Other, etc. See [here](https://docs.djangoproject.com/en/4.1/ref/models/fields/) ). The user’s gender.
          • organization: Foreign Key to Organizations Table, links a user to their organization. (At the moment only allow for a user to be a part of one organization)
          • date_of_birth: Date field ( see [here](https://docs.djangoproject.com/en/4.1/ref/models/fields/) ). The user’s birthday.
          • id: Django id field. This is the default ID field associated with all Django models.
      • data Table: (Only acceleration for now):
        • id: Django id field. This is the default ID field associated with all Django models.
        • data_type: Text field. The type of data being collected. As at the moment we are only considering acceleration data, this value will only be acceleration. In the future, we may have temperature or other recordable data names.
        • author: Foreign key to user table. Is the ID of the user that uploaded the data.
        • collection_notes: Text Field. Any notes about the collection of the data that the author would like to share, for instance, licensing or uses.
        • file_path: Text field. A string representing the path of the file. The entries in Data Table represent wrappers of actual CSV files containing recorded data. The data is obtained from the smart watches and uploaded to the server. The path column is the way to actually access the file.
        • pub_date: Django DateTimeField. Defaults to current time. Represents the time of upload of a file.
        • rating: Django integer choice field (see [here](https://docs.djangoproject.com/en/4.1/ref/models/fields/) ). Ranges anywhere from 0 to 5. 5 is best rating, 1 is worst, and zero is unrated.
      • model Table:
        • pub_date: Django DateTimeField. Defaults to current time. Represents the time of upload of a model, where in this case “model” means a machine learning model, NOT a Django model..
        • id: Django id field. This is the default ID field associated with all Django models.
        • rating: Django integer choice field (see [here](https://docs.djangoproject.com/en/4.1/ref/models/fields/) ). Ranges anywhere from 0 to 5. 5 is best rating, 1 is worst, and zero is unrated.
        • file_path: Text field. A string representing the path of the file. At the moment Dr. Valafar’s group are still deciding how best to store the ML models; one possible method is to simply store the weights and biases as a CSV file. Regardless, file_path stores the path to the model’s file in the file system of the server.
        • notes: Text field. Any notes regarding the model itself. These could be about the way the models were generated, what data sets were used, licensing, or anything else the author would like to include.
        • author: Foreign key to user table. Is the ID of the user that uploaded the model.
      • organization Table:
        • id: Django id field. This is the default ID field associated with all Django models.
        • author: Foreign key to user table. Is the ID of the user that created the organization. Right now we only allow administrators to create the organizations.
        • about: Text field. Contains information about the organization.
      • post Table:
        • id: Django id field. This is the default ID field associated with all Django models.
        • pub_date: Django DateTimeField. Defaults to current time. Represents the time of creation of a post.
        • rating: Django integer choice field (see [here](https://docs.djangoproject.com/en/4.1/ref/models/fields/) ). Post’s like count. Only positive like counts. 0 represents no likes (initialized state).
        • text: Text field. Text of the post. Posts are to only be text based for now, and can include URLs to other posts or anywhere else.
        • parent: Foreign key to post. Null = true, blank = True. This is a trick to allow posts to be associated with other posts, which also allows posts to be considered “comments” when this parent field is not null. When not null, the parent field contains the id of the parent post.
        • author: Foreign key to user table. Is the ID of the user that uploaded the data.
    • Common Requests & Their respective API endpoints
      • users table:
        • GET: Returns user data. Used in instances where user tries to log in or wants to see their account information.
          • [DOMAIN]/api/auth/users/{id}, where id is the id of the user to return information of.
          • Keys to pass: id, the id of the user. token, a token to authenticate the user making the request, ie the user is signed in.
        • GET: Login. Login a user.
          • [DOMAIN]/api/auth/
          • Keys to pass: username, password, the username and password of the user to login.
        • POST: User registers a new account, ie POST would be used for creation of new account.
          • [DOMAIN]/api/auth/
          • Keys to pass: username, password. These are the username and password of the user. token, a token to authenticate the user making the request, ie the user is signed in. May wish to add more parameters to pass into the HTTP request payload, but we start with this for flexibility.
        • PUT: User wants to change account information, ie PUT would be used to change current attributes of user model.
          • [DOMAIN]/api/auth/users/{id}, where {id} is the id of the user object.
          • Keys to pass: id, the id of the user to update.token, a token to authenticate the user making the request, ie the user is signed in.
        • DELETE: User wants to delete their account, ie DELETE deletes a user instance.
          • [DOMAIN]/api/auth/users/{id}
          • Keys to pass: id, the id of the user to update. token, a token to authenticate the user making the request, ie the user is signed in.
      • data table:
        • GET: Data files must be grabbed to be displayed to users, for example on the home screen, ie, GET returns a data model. This would be done by passing the data model’s id field into the REST API endpoint.
          • [DOMAIN]/api/data/{id}, where {id} is the id of the data object.
          • Keys to pass: id, the id of the user. token, an auth token to show the user is registered and logged in.
        • POST: User uploads a new data file, ie, POST creates a new data object.
          • [DOMAIN]/api/data
          • Keys to pass: token, an auth token to show the user is registered and logged in. file_name, the string representing the file’s name.
        • PUT: User wants to make edits to a previously uploaded data file, ie, PUT edits current attributes of a data object.
          • [DOMAIN]/api/data/{id}, where {id} is the id of the data object
          • Keys to pass: id, the id of the data object. token, an auth token to show the user is registered and logged in.
        • DELETE: User wants to remove their data from the server, ie, DELETE deletes a data object.
          • [DOMAIN]/api/data/{id}, where {id} is the id of the data object.
          • Keys to pass: id, the id of the data object. token, an auth token to show the user is registered and logged in.
      • model table:
        • GET: Returns the data for a specific ML model. This can be done via the id field of the model.
          • [DOMAIN]/api/model/{id}, where {id} is the id of the model object
          • Keys to pass: id, the id of the model object. token, an auth token to show the user is registered and logged in.
        • POST: Upload a new AI model for future use, ie, POST creates a new model object.
          • [DOMAIN]/api/models
          • Keys to pass: token, an auth token to show the user is registered and logged in. file_name, the name of the file.
        • PUT: Update a previous model, possibly with new weights or description, ie, PUT updates the current values of a model object.
          • [DOMAIN]/api/models/{id}, where {id} is the id of the object.
          • Keys to pass: id, the id of the model object. token, an auth token to show the user is registered and logged in.
        • DELETE: Delete a previously created model object.
          • [DOMAIN]/api/models/{id}, where {id} is the id of the object.
          • Keys to pass: id, the id of the model object. token, an auth token to show the user is registered and logged in.
      • organization table:
        • GET: Return data for an organization to be displayed to users on their community page, ie, GET returns data for a specific organization. This can be done via the id attribute of the organization object.
          • [DOMAIN]/api/organizations/{id}, where {id} is the id of the object.
          • Keys to pass: id, the id of the organization object. token, an auth token to show the user is registered and logged in.
        • POST: New organization is created by an admin, ie, POST creates a new organization object.
          • [DOMAIN]/api/organizations/
          • Keys to pass: token, an auth token to show the user is registered and logged in. name, the name of the new organization. about , text describing the organization.
        • PUT: Organization wants to update previous information, such as their about-tag, ie, PUT updates the current attributes of an organization object.
          • [DOMAIN]/api/organizations/{id}, where {id} is the id of the object.
          • Keys to pass: id, the id of the organization object. token, an auth token to show the user is registered and logged in.
        • DELETE: Delete an organization. Only the author of the organization can delete it.
          • [DOMAIN]/api/organizations/{id}, where {id} is the id of the object.
          • Keys to pass: id, the id of the organization object. token, an auth token to show the user is registered and logged in.
      • post table:
        • GET: Grab a previous post entry, ie, GET returns the data of a post object. This can be done by passing in the id attribute of the POST object into the API request.
          • [DOMAIN]/api/post/{id}, where {id} is the id of the object.
          • Keys to pass: id, the id of the post object. token, an auth token to show the user is registered and logged in.
        • POST: Make a new post entry.
          • [DOMAIN]/api/post/
          • Keys to pass: token, an auth token to show the user is registered and logged in. body, the body text of the post. parent_post_id, a voluntary field representing the parent post (used to create comments on posts). parent_id, the id of the parent object that is being posted on (id, data or model). type, a string representing if this post is for a data object or a model object.
        • PUT: Update a previous post entry.
          • [DOMAIN]/api/post/{id}, where {id} is the id of the object.
          • Keys to pass: id, the id of the post object. token, an auth token to show the user is registered and logged in.
        • DELETE: Delete a previous post entry.
          • [DOMAIN]/api/post/{id}, where {id} is the id of the object.
          • Keys to pass: id, the id of the post object. token, an auth token to show the user is registered and logged in.
    • Expected common queries:
      • Note that all queries are to be handled using Django’s query system. We shall explain however how these the following common queries work in terms of mySQL, as that is what Django will be using. Thus this is “pseudo” mySQL, as we do not see any of what Django is doing directly.
      • Users:
        • Select user by id.
          • SELECT * FROM users WHERE id = [id]
        • Select user by organization.
          • SELECT * FROM users WHERE organization = [organization]
      • Data:
        • Get data by id.
          • SELECT * FROM data WHERE id = [id]
        • Get data by user.
          • SELECT * FROM data JOIN users ON data.author_id = [user_id]
        • Get data by datatype:
          • SELECT * FROM data WHERE data_type = [data_type]
        • Get data by rating:
          • SELECT * FROM data WHERE rating = [rating]
      • Model:
        • Get model by id.
          • SELECT * FROM model WHERE id = [id]
        • Get model by user.
          • SELECT * FROM model JOIN users ON data.author_id = [user_id]
      • Organization:
        • Get organization by id.
          • SELECT * FROM organization WHERE id = [id]
        • Get organization by name.
          • SELECT * FROM organization WHERE name = [name]
      • Post:
        • Get post by id.
          • SELECT * FROM post WHERE id = [id]
        • Get post by user.
          • SELECT * FROM post JOIN users ON post.author_id = [user_id]

Mobile

  • Release:
    • We will be using google play to deploy the app. Because we are using android studio to build the application, we can automate most of the process using gradle to get it deployable on the google play store. There are 2 main steps in deploying the app. Preparing the app for release and releasing it to users.
    • The first step of preparing the app for release is by configuring the app.
      • As stated before, because we are using android studio to build the application, we can use the gradle to automate some of this process. We can select the release build type for the published version of the app.
    • Second step is by building and signing a release version of our application.
      • Once again, we will be using the gradle build files with the release build type to do this
    • Once done, we would just need to follow the prompts given by the Google Play store to complete this process.
    • See [here](https://developer.android.com/studio/publish/preparing)
  • VM’s or Containers?
    • No VM’s or containers shall be used for this application.
  • Models for app
    • Many of the following classes (here synonymous with model) are very similar to those found in the Web version. This is because many classes in the Android version shall primarily be populated in the same fashion as that of the web version, using the Django REST API.
    • User
      • firstName: String. First name of the user.
      • lastName : String. Last name of the user.
      • username: String. Username of the user.
      • password: String. Password of the user.
      • gender: String. Gender of the user, will be selected from a predetermined list of genders.
      • organization: Organization object. The user will have a “has a” relation with the organization they belong to.
      • dateOfBirth: Date class. Using the Kotlin Date class, will be the user’s birthday. https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.js/-date/
      • id: UUID. The user’s unique id. Used to connect the user to their associated information and data. Comes from the built in UUID within Android. https://developer.android.com/reference/kotlin/java/util/UUID
    • Data
      • id: UUID. The data’s associated id. Comes from the built in UUID within Android. https://developer.android.com/reference/kotlin/java/util/UUID
      • dataType: String. The type of data that’s being collected. This value currently will only be acceleration , with possible future additions, such as temperature , or other recordable data types.
      • author: UUID. This is the UUID of the user that uploaded the Data.
      • collectionNotes: String. Any notes about the collection of the data that the author would like to share, for instance, licensing or uses.
      • filePath: String. A string representing the path of the file. The entries in the Data Table represent wrappers of of actual CSV files containing recorded data. The dat5a is obtained from the smart watches an uploaded to the server.
      • publishDate: Date class. defaults to the current time. Represents the time of upload of a file. https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.js/-date/
      • rating: Int. Number that rangers between 1 and 5. Rating of 1 is the worst, 5 is the best.
    • Post
      • id: UUID. Unique id that connects a post to its data. https://developer.android.com/reference/kotlin/java/util/UUID
      • publishDate: Date class. defaults to the current time. Represents the time of creation of a post. https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.js/-date/
      • rating: Int. Number that rangers between 1 and 5. Rating of 1 is the worst, 5 is the best.
      • text: String. text of the post. Posts are to only be text based for now, and can include URLs to other posts or anywhere else.
      • parent: UUID. The ID of any parent post that the post may be a response to, ie. the current post is a comment to another post. If parent is null, then the post is the original post.
      • author: UUID. The user’s UUID who created the post.
    • Organization
      • id: UUID. Unique id that connects the organization to its data. https://developer.android.com/reference/kotlin/java/util/UUID
      • author: UUID. The user’s UUID that created the organization. Only administrators can currently create organizations.
      • about: String. Contains information about the organization.
    • Model
      • publishDate: Date class. Defaults to the current time. represents the time of the upload of a model, the model being the machine learning model. https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.js/-date/
      • id: UUID. The unique id that pertains to the model itself. https://developer.android.com/reference/kotlin/java/util/UUID
      • rating: Int. Number that rangers between 1 and 5. Rating of 1 is the worst, 5 is the best.
      • filePath: String. A string representing the path of the file. Stores the path to the model’s file in the file system on the user’s mobile device.
      • notes: String. Any notes regarding the model itself. This could be anything about the way the models were generated, what data sets were used, licensing, or anything else the author wants to include.
  • “How will it maintain state?”
    • The application will maintain state using the main memory of the phone itself, SQLite from the phone, and will also be able to save and restore data from the web backend using the Django REST API. The main memory of the phone will be used to store any operations that do not require storage after shutdown, such as what page the user was last on. SQLite is used to store basic login information of the user so that they can log in even without internet connection. SQLite will also store the metadata of the downloaded data sets (such as those downloaded via bluetooth on the phone). At the moment, this is the only information that we will be storing directly with SQLite; in the future we would like to be able to cache information downloaded by the backend server so that there is a level of functionality in the offline version of the app. Finally, the app will be able to refresh with data from the server, and send data to the server (such as watch files downloaded via bluetooth).
  • “How will it connect to DB?”
    • The mobile app will connect to the backend server using the Django Rest Framework and HTTP requests.
    • Please look at the API requests for the Web section to see how data can be accessed via HTTP requests.
    • Please see the Database schema for the Web section to see how data is structured.
  • “Common Requests?”
    • Each class will have the standard GET, POST, PUT, and DELETE queries. These shall operate in the exact way as the web API’s respective HTTP requests act; ie GET returns the data for some class, POST will create an instance of some class, PUT will update an existing instance of some class, and DELETE will delete an instance of the object. As these HTTP requests will be done on the Django REST API, they are the same as those in the web version.
  • “Common Queries?”
    • These queries will operate in the same exact way as those found in the Web app section.
  • Views of app?
    • [Loading](https://github.com/SCCapstone/Delta/wiki/Design#loading-screen):
      • This is the loading screen that will load every time the user opens the app. This is something that will last two seconds that will allow the app to load.
    • [Onboarding Tour:](https://github.com/SCCapstone/Delta/wiki/Design#onboarding-tour)
      • This is four screens that allows a first-time user to see a short glimpse of the capabilities of the app. There will be a click button that will allow the user to view the different screens.
    • [Registration](https://github.com/SCCapstone/Delta/wiki/Design#registration):
      • This is the first screen that a first time user will see. This screen will allow the user to enter all the necessary information to create an account that will be added to the database. This is also a simple layout. There is a link that will connect to the regular login screen.
    • [Organization Screen](https://github.com/SCCapstone/Delta/wiki/Design#organization-screen):
      • This screen appears after the user has clicked the “Create Account” button in Registration page to fully setup their account based on organizational settings. There is a link that a user can use to skip this screen if they are not part of an organization. All there is a text field that accepts a 6-digit code and will check with the server if an organization with that code exists.
    • [Login Screen](https://github.com/SCCapstone/Delta/wiki/Design#login-screen):
      • This is a basic login screen that just has fields to login. There is a sign in button that will take the user to the home screen if the username and password matches on in the database. An invalid username or password with result in an error message being displayed. There is also a link to take the user back to the registration screen.
    • [Home screen](https://github.com/SCCapstone/Delta/wiki/Design#home-screen):
      • The home screen is split into 2 major sections. There is a menu bar to toggle between the different activities/fragments for the different screens. One will be linked to the home screen, another will be linked to the cloud screen and the last one will be linked to the settings screen.
      • The second major section in the home screen is the notifications that appear. These show the user different activity metrics are expandable. The screen is going to be scrollable as well which will incorporate the RecycleView class. The notifications will have graphs that display the users data in a user friendly manner in chronological order. The graphs will use the MPAndroidChart API to display the graphs.
    • [Cloud Screen](https://github.com/SCCapstone/Delta/wiki/Design#base-cloud-screen):
    • [Upload Screen](https://github.com/SCCapstone/Delta/wiki/Design#upload-screen):
      • If the user clicks on the upload button on the Cloud screen, they will be taken to this screen. The user will be able to change the filename, if they are part of an organization select which organization it is a part of, permissions, and description of the file. All the fields will need to be filled and will be checked locally if they are. Once the submit button is clicked, the data is sent to the server and the user is redirected to the cloud screen with a confirmation message that the data was sent successfully.
    • [Settings Screen](https://github.com/SCCapstone/Delta/wiki/Design#settings):
      • This screen will have all the settings that the user is able to change. One of the options will be to change the Account Info. This will include, the username, email, password, sex, organization, age, and profile picture.
      • There will be a switch that enables finer features such as push notifications, Location Services, Sounds, and Ads.
      • The user will be able to access the pair watch screen pair the watch to the phone so the data can be transferred.
      • There will be other options such as help, support, and sign out button.
    • [Pair Watch Screen](https://github.com/SCCapstone/Delta/wiki/Design#pair-watch-screen):
      • This is the screen where the user will be able to select their watch to pair via bluetooth.
      • It will be similar to radio buttons that the user can click on to select the pairing.
      • There is a back button to go back to the settings page.
  • Activities and Fragments:
  • Classes:
    • Please see Models for App under Mobile for classes regarding models. The next classes are only related to the views / viewing of data.
    • HomeFragment: The user’s home screen.
    • SettingsFragment: Contains the list of settings that a user can change. The user can select a setting, if that setting is binary then it will be turned on or off. For more in depth settings, like pairing a watch, the user will be carried to another screen relating to the setting they’ve chosen.
    • CloudFragment: Screen for the user to view the cloud, download data that’s already in the cloud, or upload their own data to the cloud.
    • VPAdapter: Contains all of the ViewPager fragments (ie. Home and settings) and allows them to be displayed.
    • Dashboard: The main dashboard. Contains the base that will house the homepage, settings, and data for the user. The Dashboard is fragment, with a navigation bar at the bottom allowing for the user to switch between the different screens of the app.
    • PostAdapter: Adapter that will allow posts to be translated onto the screen in a scrollable list.
    • SplashFragment: Upon loading the app, displays the splash screen background for a set amount of time. If the onboarding has not been completed by the user (meaning they opened the app for the first time after downloading) they will be sent through the onboarding process. If there are updates for the user, then the user will be taken to the updates. Otherwise, they will be taken to their main dashboard.
    • WelcomeScreen: Greets users immediately after the boarding process to notify of any new updates.
Clone this wiki locally