Documentation

[IvanToplak]

One Line Summary

Updating documentation.

Issue(s) Addressed

Referencing #74

Steps to Reproduce/Test

N/A

Checklist

N/A

• Functionally tested
• Unit tests created / updated
• Backend dependencies deployed (if needed)

[julianfalcionelli]

Thanks for working on this, can we add this for the Build Types & Flavors?

Build Types & Flavors:

We defined two different Build types:
- Debug: The code is not obfuscated and it also does not remove unused resources. Used during development as the building process is faster.
- Release: The apk is signed using the debug keystore, since the final signature is done in our Continuous Integration environments (Github Actions, Bitrise, etc ...). The code is obfuscated and the resources optimized to obtain a lighter apk.

To configure the rest of the environment variables, such as which API environment to use, which Firebase configuration and others, we define 2 Product Flavors:
- Dev: Used during the development process as it points to the development/test servers. It also adds a suffix to our package name so we can have the dev and prod app installed at the same time, and add the suffix “Dev" to the name to identify it. In order to have the same application installed (which would technically be different when changing the appId), it is also important to define a unique File Provider for each environment.
- Prod: Here we use the productive environments. To avoid tracking development errors, analytics that are not produced by our end users, we must avoid using this environment for testing and only use it when we are sure that it already works well in the dev environment. 


Therefore the possible variants for now are: devDebug, devRelease, prodDebug, prodRelease.

The ideal is to have a Flavor for each API environment to use, that is, if our api has a dev, staging and prod environment, we would have to add the flavor of staging.

Finally, after testing our environments in Debug mode, it is important to test them in Release mode, since it may be necessary to add some rule in our proguard to prevent certain classes that are serialized from being obfuscated.

[julianfalcionelli]

Also we can add this for the CI & CD:

CI & CD:

Below we list the locations of the configuration files of the different Continuous Integration services that we use:

- GitHub Actions: The Workflows configuration can be found in .github/workflows.
- Bitrise: We attach the configuration file in the root directory (bitrise.yml), just to have a reference, since it is not necessary that it be in the repository, since it is automatically managed by Bitrise.
- Travis: The configuration file is located in the root directory (.travis.yml).
- Circle CI: The configuration file is in the directory .circleci (config.yml).

Important: Not all Continuous Integration environments are configured in the same way.

The Rocket team has a preference for Bitrise, Github Actions and Circle CI according to the project requirements.

[julianfalcionelli]

We can add some brief of the Google Services that we are using:

• Google services: We use several of the most common Firebase services, such as crash reports, analytics, push notifications - we have several classes that allow us to customize the different channels and the behavior of notifications easily, Google Maps - We add some classes that allow us to quickly add points, draw routes, get directions and more.

[julianfalcionelli]

We can also talk a bit about our architecture, right @brimanning ? Something like this:

Architecture:
We like to be at the forefront and at the same time generate solid products capable of scaling and adapting to changes quickly.

For that we use a series of design patterns and recommendations from the Google team that we consider key when developing a mobile app.
We use several of the Jetpack Compose libraries that allow us to make the most of the capabilities of the Android SDK.

At the architecture level we use MVVM with a series of Design Patterns that we list below:
- Repository Pattern
- Dependency Injection
- Dependency Inversion
This allows us to have a decoupled code, easy to mock up and clean.

[brimanning]

🎉

I think this is looking good! I like Julian's recommendations as well, whether they're added as part of this PR or another.

[IvanToplak]

I'll add Julian's recommendations as part of this PR.

[julianfalcionelli]

Great, thanks @IvanToplak!