CyberGuard

Helping Users to Help Themselves to Cyber Security

A protected, mobile, account manager that enables

Directory Structure

• lib/
  • const/ - Compile-time settings for application (configuration)
  • domain/ - Application domain code (essentially, business logic)
    • data/ - Data layer - generally intended for use by services layer - might request data from REST APIs, or local filesystem, for example.
    • services/ - Classes that uniformly expose specialized features.
    • struct/ - Classes that represent individual models (entities) within the system.
  • interface/ - All user-interface related code.
    • components/ - Non-application specific custom components (widgets, generalized such that they may be copied between applications).
    • partials/ - Application-specific 'parts' that may be re-used across the app for greater consistency (widgets that achieve some application-specific goal or interact with application-specific data).
    • screens/ - Widgets that implement an entire screen that will be pushed onto the navigation stack (and may render nested widgets). For screens with lots of custom components, a sub-directory for that screen might be used instead.
    • utility/ - Static classes, that might be registered in the locator, that are likely to be called for UI rendering purposes.
  • app.dart - Root-level definition of the MaterialApp. Contains core application configuration.
  • locator.dart - Statically register root-level singletons to be accessed throughout the app.
  • main.dart - The main entry point of the application.

Files that have a lot of component classes, or a 'main' class and other supporting classes (such as in the case of 'screens' where there is a screen class and potentially lots of supporting widgets specifically only to that screen), may have the initial file and a 'supporting directory' of the secondary classes. e.g., the home.dart file containing the HomeScreen class, has a home/ directory containing supporting widgets for the HomeScreen class.

Naming Conventions

Where the name of the app, CyberGuard would appear, CG is used except in iOS native code where CGA is used as the two-letter identifier this would conflict with a native iOS namespace (specifically, CoreGraphics).

Ordinarily, classes wil be named based on their purpose, followed by their structure (if necessary to disambiguate a class). For example, the home screen would be named HomeScreen (where Screen denotes the purpose, and the location within the structure is not necessary as all screens are placed in the screens/ directory).

For app-specific widgets such as the MaterialApp (root-level application widget in Flutter, or widgets that replace the built-in widgets such as AppBar) - but also more generally just any widget implemented specifically for this application (i.e., those outside of components/), the CG prefix is used to disambiguate the widgets from their (potentially) built-in counterparts.