Benoit Marty
2 years ago
18 changed files with 2216 additions and 30 deletions
@ -0,0 +1,202 @@
@@ -0,0 +1,202 @@
|
||||
# Developer on boarding |
||||
|
||||
<!--- TOC --> |
||||
|
||||
* [Introduction](#introduction) |
||||
* [Quick introduction to Matrix](#quick-introduction-to-matrix) |
||||
* [Matrix data](#matrix-data) |
||||
* [Room](#room) |
||||
* [Event](#event) |
||||
* [Sync](#sync) |
||||
* [The Android project](#the-android-project) |
||||
* [Application](#application) |
||||
* [Anvil](#anvil) |
||||
* [Node](#node) |
||||
* [Other frameworks](#other-frameworks) |
||||
* [Push](#push) |
||||
* [Dependencies management](#dependencies-management) |
||||
* [Test](#test) |
||||
* [Other points](#other-points) |
||||
* [Logging](#logging) |
||||
* [Rageshake](#rageshake) |
||||
* [Tips](#tips) |
||||
* [Happy coding!](#happy-coding) |
||||
|
||||
<!--- END --> |
||||
|
||||
## Introduction |
||||
|
||||
This doc is a quick introduction about the project and its architecture. |
||||
|
||||
It's aim is to help new developers to understand the overall project and where to start developing. |
||||
|
||||
Other useful documentation: |
||||
- all the docs in this folder! |
||||
- the [contributing doc](../CONTRIBUTING.md), that you should also read carefully. |
||||
|
||||
### Quick introduction to Matrix |
||||
|
||||
Matrix website: [matrix.org](https://matrix.org), [discover page](https://matrix.org/discover). |
||||
*Note*: Matrix.org is also hosting a homeserver ([.well-known file](https://matrix.org/.well-known/matrix/client)). |
||||
The reference homeserver (this is how Matrix servers are called) implementation is [Synapse](https://github.com/matrix-org/synapse/). But other implementations exist. The Matrix specification is here to ensure that any Matrix client, such as Element Android and its SDK can talk to any Matrix server. |
||||
|
||||
Have a quick look to the client-server API documentation: [Client-server documentation](https://spec.matrix.org/v1.3/client-server-api/). Other network API exist, the list is here: (https://spec.matrix.org/latest/) |
||||
|
||||
Matrix is an open source protocol. Change are possible and are tracked using [this GitHub repository](https://github.com/matrix-org/matrix-doc/). Changes to the protocol are called MSC: Matrix Spec Change. These are PullRequest to this project. |
||||
|
||||
Matrix object are Json data. Unstable prefixes must be used for Json keys when the MSC is not merged (i.e. accepted). |
||||
|
||||
#### Matrix data |
||||
|
||||
There are many object and data in the Matrix worlds. Let's focus on the most important and used, `Room` and `Event` |
||||
|
||||
##### Room |
||||
|
||||
`Room` is a place which contains ordered `Event`s. They are identified with their `room_id`. Nearly all the data are stored in rooms, and shared using homeserver to all the Room Member. |
||||
|
||||
*Note*: Spaces are also Rooms with a different `type`. |
||||
|
||||
##### Event |
||||
|
||||
`Events` are items of a Room, where data is embedded. |
||||
|
||||
There are 2 types of Room Event: |
||||
|
||||
- Regular Events: contain useful content for the user (message, image, etc.), but are not necessarily displayed as this in the timeline (reaction, message edition, call signaling). |
||||
- State Events: contain the state of the Room (name, topic, etc.). They have a non null value for the key `state_key`. |
||||
|
||||
Also all the Room Member details are in State Events: one State Event per member. In this case, the `state_key` is the matrixId (= userId). |
||||
|
||||
Important Fields of an Event: |
||||
- `event_id`: unique across the Matrix universe; |
||||
- `room_id`: the room the Event belongs to; |
||||
- `type`: describe what the Event contain, especially in the `content` section, and how the SDK should handle this Event; |
||||
- `content`: dynamic Event data; depends on the `type`. |
||||
|
||||
So we have a triple `event_id`, `type`, `state_key` which uniquely defines an Event. |
||||
|
||||
#### Sync |
||||
|
||||
This is managed by the Rust SDK. |
||||
|
||||
### The Android project |
||||
|
||||
The project should compile out of the box. |
||||
|
||||
This Android project is a multi modules project. |
||||
|
||||
- `app` module is the Android application module. Other modules are libraries; |
||||
- `features` modules contain some UI and can be seen as screen of the application; |
||||
- `libraries` modules contain classes that can be useful for other modules to work. |
||||
|
||||
A few details about some modules: |
||||
|
||||
- `libraries-core` module contains utility classes; |
||||
- `libraries-designsystem` module contains Composables which can be used across the app (theme, etc.); |
||||
- `libraries-elementresources` module contains resource from Element Android (mainly strings); |
||||
- `libraries-matrix` module contains wrappers around the Matrix Rust SDK. |
||||
|
||||
Here is the current module dependency graph: |
||||
|
||||
<!-- To update this graph, run `./tools/docs/generateModuleGraph.sh` (one day the CI will do it hopefully). --> |
||||
<img src=./images/module_graph.png width=800 /> |
||||
|
||||
### Application |
||||
|
||||
(Note: to update) |
||||
|
||||
This is the UI part of the project. |
||||
|
||||
There are two variants of the application: `Gplay` and `Fdroid`. |
||||
|
||||
The main difference is about using Firebase on `Gplay` variant, to have Push from Google Services. `FDroid` variant cannot contain closed source dependency. |
||||
|
||||
`Fdroid` is using background polling to lack the missing of Pushed. Now a solution using UnifiedPush has ben added to the project. See refer to [the dedicated documentation](./unifiedpush.md) for more details. |
||||
|
||||
#### Anvil |
||||
|
||||
TODO |
||||
|
||||
##### Node |
||||
|
||||
TODO |
||||
|
||||
#### Other frameworks |
||||
|
||||
- Dependency injection is managed by [Dagger](https://dagger.dev/) (SDK) and [Hilt](https://developer.android.com/training/dependency-injection/hilt-android) (App); |
||||
|
||||
### Push |
||||
|
||||
Please see the dedicated documentation for more details. |
||||
|
||||
This is the classical scenario: |
||||
|
||||
- App receives a Push. Note: Push is ignored if app is in foreground; |
||||
- App asks the SDK to load Event data (fastlane mode). We have a change to get the data faster and display the notification faster; |
||||
- App asks the SDK to perform a sync request. |
||||
|
||||
### Dependencies management |
||||
|
||||
TODO Update |
||||
All the dependencies are declared in `build.gradle` files. But some versions are declared in [this dedicated file](../dependencies.gradle). |
||||
|
||||
When adding a new dependency, you will have to update the file [dependencies_groups.gradle](../dependencies_groups.gradle) to allow the dependency to be downloaded from the artifact repository. Sometimes sub-dependencies need to be added too, until the project can compile. |
||||
|
||||
[Dependabot](https://github.com/dependabot) is set up on the project. This tool will automatically create Pull Request to upgrade our dependencies one by one. |
||||
dependencies_group, gradle files, Dependabot, etc. |
||||
|
||||
### Test |
||||
|
||||
Please refer to [this dedicated document](./ui-tests.md). |
||||
|
||||
TODO add link to the dedicated screenshot test documentation |
||||
|
||||
### Other points |
||||
|
||||
#### Logging |
||||
|
||||
**Important warning: ** NEVER log private user data, or use the flag `LOG_PRIVATE_DATA`. Be very careful when logging `data class`, all the content will be output! |
||||
|
||||
[Timber](https://github.com/JakeWharton/timber) is used to log data to logcat. We do not use directly the `Log` class. If possible please use a tag, as per |
||||
|
||||
````kotlin |
||||
Timber.tag(loggerTag.value).d("my log") |
||||
```` |
||||
|
||||
because automatic tag (= class name) will not be available on the release version. |
||||
|
||||
Also generally it is recommended to provide the `Throwable` to the Timber log functions. |
||||
|
||||
Last point, not that `Timber.v` function may have no effect on some devices. Prefer using `Timber.d` and up. |
||||
|
||||
#### Rageshake |
||||
|
||||
Rageshake is a feature to send bug report directly from the application. Just shake your phone and you will be prompted to send a bug report. |
||||
|
||||
Bug report can contain: |
||||
- a screenshot of the current application state |
||||
- the application logs from up to 15 application starts |
||||
- the logcat logs |
||||
- the key share history (crypto data) |
||||
|
||||
The data will be sent to an internal server, which is not publicly accessible. A GitHub issue will also be created to a private GitHub repository. |
||||
|
||||
Rageshake can be very useful to get logs from a release version of the application. |
||||
|
||||
### Tips |
||||
|
||||
- Element Android has a `developer mode` in the `Settings/Advanced settings`. Other useful options are available here; |
||||
- Show hidden Events can also help to debug feature. When developer mode is enabled, it is possible to view the source (= the Json content) of any Events; |
||||
- Type `/devtools` in a Room composer to access a developer menu. There are some other entry points. Developer mode has to be enabled; |
||||
- Hidden debug menu: when developer mode is enabled and on debug build, there are some extra screens that can be accessible using the green wheel. In those screens, it will be possible to toggle some feature flags; |
||||
- Using logcat, filtering with `onResume` can help you to understand what screen are currently displayed on your device. Searching for string displayed on the screen can also help to find the running code in the codebase. |
||||
- When this is possible, prefer using `sealed interface` instead of `sealed class`; |
||||
- When writing temporary code, using the string "DO NOT COMMIT" in a comment can help to avoid committing things by mistake. If committed and pushed, the CI will detect this String and will warn the user about it. |
||||
|
||||
## Happy coding! |
||||
|
||||
The team is here to support you, feel free to ask anything to other developers. |
||||
|
||||
Also please feel to update this documentation, if incomplete/wrong/obsolete/etc. |
||||
|
||||
**Thanks!** |
||||
@ -0,0 +1,24 @@
@@ -0,0 +1,24 @@
|
||||
# Analytics in Element |
||||
|
||||
<!--- TOC --> |
||||
|
||||
* [Solution](#solution) |
||||
* [How to add a new Event](#how-to-add-a-new-event) |
||||
* [Forks of Element](#forks-of-element) |
||||
|
||||
<!--- END --> |
||||
|
||||
## Solution |
||||
|
||||
Element is using PostHog to send analytics event. |
||||
We ask for the user to give consent before sending any analytics data. |
||||
|
||||
## How to add a new Event |
||||
|
||||
The analytics plan is shared between all Element clients. To add an Event, please open a PR to this project: https://github.com/matrix-org/matrix-analytics-events |
||||
|
||||
Then, once the PR has been merged, you can run the tool `import_analytic_plan.sh` to import the plan to Element, and then you can use the new Event. Note that this tool is run by Github action once a week. |
||||
|
||||
## Forks of Element |
||||
|
||||
Analytics on forks are disabled by default. Please refer to AnalyticsConfig and there implementation to setup analytics on your project. |
||||
@ -0,0 +1,106 @@
@@ -0,0 +1,106 @@
|
||||
## Danger |
||||
|
||||
<!--- TOC --> |
||||
|
||||
* [What does danger checks](#what-does-danger-checks) |
||||
* [PR check](#pr-check) |
||||
* [Quality check](#quality-check) |
||||
* [Setup](#setup) |
||||
* [Run danger locally](#run-danger-locally) |
||||
* [Danger user](#danger-user) |
||||
* [Useful links](#useful-links) |
||||
|
||||
<!--- END --> |
||||
|
||||
## What does danger checks |
||||
|
||||
### PR check |
||||
|
||||
See the [dangerfile](../tools/danger/dangerfile.js). If you add rules in the dangerfile, please update the list below! |
||||
|
||||
Here are the checks that Danger does so far: |
||||
|
||||
- PR description is not empty |
||||
- Big PR got a warning to recommend to split |
||||
- PR contains a file for towncrier and extension is checked |
||||
- PR does not modify frozen classes |
||||
- PR contains a Sign-Off, with exception for Element employee contributors |
||||
- PR with change on layout should include screenshot in the description |
||||
- PR which adds png file warn about the usage of vector drawables |
||||
- non draft PR should have a reviewer |
||||
- files containing translations are not modified by developers |
||||
|
||||
### Quality check |
||||
|
||||
After all the checks that generate checkstyle XML report, such as Ktlint, lint, or Detekt, Danger is run with this [dangerfile](../tools/danger/dangerfile-lint.js), in order to post comments to the PR with the detected error and warnings. |
||||
|
||||
To run locally, you will have to install the plugin `danger-plugin-lint-report` using: |
||||
|
||||
```shell |
||||
yarn add danger-plugin-lint-report --dev |
||||
``` |
||||
|
||||
## Setup |
||||
|
||||
This operation should not be necessary, since Danger is already setup for the project. |
||||
|
||||
To setup danger to the project, run: |
||||
|
||||
```shell |
||||
bundle exec danger init |
||||
``` |
||||
|
||||
## Run danger locally |
||||
|
||||
When modifying the [dangerfile](../tools/danger/dangerfile.js), you can check it by running Danger locally. |
||||
|
||||
To run danger locally, install it and run: |
||||
|
||||
```shell |
||||
bundle exec danger pr <PR_URL> --dangerfile=./tools/danger/dangerfile.js |
||||
``` |
||||
|
||||
For instance: |
||||
|
||||
```shell |
||||
bundle exec danger pr https://github.com/vector-im/element-android/pull/6637 --dangerfile=./tools/danger/dangerfile.js |
||||
``` |
||||
|
||||
We may need to create a GitHub token to have less API rate limiting, and then set the env var: |
||||
|
||||
```shell |
||||
export DANGER_GITHUB_API_TOKEN='YOUR_TOKEN' |
||||
``` |
||||
|
||||
Swift and Kotlin (just in case) |
||||
|
||||
```shell |
||||
bundle exec danger-swift pr <PR_URL> --dangerfile=./tools/danger/dangerfile.js |
||||
bundle exec danger-kotlin pr <PR_URL> --dangerfile=./tools/danger/dangerfile.js |
||||
``` |
||||
|
||||
## Danger user |
||||
|
||||
To let Danger check all the PRs, including PRs form forks, a GitHub account have been created: |
||||
- login: ElementBot |
||||
- password: Stored on Passbolt |
||||
- GitHub token: A token with limited access has been created and added to the repository https://github.com/vector-im/element-android as secret DANGER_GITHUB_API_TOKEN. This token is not saved anywhere else. In case of problem, just delete it and create a new one, then update the secret. |
||||
|
||||
PRs from forks do not always have access to the secret `secrets.DANGER_GITHUB_API_TOKEN`, so `secrets.GITHUB_TOKEN` is also provided to the job environment. If `secrets.DANGER_GITHUB_API_TOKEN` is available, it will be used, so user `ElementBot` will comment the PR. Else `secrets.GITHUB_TOKEN` will be used, and bot `github-actions` will comment the PR. |
||||
|
||||
## Useful links |
||||
|
||||
- https://danger.systems/ |
||||
- https://danger.systems/js/ |
||||
- https://danger.systems/js/guides/getting_started.html |
||||
- https://danger.systems/js/reference.html |
||||
- https://github.com/danger/awesome-danger |
||||
|
||||
Some danger files to get inspired from |
||||
|
||||
- https://github.com/artsy/emission/blob/master/dangerfile.ts |
||||
- https://github.com/facebook/react-native/blob/master/bots/dangerfile.js |
||||
- https://github.com/apollographql/apollo-client/blob/master/config/dangerfile.ts |
||||
- https://github.com/styleguidist/react-styleguidist/blob/master/dangerfile.js |
||||
- https://github.com/storybooks/storybook/blob/master/dangerfile.js |
||||
- https://github.com/ReactiveX/rxjs/blob/master/dangerfile.js |
||||
@ -0,0 +1,55 @@
@@ -0,0 +1,55 @@
|
||||
<!--- TOC --> |
||||
|
||||
* [Testing database migration](#testing-database-migration) |
||||
* [Creating a reference database](#creating-a-reference-database) |
||||
* [Testing](#testing) |
||||
|
||||
<!--- END --> |
||||
|
||||
## Testing database migration |
||||
|
||||
### Creating a reference database |
||||
|
||||
Databases are encrypted, the key to decrypt is needed to setup the test. |
||||
A special build property must be enabled to extract it. |
||||
|
||||
Set `vector.debugPrivateData=true` in `~/.gradle/gradle.properties` (to avoid committing by mistake) |
||||
|
||||
Launch the app in your emulator, login and use the app to fill up the database. |
||||
|
||||
Save the key for the tested database |
||||
``` |
||||
RealmKeysUtils W Database key for alias `session_db_fe9f212a611ccf6dea1141777065ed0a`: 935a6dfa0b0fc5cce1414194ed190.... |
||||
RealmKeysUtils W Database key for alias `crypto_module_fe9f212a611ccf6dea1141777065ed0a`: 7b9a21a8a311e85d75b069a343..... |
||||
``` |
||||
|
||||
|
||||
Use the [Device File Explorer](https://developer.android.com/studio/debug/device-file-explorer) to extrat the database file from the emulator. |
||||
|
||||
Go to `data/data/im.vector.app.debug/files/<hash>/` |
||||
Pick the database you want to test (name can be found in SessionRealmConfigurationFactory): |
||||
- crypto_store.realm for crypto |
||||
- disk_store.realm for session |
||||
- etc... |
||||
|
||||
Download the file on your disk |
||||
|
||||
### Testing |
||||
|
||||
Copy the file in `src/AndroidTest/assets` |
||||
|
||||
see `CryptoSanityMigrationTest` or `RealmSessionStoreMigration43Test` for sample tests. |
||||
|
||||
There are already some databases in the assets folder. |
||||
The existing test will properly detect schema changes, and fail with such errors if a migration is missing: |
||||
|
||||
``` |
||||
io.realm.exceptions.RealmMigrationNeededException: Migration is required due to the following errors: |
||||
- Property 'CryptoMetadataEntity.foo' has been added. |
||||
``` |
||||
|
||||
If you want to test properly more complex database migration (dynamic transforms) ensure that the database contains |
||||
the entity you want to migrate. |
||||
|
||||
You can explore the database with [realm studio](https://www.mongodb.com/docs/realm/studio/) if needed. |
||||
|
||||
@ -0,0 +1,141 @@
@@ -0,0 +1,141 @@
|
||||
# Element Android design |
||||
|
||||
<!--- TOC --> |
||||
|
||||
* [Introduction](#introduction) |
||||
* [How to import from Figma to the Element Android project](#how-to-import-from-figma-to-the-element-android-project) |
||||
* [Colors](#colors) |
||||
* [Text](#text) |
||||
* [Dimension, position and margin](#dimension-position-and-margin) |
||||
* [Icons](#icons) |
||||
* [Export drawable from Figma](#export-drawable-from-figma) |
||||
* [Import in Android Studio](#import-in-android-studio) |
||||
* [Images](#images) |
||||
* [Figma links](#figma-links) |
||||
* [Coumpound](#coumpound) |
||||
* [Login](#login) |
||||
* [Login v2](#login-v2) |
||||
* [Room list](#room-list) |
||||
* [Timeline](#timeline) |
||||
* [Voice message](#voice-message) |
||||
* [Room settings](#room-settings) |
||||
* [VoIP](#voip) |
||||
* [Presence](#presence) |
||||
* [Spaces](#spaces) |
||||
* [List to be continued...](#list-to-be-continued) |
||||
|
||||
<!--- END --> |
||||
|
||||
## Introduction |
||||
|
||||
Design at element.io is done using Figma - https://www.figma.com |
||||
|
||||
## How to import from Figma to the Element Android project |
||||
|
||||
Integration should be done using the Android development best practice, and should follow the existing convention in the code. |
||||
|
||||
### Colors |
||||
|
||||
Element Android already contains all the colors which can be used by the designer, in the module `ui-style`. |
||||
Some of them depend on the theme, so ensure to use theme attributes and not colors directly. |
||||
|
||||
### Text |
||||
|
||||
- click on a text on Figma |
||||
- on the right panel, information about the style and colors are displayed |
||||
- in Element Android, text style are already defined, generally you should not create new style |
||||
- apply the style and the color to the layout |
||||
|
||||
### Dimension, position and margin |
||||
|
||||
- click on an item on Figma |
||||
- dimensions of the item will be displayed. |
||||
- move the mouse to other items to get relative positioning, margin, etc. |
||||
|
||||
### Icons |
||||
|
||||
#### Export drawable from Figma |
||||
|
||||
- click on the element to export |
||||
- ensure that the correct layer is selected. Sometimes the parent layer has to be selected on the left panel |
||||
- on the right panel, click on "export" |
||||
- select SVG |
||||
- you can check the preview of what will be exported |
||||
- click on "export" and save the file locally |
||||
- unzip the file if necessary |
||||
|
||||
It's also possible for any icon to go to the main component by right-clicking on the icon. |
||||
|
||||
#### Import in Android Studio |
||||
|
||||
- right click on the drawable folder where the drawable will be created |
||||
- click on "New"/"Vector Asset" |
||||
- select the exported file |
||||
- update the filename if necessary |
||||
- click on "Next" and click on "Finish" |
||||
- open the created vector drawable |
||||
- optionally update the color(s) to "#FF0000" (red) to ensure that the drawable is correctly tinted at runtime. |
||||
|
||||
### Images |
||||
|
||||
Android 4.3 (18+) fully supports the WebP image format which can often provide smaller image sizes without drastically impacting image quality (depending on the output encoding quality). |
||||
When importing non vector images, WebP is the preferred format. |
||||
|
||||
Images can be converted to the WebP within Android Studio by |
||||
- right clicking the image file within the project file explorer |
||||
- select `Convert to WebP` |
||||
|
||||
https://developer.android.com/studio/write/convert-webp |
||||
|
||||
## Figma links |
||||
|
||||
Figma links can be included in the layout, for future reference, but it is also OK to add a paragraph below here, to centralize the information |
||||
|
||||
Main entry point: https://www.figma.com/files/project/5612863/Element?fuid=779371459522484071 |
||||
|
||||
Note: all the Figma links are not publicly available. |
||||
|
||||
### Coumpound |
||||
|
||||
Coumpound contains the theme of the application, with all the components, in Light and Dark theme: palette (colors), typography, iconography, etc. |
||||
|
||||
https://www.figma.com/file/X4XTH9iS2KGJ2wFKDqkyed/Compound |
||||
|
||||
### Login |
||||
|
||||
TBD |
||||
|
||||
#### Login v2 |
||||
|
||||
https://www.figma.com/file/xdV4PuI3DlzA1EiBvbrggz/Login-Flow-v2 |
||||
|
||||
### Room list |
||||
|
||||
TBD |
||||
|
||||
### Timeline |
||||
|
||||
https://www.figma.com/file/x1HYYLYMmbYnhfoz2c2nGD/%5BRiotX%5D-Misc?node-id=0%3A1 |
||||
|
||||
### Voice message |
||||
|
||||
https://www.figma.com/file/uaWc62Ux2DkZC4OGtAGcNc/Voice-Messages?node-id=473%3A12 |
||||
|
||||
### Room settings |
||||
|
||||
TBD |
||||
|
||||
### VoIP |
||||
|
||||
https://www.figma.com/file/V6m2z0oAtUV1l8MdyIrAep/VoIP?node-id=4254%3A25767 |
||||
|
||||
### Presence |
||||
|
||||
https://www.figma.com/file/qmvEskET5JWva8jZJ4jX8o/Presence---User-Status?node-id=114%3A9174 |
||||
(Option B is chosen) |
||||
|
||||
### Spaces |
||||
|
||||
https://www.figma.com/file/m7L63aGPW7iHnIYStfdxCe/Spaces?node-id=192%3A30161 |
||||
|
||||
### List to be continued... |
||||
@ -0,0 +1,58 @@
@@ -0,0 +1,58 @@
|
||||
# Flipper |
||||
|
||||
<!--- TOC --> |
||||
|
||||
* [Introduction](#introduction) |
||||
* [Setup](#setup) |
||||
* [Troubleshoot](#troubleshoot) |
||||
* [No device found issue](#no-device-found-issue) |
||||
* [Diagnostic Activity](#diagnostic-activity) |
||||
* [Other](#other) |
||||
* [Links](#links) |
||||
|
||||
<!--- END --> |
||||
|
||||
## Introduction |
||||
|
||||
[Flipper](https://fbflipper.com) is a powerful tool from Meta, which allow to inspect the running application details and states from your computer. |
||||
|
||||
Flipper is configured in the Element Android project to let the developers be able to: |
||||
- inspect all the Realm databases content; |
||||
- do layout inspection; |
||||
- see the crash logs; |
||||
- see the logcat; |
||||
- see all the network requests; |
||||
- see all the SharedPreferences; |
||||
- take screenshots and record videos of the device; |
||||
- and more! |
||||
|
||||
## Setup |
||||
|
||||
- Install Flipper on your computer. Follow instructions here: https://fbflipper.com/docs/getting-started/index/ |
||||
- Run the debug version of Element on an emulator or on a real device. |
||||
|
||||
### Troubleshoot |
||||
|
||||
#### No device found issue |
||||
|
||||
The configuration of the Flipper application has to be updated. The issue has been asked and answered here: https://stackoverflow.com/questions/71744103/android-emulator-unable-to-connect-to-flipper/72608113#72608113 |
||||
|
||||
#### Diagnostic Activity |
||||
|
||||
Flipper comes with a Diagnostic Activity that you can start from command line using: |
||||
|
||||
```shell |
||||
adb shell am start -n im.vector.app.debug/com.facebook.flipper.android.diagnostics.FlipperDiagnosticActivity |
||||
``` |
||||
|
||||
It provides some log which can help to figure out what's going on client side. |
||||
|
||||
#### Other |
||||
|
||||
https://fbflipper.com/docs/getting-started/troubleshooting/android/ may help. |
||||
|
||||
## Links |
||||
|
||||
- Official Flipper website: https://fbflipper.com |
||||
- Realm Plugin for Flipper: https://github.com/kamgurgul/Flipper-Realm |
||||
- Dedicated Matrix room: https://matrix.to/#/#unifiedpush:matrix.org |
||||
@ -0,0 +1,106 @@
@@ -0,0 +1,106 @@
|
||||
# Identity server |
||||
|
||||
<!--- TOC --> |
||||
|
||||
* [Introduction](#introduction) |
||||
* [Implementation](#implementation) |
||||
* [Related MSCs](#related-mscs) |
||||
* [Steps and requirements](#steps-and-requirements) |
||||
* [Screens](#screens) |
||||
* [Settings](#settings) |
||||
* [Discovery screen](#discovery-screen) |
||||
* [Set identity server screen](#set-identity-server-screen) |
||||
* [Ref:](#ref:) |
||||
|
||||
<!--- END --> |
||||
|
||||
Issue: #607 |
||||
PR: #1354 |
||||
|
||||
## Introduction |
||||
Identity servers support contact discovery on Matrix by letting people look up Third Party Identifiers to see if the owner has publicly linked them with their Matrix ID. |
||||
|
||||
## Implementation |
||||
|
||||
The current implementation was Inspired by the code from Riot-Android. |
||||
|
||||
Difference though (list not exhaustive): |
||||
- Only API v2 is supported (see https://matrix.org/docs/spec/identity_service/latest) |
||||
- Homeserver has to be up to date to support binding (Versions.isLoginAndRegistrationSupportedBySdk() has to return true) |
||||
- The SDK managed the session and client secret when binding ThreePid. Those data are not exposed to the client. |
||||
- The SDK supports incremental sendAttempt (this is not used by Element) |
||||
- The "Continue" button is now under the information, and not as the same place that the checkbox |
||||
- The app can cancel a binding. Current data are erased from DB. |
||||
- The API (IdentityService) is improved. |
||||
- A new DB to store data related to the identity server management. |
||||
|
||||
Missing features (list not exhaustive): |
||||
- Invite by 3Pid (will be in a dedicated PR) |
||||
- Add email or phone to account (not P1, can be done on Element-Web) |
||||
- List email and phone of the account (could be done in a dedicated PR) |
||||
- Search contact (not P1) |
||||
- Logout from identity server when user sign out or deactivate his account. |
||||
|
||||
## Related MSCs |
||||
The list can be found here: https://matrix.org/blog/2019/09/27/privacy-improvements-in-synapse-1-4-and-riot-1-4 |
||||
|
||||
## Steps and requirements |
||||
|
||||
- Only one identity server by account can be set. The user's choice is stored in account data with key `m.identity_server`. But every clients will managed its own token to log in to the identity server |
||||
```json |
||||
{ |
||||
"type": "m.identity_server", |
||||
"content": { |
||||
"base_url": "https://matrix.org" |
||||
} |
||||
} |
||||
``` |
||||
- The accepted terms are stored in the account data: |
||||
```json |
||||
{ |
||||
"type": "m.accepted_terms", |
||||
"content": { |
||||
"accepted": [ |
||||
"https://vector.im/identity-server-privacy-notice-1" |
||||
] |
||||
} |
||||
} |
||||
``` |
||||
|
||||
- Default identity server URL, from Wellknown data is proposed to the user. |
||||
- Identity server can be set |
||||
- Identity server can be changed on another user's device, so when the change is detected (thanks to account data sync) Element should properly disconnect from a previous identity server (I think it was not the case in Riot-Android, where we keep the token forever) |
||||
- Registration to the identity server is managed with an openId token |
||||
- Terms of service can be accepted when configuring the identity server. |
||||
- Terms of service can be accepted after, if they change. |
||||
- Identity server can be modified |
||||
- Identity server can be disconnected with a warning dialog, with special content if there are current bound 3pid on this identity server. |
||||
- Email can be bound |
||||
- Email can be unbound |
||||
- Phone can be bound |
||||
- Phone can be unbound |
||||
- Look up can be performed, to get matrixIds from local contact book (phone and email): Android permission correctly handled (not done yet) |
||||
- Look up pepper can be updated if it is rotated on the identity server |
||||
- Invitation using 3PID can be done (See #548) (not done yet) |
||||
- Homeserver access-token will never be sent to an identity server |
||||
- When user sign-out: logout from the identity server if any. |
||||
- When user deactivate account: logout from the identity server if any. |
||||
|
||||
## Screens |
||||
|
||||
### Settings |
||||
|
||||
Identity server settings can be accessed from the internal setting of the application, both from "Discovery" section and from identity detail section. |
||||
|
||||
### Discovery screen |
||||
|
||||
This screen displays the identity server configuration and the binding of the user's ThreePid (email and msisdn). This is the main screen of the feature. |
||||
|
||||
### Set identity server screen |
||||
|
||||
This screen is a form to set a new identity server URL |
||||
|
||||
## Ref: |
||||
- https://matrix.org/blog/2019/09/27/privacy-improvements-in-synapse-1-4-and-riot-1-4 is a good summary of the role of an identity server and the proper way to configure and use it in respect to the privacy and the consent of the user. |
||||
- API documentation: https://matrix.org/docs/spec/identity_service/latest |
||||
- vector.im TOS: https://vector.im/identity-server-privacy-notice |
||||
@ -0,0 +1,52 @@
@@ -0,0 +1,52 @@
|
||||
## Installing from CI |
||||
|
||||
<!--- TOC --> |
||||
|
||||
* [Installing from Buildkite](#installing-from-buildkite) |
||||
* [Installing from GitHub](#installing-from-github) |
||||
* [Create a GitHub token](#create-a-github-token) |
||||
* [Provide artifact URL](#provide-artifact-url) |
||||
* [Next steps](#next-steps) |
||||
* [Future improvement](#future-improvement) |
||||
|
||||
<!--- END --> |
||||
|
||||
Installing APK build by the CI is possible |
||||
|
||||
### Installing from Buildkite |
||||
|
||||
The script `./tools/install/installFromBuildkite.sh` can be used, but Builkite will be removed soon. See next section. |
||||
|
||||
### Installing from GitHub |
||||
|
||||
To install an APK built by a GitHub action, run the script `./tools/install/installFromGitHub.sh`. You will need to pass a GitHub token to do so. |
||||
|
||||
#### Create a GitHub token |
||||
|
||||
You can create a GitHub token going to your Github account, at this page: [https://github.com/settings/tokens](https://github.com/settings/tokens). |
||||
|
||||
You need to create a token (classic) with the scope `repo/public_repo`. So just check the corresponding checkbox. |
||||
Validity can be long since the scope of this token is limited. You will still be able to delete the token and generate a new one. |
||||
Click on Generate token and save the token locally. |
||||
|
||||
### Provide artifact URL |
||||
|
||||
The script will ask for an artifact URL. You can get this artifact URL by following these steps: |
||||
|
||||
- open the pull request |
||||
- in the check at the bottom, click on `APK Build / Build debug APKs` |
||||
- click on `Summary` |
||||
- scroll to the bottom of the page |
||||
- copy the link `vector-Fdroid-debug` if you want the F-Droid variant or `vector-Gplay-debug` if you want the Gplay variant. |
||||
|
||||
The copied link can be provided to the script. |
||||
|
||||
### Next steps |
||||
|
||||
The script will download the artifact, unzip it and install the correct version (regarding arch) on your device. |
||||
|
||||
Files will be added to the folder `./tmp/DebugApks`. Feel free to cleanup this folder from time to time, the script will not delete files. |
||||
|
||||
### Future improvement |
||||
|
||||
The script could ask the user for a Pull Request number and Gplay/Fdroid choice like it was done with Buildkite script. Using GitHub API may be possible to do that. |
||||
@ -0,0 +1,131 @@
@@ -0,0 +1,131 @@
|
||||
# Integration tests |
||||
|
||||
<!--- TOC --> |
||||
|
||||
* [Pre requirements](#pre-requirements) |
||||
* [Install and run Synapse](#install-and-run-synapse) |
||||
* [Run the test](#run-the-test) |
||||
* [Stop Synapse](#stop-synapse) |
||||
* [Troubleshoot](#troubleshoot) |
||||
* [Android Emulator does cannot reach the homeserver](#android-emulator-does-cannot-reach-the-homeserver) |
||||
* [Tests partially run but some fail with "Unable to contact localhost:8080"](#tests-partially-run-but-some-fail-with-"unable-to-contact-localhost:8080") |
||||
* [virtualenv command fails](#virtualenv-command-fails) |
||||
|
||||
<!--- END --> |
||||
|
||||
Integration tests are useful to ensure that the code works well for any use cases. |
||||
|
||||
They can also be used as sample on how to use the Matrix SDK. |
||||
|
||||
In a ideal world, every API of the SDK should be covered by integration tests. For the moment, we have test mainly for the Crypto part, which is the tricky part. But it covers quite a lot of features: accounts creation, login to existing account, send encrypted messages, keys backup, verification, etc. |
||||
|
||||
The Matrix SDK is able to open multiple sessions, for the same user, of for different users. This way we can test communication between several sessions on a single device. |
||||
|
||||
## Pre requirements |
||||
|
||||
Integration tests need a homeserver running on localhost. |
||||
|
||||
The documentation describes what we do to have one, using [Synapse](https://github.com/matrix-org/synapse/), which is the Matrix reference homeserver. |
||||
|
||||
## Install and run Synapse |
||||
|
||||
Steps: |
||||
|
||||
- Install virtualenv |
||||
|
||||
```bash |
||||
python3 -m pip install virtualenv |
||||
``` |
||||
|
||||
- Clone Synapse repository |
||||
|
||||
```bash |
||||
git clone -b develop https://github.com/matrix-org/synapse.git |
||||
``` |
||||
or |
||||
```bash |
||||
git clone -b develop git@github.com:matrix-org/synapse.git |
||||
``` |
||||
|
||||
You should have the develop branch cloned by default. |
||||
|
||||
- Run synapse, from the Synapse folder you just cloned |
||||
|
||||
```bash |
||||
virtualenv -p python3 env |
||||
source env/bin/activate |
||||
pip install -e . |
||||
demo/start.sh --no-rate-limit |
||||
|
||||
``` |
||||
|
||||
Alternatively, to install the latest Synapse release package (and not a cloned branch) you can run the following instead of `git clone` and `pip install -e .`: |
||||
|
||||
```bash |
||||
pip install matrix-synapse |
||||
``` |
||||
|
||||
On your first run, you will want to stop the demo and edit the config to correct the `public_baseurl` to http://10.0.2.2:8080 and restart the server. |
||||
|
||||
You should now have 3 running federated Synapse instances 🎉, at http://127.0.0.1:8080/, http://127.0.0.1:8081/ and http://127.0.0.1:8082/, which should display a "It Works! Synapse is running" message. |
||||
|
||||
## Run the test |
||||
|
||||
It's recommended to run tests using an Android Emulator and not a real device. First reason for that is that the tests will use http://10.0.2.2:8080 to connect to Synapse, which run locally on your machine. |
||||
|
||||
You can run all the tests in the `androidTest` folders. |
||||
|
||||
It can be done using this command: |
||||
|
||||
```bash |
||||
./gradlew vector:connectedAndroidTest matrix-sdk-android:connectedAndroidTest |
||||
``` |
||||
|
||||
## Stop Synapse |
||||
|
||||
To stop Synapse, you can run the following commands: |
||||
|
||||
```bash |
||||
./demo/stop.sh |
||||
``` |
||||
|
||||
And you can deactivate the virtualenv: |
||||
|
||||
```bash |
||||
deactivate |
||||
``` |
||||
|
||||
## Troubleshoot |
||||
|
||||
You'll need python3 to be able to run synapse |
||||
|
||||
### Android Emulator does cannot reach the homeserver |
||||
|
||||
Try on the Emulator browser to open "http://10.0.2.2:8080". You should see the "Synapse is running" message. |
||||
|
||||
### Tests partially run but some fail with "Unable to contact localhost:8080" |
||||
|
||||
This is because the `public_baseurl` of synapse is not consistent with the endpoint that the tests are connecting to. |
||||
|
||||
Ensure you have the following configuration in `demo/etc/8080.config`. |
||||
|
||||
``` |
||||
public_baseurl: http://10.0.2.2:8080/ |
||||
``` |
||||
|
||||
After changing this you will need to restart synapse using `demo/stop.sh` and `demo/start.sh` to load the new configuration. |
||||
|
||||
### virtualenv command fails |
||||
|
||||
You can try using |
||||
```bash |
||||
python3 -m venv env |
||||
``` |
||||
or |
||||
```bash |
||||
python3 -m virtualenv env |
||||
``` |
||||
instead of |
||||
```bash |
||||
virtualenv -p python3 env |
||||
``` |
||||
@ -0,0 +1,96 @@
@@ -0,0 +1,96 @@
|
||||
# Jitsi in Element Android |
||||
|
||||
<!--- TOC --> |
||||
|
||||
* [Native Jitsi SDK](#native-jitsi-sdk) |
||||
* [How to build the Jitsi Meet SDK](#how-to-build-the-jitsi-meet-sdk) |
||||
* [Jitsi version](#jitsi-version) |
||||
* [Run the build script](#run-the-build-script) |
||||
* [Link with the new generated library](#link-with-the-new-generated-library) |
||||
* [Sanity tests](#sanity-tests) |
||||
* [Export the build library](#export-the-build-library) |
||||
|
||||
<!--- END --> |
||||
|
||||
Native Jitsi support has been added to Element Android by the PR [#1914](https://github.com/vector-im/element-android/pull/1914). The description of the PR contains some documentation about the behaviour in each possible room configuration. |
||||
|
||||
Also, ensure to have a look on [the documentation from Element Web](https://github.com/vector-im/element-web/blob/develop/docs/jitsi.md) |
||||
|
||||
The official documentation about how to integrate the Jitsi SDK in an Android app is available here: https://jitsi.github.io/handbook/docs/dev-guide/dev-guide-android-sdk. |
||||
|
||||
## Native Jitsi SDK |
||||
|
||||
The Jitsi SDK is built by ourselves with the flag LIBRE_BUILD, to be able to be integrated on the F-Droid version of Element Android. |
||||
|
||||
The generated maven repository is then host in the project https://github.com/vector-im/jitsi_libre_maven |
||||
|
||||
### How to build the Jitsi Meet SDK |
||||
|
||||
#### Jitsi version |
||||
|
||||
Update the script `./tools/jitsi/build_jisti_libs.sh` with the tag of the project `https://github.com/jitsi/jitsi-meet`. |
||||
|
||||
Latest tag can be found from this page: https://github.com/jitsi/jitsi-meet-release-notes/blob/master/CHANGELOG-MOBILE-SDKS.md |
||||
|
||||
Currently we are building the version with the tag `android-sdk-3.10.0`. |
||||
|
||||
#### Run the build script |
||||
|
||||
At the root of the Element Android, run the following script: |
||||
|
||||
```shell script |
||||
./tools/jitsi/build_jisti_libs.sh |
||||
``` |
||||
|
||||
It will build the Jitsi Meet Android library and put every generated files in the folder `/tmp/jitsi` |
||||
|
||||
#### Link with the new generated library |
||||
|
||||
- Update the file `./build.gradle` to use the previously created local Maven repository. Currently we have this line: |
||||
|
||||
```groovy |
||||
url "https://github.com/vector-im/jitsi_libre_maven/raw/master/android-sdk-3.10.0" |
||||
``` |
||||
|
||||
You can uncomment and update the line starting with `// url "file://...` and comment the line starting with `url`, to test the library using the locally generated Maven repository. |
||||
|
||||
- Update the dependency of the Jitsi Meet library in the file `./vector/build.gradle`. Currently we have this line: |
||||
|
||||
```groovy |
||||
implementation('org.jitsi.react:jitsi-meet-sdk:3.10.0') |
||||
``` |
||||
|
||||
- Update the dependency of the WebRTC library in the file `./vector/build.gradle`. Currently we have this line: |
||||
|
||||
```groovy |
||||
implementation('com.facebook.react:react-native-webrtc:1.92.1-jitsi-9093212@aar') |
||||
``` |
||||
|
||||
- Perform a gradle sync and build the project |
||||
- Perform test |
||||
|
||||
#### Sanity tests |
||||
|
||||
In order to validate that the upgrade of the Jitsi and WebRTC dependency does not break anything, the following sanity tests have to be performed, using two devices: |
||||
- Make 1-1 audio call (so using WebRTC) |
||||
- Make 1-1 video call (so using WebRTC) |
||||
- Create and join a conference call with audio only (so using Jitsi library). Leave the conference. Join it again. |
||||
- Create and join a conference call with audio and video (so using Jitsi library) Leave the conference. Join it again. |
||||
|
||||
#### Export the build library |
||||
|
||||
If all the tests are passed, you can export the generated Jitsi library to our Maven repository. |
||||
|
||||
- Clone the project https://github.com/vector-im/jitsi_libre_maven. |
||||
- Create a new folder with the version name. |
||||
- Copy every generated files form `/tmp/jitsi` to the folder you have just created. |
||||
- Commit and push the change on https://github.com/vector-im/jitsi_libre_maven. |
||||
- Update the file `./build.gradle` to use the previously created Maven repository. Currently we have this line: |
||||
|
||||
```groovy |
||||
url "https://github.com/vector-im/jitsi_libre_maven/raw/master/android-sdk-3.10.0" |
||||
``` |
||||
|
||||
- Build the project and perform the sanity tests again. |
||||
|
||||
- Create a PR for project Element Android and add a changelog file `<PR_NUMBER>.misc` to notify about the library upgrade. |
||||
@ -0,0 +1,54 @@
@@ -0,0 +1,54 @@
|
||||
# Nightly builds |
||||
|
||||
<!--- TOC --> |
||||
|
||||
* [Configuration](#configuration) |
||||
* [How to register to get nightly build](#how-to-register-to-get-nightly-build) |
||||
* [Build nightly manually](#build-nightly-manually) |
||||
|
||||
<!--- END --> |
||||
|
||||
## Configuration |
||||
|
||||
The nightly build will contain what's on develop, in release mode, for Gplay variant. It is signed using a dedicated signature, and has a dedicated appId (`im.vector.app.nightly`), so it can be installed along with the production version of Element Android. The only other difference compared to Element Android is a different app icon background. We do not want to change the app name since it will also affect some strings in the app, and we do want to do that. |
||||
|
||||
Nightly builds are built and released to Firebase every days, and automatically. |
||||
|
||||
This is recommended to exclusively use this app, with your main account, instead of Element Android, and fallback to Element Android just in case of regression, to discover as soon as possible any regression, and report it to the team. To avoid double notification, you may want to disable the notification from the Element Android production version. Just open Element Android, navigate to `Settings/Notifications` and uncheck `Enable notifications for this session`. |
||||
|
||||
*Note:* Due to a limitation of Firebase, the nightly build is the universal build, which means that the size of the APK is a bit bigger, but this should not have any other side effect. |
||||
|
||||
## How to register to get nightly build |
||||
|
||||
Provide your email to the Android team, who will add it to the list "External testers" on Firebase. You will then receive an invite on the provided email. |
||||
|
||||
Follow the instructions on the email to install the latest nightly build. This is not clear yet if new nightly build will be automatically installed or not. |
||||
|
||||
## Build nightly manually |
||||
|
||||
Nightly build can be built manually from your computer. You will need to retrieved some secrets from Passbolt and add them to your file `~/.gradle/gradle.properties`: |
||||
|
||||
``` |
||||
signing.element.nightly.storePassword=VALUE_FROM_PASSBOLT |
||||
signing.element.nightly.keyId=VALUE_FROM_PASSBOLT |
||||
signing.element.nightly.keyPassword=VALUE_FROM_PASSBOLT |
||||
``` |
||||
|
||||
You will also need to add the environment variable `FIREBASE_TOKEN`: |
||||
|
||||
```sh |
||||
export FIREBASE_TOKEN=VALUE_FROM_PASSBOLT |
||||
``` |
||||
|
||||
Then you can run the following commands (which are also used in the file for [the GitHub action](../.github/workflows/nightly.yml)): |
||||
|
||||
```sh |
||||
git checkout develop |
||||
mv towncrier.toml towncrier.toml.bak |
||||
sed 's/CHANGES\.md/CHANGES_NIGHTLY\.md/' towncrier.toml.bak > towncrier.toml |
||||
rm towncrier.toml.bak |
||||
yes n | towncrier build --version nightly |
||||
./gradlew assembleGplayNightly appDistributionUploadGplayNightly $CI_GRADLE_ARG_PROPERTIES |
||||
``` |
||||
|
||||
Then you can reset the change on the codebase. |
||||
@ -0,0 +1,284 @@
@@ -0,0 +1,284 @@
|
||||
This document aims to describe how Element android displays notifications to the end user. It also clarifies notifications and background settings in the app. |
||||
|
||||
# Table of Contents |
||||
|
||||
<!--- TOC --> |
||||
|
||||
* [Prerequisites Knowledge](#prerequisites-knowledge) |
||||
* [How does a matrix client get a message from a homeserver?](#how-does-a-matrix-client-get-a-message-from-a-homeserver?) |
||||
* [How does a mobile app receives push notification](#how-does-a-mobile-app-receives-push-notification) |
||||
* [Push VS Notification](#push-vs-notification) |
||||
* [Push in the matrix federated world](#push-in-the-matrix-federated-world) |
||||
* [How does the homeserver know when to notify a client?](#how-does-the-homeserver-know-when-to-notify-a-client?) |
||||
* [Push vs privacy, and mitigation](#push-vs-privacy-and-mitigation) |
||||
* [Background processing limitations](#background-processing-limitations) |
||||
* [Element Notification implementations](#element-notification-implementations) |
||||
* [Requirements](#requirements) |
||||
* [Foreground sync mode (Gplay and F-Droid)](#foreground-sync-mode-gplay-and-f-droid) |
||||
* [Push (FCM) received in background](#push-fcm-received-in-background) |
||||
* [FCM Fallback mode](#fcm-fallback-mode) |
||||
* [F-Droid background Mode](#f-droid-background-mode) |
||||
* [Application Settings](#application-settings) |
||||
|
||||
<!--- END --> |
||||
|
||||
|
||||
First let's start with some prerequisite knowledge |
||||
|
||||
## Prerequisites Knowledge |
||||
|
||||
### How does a matrix client get a message from a homeserver? |
||||
|
||||
In order to get messages from a homeserver, a matrix client need to perform a ``sync`` operation. |
||||
|
||||
`To read events, the intended flow of operation is for clients to first call the /sync API without a since parameter. This returns the most recent message events for each room, as well as the state of the room at the start of the returned timeline. ` |
||||
|
||||
The client need to call the `sync` API periodically in order to get incremental updates of the server state (new messages). |
||||
This mechanism is known as **HTTP long Polling**. |
||||
|
||||
Using the **HTTP Long Polling** mechanism a client polls a server requesting new information. |
||||
The server *holds the request open until new data is available*. |
||||
Once available, the server responds and sends the new information. |
||||
When the client receives the new information, it immediately sends another request, and the operation is repeated. |
||||
This effectively emulates a server push feature. |
||||
|
||||
The HTTP long Polling can be fine tuned in the **SDK** using two parameters: |
||||
* timeout (Sync request timeout) |
||||
* delay (Delay between each sync) |
||||
|
||||
**timeout** is a server parameter, defined by: |
||||
``` |
||||
The maximum time to wait, in milliseconds, before returning this request.` |
||||
If no events (or other data) become available before this time elapses, the server will return a response with empty fields. |
||||
By default, this is 0, so the server will return immediately even if the response is empty. |
||||
``` |
||||
|
||||
**delay** is a client preference. When the server responds to a sync request, the client waits for `delay`before calling a new sync. |
||||
|
||||
When the Element Android app is open (i.e in foreground state), the default timeout is 30 seconds, and delay is 0. |
||||
|
||||
### How does a mobile app receives push notification |
||||
|
||||
Push notification is used as a way to wake up a mobile application when some important information is available and should be processed. |
||||
|
||||
Typically in order to get push notification, an application relies on a **Push Notification Service** or **Push Provider**. |
||||
|
||||
For example iOS uses APNS (Apple Push Notification Service). |
||||
Most of android devices relies on Google's Firebase Cloud Messaging (FCM). |
||||
> FCM has replaced Google Cloud Messaging (GCM - deprecated April 10 2018) |
||||
|
||||
FCM will only work on android devices that have Google plays services installed |
||||
(In simple terms, Google Play Services is a background service that runs on Android, which in turn helps in integrating Google’s advanced functionalities to other applications) |
||||
|
||||
De-Googlified devices need to rely on something else in order to stay up to date with a server. |
||||
There some cases when devices with google services cannot use FCM (network infrastructure limitations -firewalls-, |
||||
privacy and or independence requirement, source code licence) |
||||
|
||||
### Push VS Notification |
||||
|
||||
This need some disambiguation, because it is the source of common confusion: |
||||
|
||||
|
||||
*The fact that you see a notification on your screen does not mean that you have successfully configured your PUSH platform.* |
||||
|
||||
Technically there is a difference between a push and a notification. A notification is what you see on screen and/or in the notification Menu/Drawer (in the top bar of the phone). |
||||
|
||||
Notifications are not always triggered by a push (One can display a notification locally triggered by an alarm) |
||||
|
||||
|
||||
### Push in the matrix federated world |
||||
|
||||
In order to send a push to a mobile, App developers need to have a server that will use the FCM APIs, and these APIs requires authentication! |
||||
This server is called a **Push Gateway** in the matrix world |
||||
|
||||
That means that Element Android, a matrix client created by New Vector, is using a **Push Gateway** with the needed credentials (FCM API secret Key) in order to send push to the New Vector client. |
||||
|
||||
If you create your own matrix client, you will also need to deploy an instance of a **Push Gateway** with the credentials needed to use FCM for your app. |
||||
|
||||
On registration, a matrix client must tell its homeserver what Push Gateway to use. |
||||
|
||||
See [Sygnal](https://github.com/matrix-org/sygnal/) for a reference implementation. |
||||
``` |
||||
|
||||
+--------------------+ +-------------------+ |
||||
Matrix HTTP | | | | |
||||
Notification Protocol | App Developer | | Device Vendor | |
||||
| | | | |
||||
+-------------------+ | +----------------+ | | +---------------+ | |
||||
| | | | | | | | | | |
||||
| Matrix homeserver +-----> Push Gateway +------> Push Provider | | |
||||
| | | | | | | | | | |
||||
+-^-----------------+ | +----------------+ | | +----+----------+ | |
||||
| | | | | | |
||||
Matrix | | | | | | |
||||
Client/Server API + | | | | | |
||||
| | +--------------------+ +-------------------+ |
||||
| +--+-+ | |
||||
| | <-------------------------------------------+ |
||||
+---+ | |
||||
| | Provider Push Protocol |
||||
+----+ |
||||
|
||||
Mobile Device or Client |
||||
``` |
||||
|
||||
Recommended reading: |
||||
* https://thomask.sdf.org/blog/2016/12/11/riots-magical-push-notifications-in-ios.html |
||||
* https://matrix.org/docs/spec/client_server/r0.4.0.html#id128 |
||||
|
||||
|
||||
### How does the homeserver know when to notify a client? |
||||
|
||||
This is defined by [**push rules**](https://matrix.org/docs/spec/client_server/r0.4.0.html#push-rules-). |
||||
|
||||
`A push rule is a single rule that states under what conditions an event should be passed onto a push gateway and how the notification should be presented (sound / importance).` |
||||
|
||||
A homeserver can be configured with default rules (for Direct messages, group messages, mentions, etc.. ). |
||||
|
||||
There are different kind of push rules, it can be per room (each new message on this room should be notified), it can also define a pattern that a message should match (when you are mentioned, or key word based). |
||||
|
||||
Notifications have 2 'levels' (`highlighted = true/false sound = default/custom`). In Element these notifications level are reflected as Noisy/Silent. |
||||
|
||||
**What about encrypted messages?** |
||||
|
||||
Of course, content patterns matching cannot be used for encrypted messages server side (as the content is encrypted). |
||||
|
||||
That is why clients are able to **process the push rules client side** to decide what kind of notification should be presented for a given event. |
||||
|
||||
### Push vs privacy, and mitigation |
||||
|
||||
As seen previously, App developers don't directly send a push to the end user's device, they use a Push Provider as intermediary. So technically this intermediary is able to read the content of what is sent. |
||||
|
||||
App developers usually mitigate this by sending a `silent notification`, that is a notification with no identifiable data, or with an encrypted payload. When the push is received the app can then synchronise to it's server in order to generate a local notification. |
||||
|
||||
|
||||
### Background processing limitations |
||||
|
||||
A mobile applications process live in a managed word, meaning that its process can be limited (e.g no network access), stopped or killed at almost anytime by the Operating System. |
||||
|
||||
In order to improve the battery life of their devices some constructors started to implement mechanism to drastically limit background execution of applications (e.g MIUI/Xiaomi restrictions, Sony stamina mode). |
||||
Then starting android M, android has also put more focus on improving device performances, introducing several IDLE modes, App-Standby, Light Doze, Doze. |
||||
|
||||
In a nutshell, apps can't do much in background now. |
||||
|
||||
If the devices is not plugged and stays IDLE for a certain amount of time, radio (mobile connectivity) and CPU can/will be turned off. |
||||
|
||||
For an application like Element, where users can receive important information at anytime, the best option is to rely on a push system (Google's Firebase Message a.k.a FCM). FCM high priority push can wake up the device and whitelist an application to perform background task (for a limited but unspecified amount of time). |
||||
|
||||
Notice that this is still evolving, and in future versions application that has been 'background restricted' by users won't be able to wake up even when a high priority push is received. Also high priority notifications could be rate limited (not defined anywhere) |
||||
|
||||
It's getting a lot more complicated when you cannot rely on FCM (because: closed sources, network/firewall restrictions, privacy concerns). |
||||
The documentation on this subject is vague, and as per our experiments not always exact, also device's behaviour is fragmented. |
||||
|
||||
It is getting more and more complex to have reliable notifications when FCM is not used. |
||||
|
||||
## Element Notification implementations |
||||
|
||||
### Requirements |
||||
|
||||
Element Android must work with and without FCM. |
||||
* The Element android app published on F-Droid do not rely on FCM (all related dependencies are not present) |
||||
* The Element android app published on google play rely on FCM, with a fallback mode when FCM registration has failed (e.g outdated or missing Google Play Services) |
||||
|
||||
### Foreground sync mode (Gplay and F-Droid) |
||||
|
||||
When in foreground, Element performs sync continuously with a timeout value set to 10 seconds (see HttpPooling). |
||||
|
||||
As this mode does not need to live beyond the scope of the application, and as per Google recommendation, Element uses the internal app resources (Thread and Timers) to perform the syncs. |
||||
|
||||
This mode is turned on when the app enters foreground, and off when enters background. |
||||
|
||||
In background, and depending on whether push is available or not, Element will use different methods to perform the syncs (Workers / Alarms / Service) |
||||
|
||||
### Push (FCM) received in background |
||||
|
||||
In order to enable Push, Element must first get a push token from the firebase SDK, then register a pusher with this token on the homeserver. |
||||
|
||||
When a message should be notified to a user, the user's homeserver notifies the registered `push gateway` for Element, that is [sygnal](https://github.com/matrix-org/sygnal) _- The reference implementation for push gateways -_ hosted by matrix.org. |
||||
|
||||
This sygnal instance is configured with the required FCM API authentication token, and will then use the FCM API in order to notify the user's device running Element. |
||||
|
||||
``` |
||||
Homeserver ----> Sygnal (configured for Element) ----> FCM ----> Element |
||||
``` |
||||
|
||||
The push gateway is configured to only send `(eventId,roomId)` in the push payload (for better [privacy](#push-vs-privacy-and-mitigation)). |
||||
|
||||
Element needs then to synchronise with the user's homeserver, in order to resolve the event and create a notification. |
||||
|
||||
As per [Google recommendation](https://android-developers.googleblog.com/2018/09/notifying-your-users-with-fcm.html), Element will then use the WorkManager API in order to trigger a background sync. |
||||
|
||||
**Google recommendations:** |
||||
> We recommend using FCM messages in combination with the WorkManager 1 or JobScheduler API |
||||
|
||||
> Avoid background services. One common pitfall is using a background service to fetch data in the FCM message handler, since background service will be stopped by the system per recent changes to Google Play Policy |
||||
|
||||
``` |
||||
Homeserver ----> Sygnal ----> FCM ----> Element |
||||
(Sync) ----> Homeserver |
||||
<---- |
||||
Display notification |
||||
``` |
||||
|
||||
**Possible outcomes** |
||||
|
||||
Upon reception of the FCM push, Element will perform a sync call to the homeserver, during this process it is possible that: |
||||
* Happy path, the sync is performed, the message resolved and displayed in the notification drawer |
||||
* The notified message is not in the sync. Can happen if a lot of things did happen since the push (`gappy sync`) |
||||
* The sync generates additional notifications (e.g an encrypted message where the user is mentioned detected locally) |
||||
* The sync takes too long and the process is killed before completion, or network is not reliable and the sync fails. |
||||
|
||||
Element implements several strategies in these cases (TODO document) |
||||
|
||||
### FCM Fallback mode |
||||
|
||||
It is possible that Element is not able to get a FCM push token. |
||||
Common errors (among several others) that can cause that: |
||||
* Google Play Services is outdated |
||||
* Google Play Service fails in someways with FCM servers (infamous `SERVICE_NOT_AVAILABLE`) |
||||
|
||||
If Element is able to detect one of this cases, it will notifies it to the users and when possible help him fix it via a dedicated troubleshoot screen. |
||||
|
||||
Meanwhile, in order to offer a minimal service, and as per Google's recommendation for background activities, Element will launch periodic background sync in order to stays in sync with servers. |
||||
|
||||
The fallback mode is impacted by all the battery life saving mechanism implemented by android. Meaning that if the app is not used for a certain amount of time (`App-Standby`), or the device stays still and unplugged (`Light Doze`) , the sync will become less frequent. |
||||
|
||||
And if the device stays unplugged and still for too long (`Doze Mode`), no background sync will be perform at all (the system's `Ignore Battery Optimization option` has no effect on that). |
||||
|
||||
Also the time interval between sync is elastic, controlled by the system to group other apps background sync request and start radio/cpu only once for all. |
||||
|
||||
Usually in this mode, what happen is when you take back your phone in your hand, you suddenly receive notifications. |
||||
|
||||
The fallback mode is supposed to be a temporary state waiting for the user to fix issues for FCM, or for App Developers that has done a fork to correctly configure their FCM settings. |
||||
|
||||
### F-Droid background Mode |
||||
|
||||
The F-Droid Element flavor has no dependencies to FCM, therefore cannot relies on Push. |
||||
|
||||
Also Google's recommended background processing method cannot be applied. This is because all of these methods are affected by IDLE modes, and will result on the user not being notified at all when the app is in a Doze mode (only in maintenance windows that could happens only after hours). |
||||
|
||||
Only solution left is to use `AlarmManager`, that offers new API to allow launching some process even if the App is in IDLE modes. |
||||
|
||||
Notice that these alarms, due to their potential impact on battery life, can still be restricted by the system. Documentation says that they will not be triggered more than every minutes under normal system operation, and when in low power mode about every 15 mn. |
||||
|
||||
These restrictions can be relaxed by requiring the app to be white listed from battery optimization. |
||||
|
||||
F-Droid version will schedule alarms that will then trigger a Broadcast Receiver, that in turn will launch a Service (in the classic android way), and the reschedule an alarm for next time. |
||||
|
||||
Depending on the system status (or device make), it is still possible that the app is not given enough time to launch the service, or that the radio is still turned off thus preventing the sync to success (that's why Alarms are not recommended for network related tasks). |
||||
|
||||
That is why on Element F-Droid, the broadcast receiver will acquire a temporary WAKE_LOCK for several seconds (thus securing cpu/network), and launch the service in foreground. The service performs the sync. |
||||
|
||||
Note that foreground services require to put a notification informing the user that the app is doing something even if not launched). |
||||
|
||||
## Application Settings |
||||
|
||||
**Notifications > Enable notifications for this account** |
||||
|
||||
Configure Sygnal to send or not notifications to all user devices. |
||||
|
||||
**Notifications > Enable notifications for this device** |
||||
|
||||
Disable notifications locally. The push server will continue to send notifications to the device but this one will ignore them. |
||||
|
||||
|
||||
@ -0,0 +1,290 @@
@@ -0,0 +1,290 @@
|
||||
# Pull requests |
||||
|
||||
<!--- TOC --> |
||||
|
||||
* [Introduction](#introduction) |
||||
* [Who should read this document?](#who-should-read-this-document?) |
||||
* [Submitting PR](#submitting-pr) |
||||
* [Who can submit pull requests?](#who-can-submit-pull-requests?) |
||||
* [Humans](#humans) |
||||
* [Draft PR?](#draft-pr?) |
||||
* [Base branch](#base-branch) |
||||
* [PR Review Assignment](#pr-review-assignment) |
||||
* [PR review time](#pr-review-time) |
||||
* [Re-request PR review](#re-request-pr-review) |
||||
* [When create split PR?](#when-create-split-pr?) |
||||
* [Avoid fixing other unrelated issue in a big PR](#avoid-fixing-other-unrelated-issue-in-a-big-pr) |
||||
* [Bots](#bots) |
||||
* [Dependabot](#dependabot) |
||||
* [Gradle wrapper](#gradle-wrapper) |
||||
* [Sync analytics plan](#sync-analytics-plan) |
||||
* [Reviewing PR](#reviewing-pr) |
||||
* [Who can review pull requests?](#who-can-review-pull-requests?) |
||||
* [What to have in mind when reviewing a PR](#what-to-have-in-mind-when-reviewing-a-pr) |
||||
* [Rules](#rules) |
||||
* [Check the form](#check-the-form) |
||||
* [PR title](#pr-title) |
||||
* [PR description](#pr-description) |
||||
* [File change](#file-change) |
||||
* [Check the commit](#check-the-commit) |
||||
* [Check the substance](#check-the-substance) |
||||
* [Make a dedicated meeting to review the PR](#make-a-dedicated-meeting-to-review-the-pr) |
||||
* [What happen to the issue(s)?](#what-happen-to-the-issues?) |
||||
* [Merge conflict](#merge-conflict) |
||||
* [When and who can merge PR](#when-and-who-can-merge-pr) |
||||
* [Merge type](#merge-type) |
||||
* [Resolve conversation](#resolve-conversation) |
||||
* [Responsibility](#responsibility) |
||||
|
||||
<!--- END --> |
||||
|
||||
## Introduction |
||||
|
||||
This document gives some clue about how to efficiently manage Pull Requests (PR). This document is a first draft and may be improved later. |
||||
|
||||
## Who should read this document? |
||||
|
||||
Every pull request reviewers, but also probably every ones who submit PRs. |
||||
|
||||
## Submitting PR |
||||
|
||||
### Who can submit pull requests? |
||||
|
||||
Basically every one who wants to contribute to the project! But there are some rules to follow. |
||||
|
||||
#### Humans |
||||
|
||||
People with write access to the project can directly clone the project, push their branches and create PR. |
||||
|
||||
External contributors must first fork the project and create PR to the mainline from there. |
||||
|
||||
##### Draft PR? |
||||
|
||||
Draft PR can be created when the submitter does not expect the PR to be reviewed and merged yet. It can be useful to publicly show the work, or to do a self-review first. |
||||
|
||||
Draft PR can also be created when it depends on other un-merged PR. |
||||
|
||||
In any case, it is better to explicitly declare in the description why the PR is a draft PR. |
||||
|
||||
Also, draft PR should not stay indefinitely in this state. It may be removed if it is the case and the submitter does not update it after a few days. |
||||
|
||||
##### Base branch |
||||
|
||||
The `develop` branch is generally the base branch for every PRs. |
||||
|
||||
Exceptions can occur: |
||||
|
||||
- if a feature implementation is split into multiple PRs. We can have a chain of PRs in this case. PR can be merged one by one on develop, and GitHub change the target branch to `develop` for the next PR automatically. |
||||
- we want to merge a PR from the community, but there is still work to do, and the PR is not updated by the submitter. First, we can kindly ask the submitter if they will update their PR, by commenting it. If there is no answer after a few days (including a week-end), we can create a new branch, push it, and change the target branch of the PR to this new branch. The PR can then be merged, and we can add more commits to fix the issues. After that a new PR can be created with `develop` as a target branch. |
||||
|
||||
**Important notice 1:** Releases are created from the `develop` branch. So `develop` branch should always contain a "releasable" source code. So when a feature is being implemented with several PRs, it has to be disabled by default (using a feature flag for instance), until the feature is fully implemented. A last PR to enable the feature can then be created. |
||||
|
||||
**Important notice 2:** Database migration: some developers and some people from the community are using the nightly build from `develop`. Multiple database migrations should be properly handled for them. This is OK to have multiple migrations between 2 releases, this is not OK to add steps to the pending database migration on `develop`. So for instance `develop` users will migrate from version 11 to version 12, then 13, then 14, and `main` users will do all those steps after they get the app upgrade. |
||||
|
||||
##### PR Review Assignment |
||||
|
||||
We use automatic assignment for PR reviews. **A PR is automatically routed by GitHub to one team member** using the round robin algorithm. Additional reviewers can be used for complex changes or when the first reviewer is not confident enough on the changes. |
||||
The process is the following: |
||||
|
||||
- The PR creator selects the [element-android-reviewers](https://github.com/orgs/vector-im/teams/element-android-reviewers) team as a reviewer. |
||||
- GitHub automatically assign the reviewer. If the reviewer is not available (holiday, etc.), remove them and set again the team, GitHub will select another reviewer. |
||||
- Alternatively, the PR creator can directly assign specific people if they have another Android developer in their team or they think a specific reviewer should take a look at their PR. |
||||
- Reviewers get a notification to make the review: they review the code following the good practice (see the rest of this document). |
||||
- After making their own review, if they feel not confident enough, they can ask another person for a full review, or they can tag someone within a PR comment to check specific lines. |
||||
|
||||
For PRs coming from the community, the issue wrangler can assign either the team [element-android-reviewers](https://github.com/orgs/vector-im/teams/element-android-reviewers) or any member directly. |
||||
|
||||
##### PR review time |
||||
|
||||
As a PR submitter, you deserve a quick review. As a reviewer, you should do your best to unblock others. |
||||
|
||||
Some tips to achieve it: |
||||
|
||||
- Set up your GH notifications correctly |
||||
- Check your pulls page: [https://github.com/pulls](https://github.com/pulls) |
||||
- Check your pending assigned PRs before starting or resuming your day to day tasks |
||||
- If you are busy with high priority tasks, inform the author. They will find another developer |
||||
|
||||
It is hard to define a deadline for a review. It depends on the PR size and the complexity. Let's start with a goal of 24h (working day!) for a PR smaller than 500 lines. If bigger, the submitter and the reviewer should discuss. |
||||
|
||||
After this time, the submitter can ping the reviewer to get a status of the review. |
||||
|
||||
##### Re-request PR review |
||||
|
||||
Once all the remarks have been handled, it's possible to re-request a review from the (same) reviewer to let them know that the PR has been updated the PR is ready to be reviewed again. Use the double arrow next to the reviewer name to do that. |
||||
|
||||
##### When create split PR? |
||||
|
||||
To implement big new feature, it may be efficient to split the work into several smaller and scoped PRs. They will be easier to review, and they can be merged on `develop` faster. |
||||
|
||||
Big PR can take time, and there is a risk of future merge conflict. |
||||
|
||||
Feature flag can be used to avoid half implemented feature to be available in the application. |
||||
|
||||
That said, splitting into several PRs should not have the side effect to have more review to do, for instance if some code is added, then finally removed. |
||||
|
||||
##### Avoid fixing other unrelated issue in a big PR |
||||
|
||||
Each PR should focus on a single task. If other issues may be fixed when working in the area of it, it's preferable to open a dedicated PR. |
||||
|
||||
It will have the advantage to be reviewed and merged faster, and not interfere with the main PR. |
||||
|
||||
It's also applicable for code rework (such as renaming for instance), or code formatting. Sometimes, it is more efficient to extract that work to a dedicated PR, and rebase your branch once this "rework" PR has been merged. |
||||
|
||||
#### Bots |
||||
|
||||
Some bots can create PR, but they still have to be reviewed by the team |
||||
|
||||
##### Dependabot |
||||
|
||||
Dependabot is a tool which maintain all our external dependencies up to date. A dedicated PR is created for each new available release for one of our external dependency.Dependabot |
||||
|
||||
To review such PR, you have to |
||||
- **IMPORTANT** check the diff files (as always). |
||||
- Check the release note. Some existing bugs in Element project may be fixed by the upgrade |
||||
- Make sure that the CI is happy |
||||
- If the code does not compile (API break for instance), you have to checkout the branch and push new commits |
||||
- Do some smoke test, depending of the library which has been upgraded |
||||
|
||||
For some reason dependabot sometimes does not upgrade some dependencies. In this case, and when detected, the upgrade has to be done manually. |
||||
|
||||
##### Gradle wrapper |
||||
|
||||
`Update Gradle Wrapper` is a tool which can create PR to upgrade our gradle.properties file. |
||||
Review such PR is the same recipe than for PR from Dependabot |
||||
|
||||
##### Sync analytics plan |
||||
|
||||
This tools imports any update in the analytics plan. See instruction in the PR itself to handle it. |
||||
More info can be found in the file [analytics.md](./analytics.md) |
||||
|
||||
## Reviewing PR |
||||
|
||||
### Who can review pull requests? |
||||
|
||||
As an open source project, every one can review each others PR. Of course an approval from internal developer is mandatory for a PR to be merged. |
||||
But comment in PR from the community are always appreciated! |
||||
|
||||
### What to have in mind when reviewing a PR |
||||
|
||||
1. User experience: is the UX and UI correct? You will probably be the second person to test the new thing, the first one is the developer. |
||||
2. Developer experience: does the code look nice and decoupled? No big functions, new classes added to the right module, etc. |
||||
3. Code maintenance. A bit similar to point 2. Tricky code must be documented for instance |
||||
4. Fork consideration. Will configuration of forks be easy? Some documentation may help in some cases. |
||||
5. We are building long term products. "Quick and dirty" code must be avoided. |
||||
6. The PR includes new tests for the added code, updated test for the existing code |
||||
7. All PRs from external contributors **MUST** include a sign-off. It's in the checklist, and sometimes it's checked by the submitter, but there is actually no sign-off. In this case, ask nicely for a sign-off and request changes (do not approve the PR, even if everything else is fine). |
||||
|
||||
### Rules |
||||
|
||||
#### Check the form |
||||
|
||||
##### PR title |
||||
|
||||
PR title should describe in one line what's brought by the PR. Reviewer can edit the title if it's not clear enough, or to add suffix like `[BLOCKED]` or similar. Fixing typo is also a good practice, since GitHub search is quite not efficient, so the words must be spelled without any issue. Adding suffix will help when viewing the PR list. |
||||
|
||||
It's free form, but prefix tags could also be used to help understand what's in the PR. |
||||
|
||||
Examples of prefixes: |
||||
- `[Refacto]` |
||||
- `[Feature]` |
||||
- `[Bugfix]` |
||||
- etc. |
||||
|
||||
Also, it's still possible to add labels to the PRs, such as `A-` or `T-` labels, even if this is not a strong requirement. We prefer to spend time to add labels on issues. |
||||
|
||||
##### PR description |
||||
|
||||
PR description should follow the PR template, and at least provide some context about the code change. |
||||
|
||||
##### File change |
||||
|
||||
1. Code should follow the guidelines |
||||
2. Code should be formatted correctly |
||||
3. XML attribute must be sorted |
||||
4. New code is added at the correct location |
||||
5. New classes are added to the correct location |
||||
6. Naming is correct. Naming is really important, it's considered part of the documentation |
||||
7. Architecture is followed. For instance, the logic is in the ViewModel and not in the Fragment |
||||
8. There is at least one file for the changelog. Exception if the PR fixes something which has not been released yet. Changelog content should target their audience: `.sdk` extension are mainly targeted for developers, other extensions are targeted for users and forks maintainers. It should generally describe visual change rather than give technical details. More details can be found [here](../CONTRIBUTING.md#changelog). |
||||
9. PR includes tests. allScreensTest when applicable, and unit tests |
||||
10. Avoid over complicating things. Keep it simple (KISS)! |
||||
11. PR contains only the expected change. Sometimes, the diff is showing changes that are already on `develop`. This is not good, submitter has to fix that up. |
||||
|
||||
##### Check the commit |
||||
|
||||
Commit message must be short, one line and valuable. "WIP" is not a good commit message. Commit message can contain issue number, starting with `#`. GitHub will add some link between the issue and such commit, which can be useful. It's possible to change a commit message at any time (may require a force push). |
||||
|
||||
Commit messages can contain extra lines with more details, links, etc. But keep in mind that those lines are quite less visible than the first line. |
||||
|
||||
Also commit history should be nice. Having commits like "Adding temporary code" then later "Removing temporary code" is not good. The branch has to be rebased and those commit have to be dropped. |
||||
|
||||
PR merger could decide to squash and merge if commit history is not good. |
||||
|
||||
Commit like "Code review fixes" is good when reviewing the PR, since new changes can be reviewed easily, but is less valuable when looking at git history. To avoid this, PR submitter should always push new commits after a review (no commit amend with force push), and when the PR is approved decide to interactive rebase the PR to improve the git history and reduce noise. |
||||
|
||||
##### Check the substance |
||||
|
||||
1. Test the changes! |
||||
2. Test the nominal case and the edge cases |
||||
3. Run the sanity test for critical PR |
||||
|
||||
##### Make a dedicated meeting to review the PR |
||||
|
||||
Sometimes a big PR can be hard to review. Setting up a call with the PR submitter can speed up the communication, rather than putting comments and questions in GitHub comments. It has the inconvenience of making the discussion non-public, consider including a summary of the main points of the "offline" conversation in the PR. |
||||
|
||||
### What happen to the issue(s)? |
||||
|
||||
The issue(s) should be referenced in the PR description using keywords like `Closes` of `Fixes` followed by the issue number. |
||||
|
||||
Example: |
||||
> Closes #1 |
||||
|
||||
Note that you have to repeat the keyword in case of a list of issue |
||||
|
||||
> Closes #1, Closes #2, etc. |
||||
|
||||
When PR will be merged, such referenced issue will be automatically closed. |
||||
It is up to the person who has merged the PR to go to the (closed) issue(s) and to add a comment to inform in which version the issue fix will be available. Use the current version of `develop` branch. |
||||
|
||||
> Closed in Element Android v1.x.y |
||||
|
||||
### Merge conflict |
||||
|
||||
It's up to the submitter to handle merge conflict. Sometimes, they can be fixed directly from GitHub, sometimes this is not possible. The branch can be rebased on `develop`, or the `develop` branch can be merged on the branch, it's up to the submitter to decide what is best. |
||||
Keep in mind that Github Actions are not run in case of conflict. |
||||
|
||||
### When and who can merge PR |
||||
|
||||
PR can be merged by the submitter, if and only if at least one approval from another developer is done. Approval from all people added as reviewer is also a good thing to have. Approval from design team may be mandatory, but is not sufficient to merge a PR. |
||||
|
||||
PR can also be merged by the reviewer, to reduce the time the PR is open. But only if the PR is not in draft and the change are quite small, or behind a feature flag. |
||||
|
||||
Dangerous PR should not be merged just before a release. Dangerous PR are PR that could break the app. Update of Realm library, rework in the chunk of Events management in the SDK, etc. |
||||
|
||||
We prefer to merge such PR after a release so that it can be tested during several days by the team before behind included in a release candidate. |
||||
|
||||
PR from bots will always be merged by the reviewer, right after approving the changes, or in case of critical changes, right after a release. |
||||
|
||||
#### Merge type |
||||
|
||||
Generally we use "Create a merge commit", which has the advantage to keep the branch visible. |
||||
|
||||
If git history is noisy (code added, then removed, etc.), it's possible to use "Squash and merge". But the branch will not be visible anymore, a commit will be added on top of develop. Git commit message can (and probably must) be edited from the GitHub web app. It's better if the submitter do the work to cleanup the git history by using a git interactive rebase of their branch. |
||||
|
||||
### Resolve conversation |
||||
|
||||
Generally we do not close conversation added during PR review and update by clicking on "Resolve conversation" |
||||
If the submitter or the reviewer do so, it will more difficult for further readers to see again the content. They will have to open the conversation to see it again. it's a waste of time. |
||||
|
||||
When remarks are handled, a small comment like "done" is enough, commit hash can also be added to the conversation. |
||||
|
||||
Exception: for big PRs with lots of conversations, using "Resolve conversation" may help to see the remaining remarks. |
||||
|
||||
Also "Resolve conversation" should probably be hit by the creator of the conversation. |
||||
|
||||
## Responsibility |
||||
|
||||
PR submitter is responsible of the incoming change. PR reviewers who approved the PR take a part of responsibility on the code which will land to develop, and then be used by our users, and the user of our forks. |
||||
|
||||
That said, bug may still be merged on `develop`, this is still acceptable of course. In this case, please make sure an issue is created and correctly labelled. Ideally, such issues should be fixed before the next release candidate, i.e. with a higher priority. But as we release the application every 10 working days, it can be hard to fix every bugs. That's why PR should be fully tested and reviewed before being merge and we should never comment code review remark with "will be handled later", or similar comments. |
||||
@ -0,0 +1,72 @@
@@ -0,0 +1,72 @@
|
||||
# Screenshot testing |
||||
|
||||
<!--- TOC --> |
||||
|
||||
* [Overview](#overview) |
||||
* [Setup](#setup) |
||||
* [Recording](#recording) |
||||
* [Verifying](#verifying) |
||||
* [Contributing](#contributing) |
||||
* [Example](#example) |
||||
|
||||
<!--- END --> |
||||
|
||||
## Overview |
||||
|
||||
- Screenshot tests are tests which record the content of a rendered screen and verify subsequent runs to check if the screen renders differently. |
||||
- Element uses [Paparazzi](https://github.com/cashapp/paparazzi) to render, record and verify android layouts. |
||||
- The screenshot verification occurs on every pull request as part of the `tests.yml` workflow. |
||||
|
||||
## Setup |
||||
|
||||
- Install Git LFS through your package manager of choice (`brew install git-lfs` | `yay -S git-lfs`). |
||||
- Install the Git LFS hooks into the project. |
||||
|
||||
```bash |
||||
# with element-android as the current working directory |
||||
git lfs install --local |
||||
``` |
||||
|
||||
- If installed correctly, `git push` and `git pull` will now include LFS content. |
||||
|
||||
## Recording |
||||
|
||||
- `./gradlew recordScreenshots` |
||||
- Paparazzi will generate images in `${module}/src/test/snapshots`, which will need to be committed to the repository using Git LFS. |
||||
|
||||
## Verifying |
||||
|
||||
- `./gradlew verifyScreenshots` |
||||
- In the case of failure, Paparazzi will generate images in `${module}/out/failure`. The images will show the expected and actual screenshots along with a delta of the two images. |
||||
|
||||
## Contributing |
||||
|
||||
- When creating a test, the file (and class) name names must include `ScreenshotTest`, eg `ItemScreenshotTest`. |
||||
- After creating the new test, record and commit the newly rendered screens. |
||||
- `./tools/validate_lfs` can be ran to ensure everything is working correctly with Git LFS, the CI also runs this check. |
||||
|
||||
## Example |
||||
|
||||
```kotlin |
||||
class PaparazziExampleScreenshotTest { |
||||
|
||||
@get:Rule |
||||
val paparazzi = Paparazzi( |
||||
deviceConfig = PIXEL_3, |
||||
theme = "Theme.Vector.Light", |
||||
) |
||||
|
||||
@Test |
||||
fun `example paparazzi test`() { |
||||
// Inflate the layout |
||||
val view = paparazzi.inflate<ConstraintLayout>(R.layout.item_radio) |
||||
|
||||
// Bind data to the view |
||||
view.findViewById<TextView>(R.id.actionTitle).text = paparazzi.resources.getString(R.string.room_settings_all_messages) |
||||
view.findViewById<ImageView>(R.id.radioIcon).setImageResource(R.drawable.ic_radio_on) |
||||
|
||||
// Record the bound view |
||||
paparazzi.snapshot(view) |
||||
} |
||||
} |
||||
``` |
||||
@ -0,0 +1,193 @@
@@ -0,0 +1,193 @@
|
||||
# Automate user interface tests |
||||
|
||||
Element Android ensures that some fundamental flows are properly working by running automated user interface tests. |
||||
Ui tests are using the android [Espresso](https://developer.android.com/training/testing/espresso) library. |
||||
|
||||
Tests can be run on a real device, or on a virtual device (such as the emulator in Android Studio). |
||||
|
||||
Currently the test are covering a small set of application flows: |
||||
- Registration |
||||
- Self verification via emoji |
||||
- Self verification via passphrase |
||||
|
||||
<!--- TOC --> |
||||
|
||||
* [Prerequisites:](#prerequisites:) |
||||
* [Run the tests](#run-the-tests) |
||||
* [From the source code](#from-the-source-code) |
||||
* [From command line](#from-command-line) |
||||
* [Recipes](#recipes) |
||||
* [Wait for initial sync](#wait-for-initial-sync) |
||||
* [Accessing current activity](#accessing-current-activity) |
||||
* [Interact with other session](#interact-with-other-session) |
||||
* [Contributing to the UiAllScreensSanityTest](#contributing-to-the-uiallscreenssanitytest) |
||||
|
||||
<!--- END --> |
||||
|
||||
## Prerequisites: |
||||
|
||||
Out of the box, the tests use one of the homeservers (located at http://localhost:8080) of the "Demo Federation of Homeservers" (https://github.com/matrix-org/synapse#running-a-demo-federation-of-synapses). |
||||
|
||||
You first need to follow instructions to set up Synapse in development mode at https://github.com/matrix-org/synapse#synapse-development. If you have already installed all dependencies, the steps are: |
||||
|
||||
```shell script |
||||
$ git clone https://github.com/matrix-org/synapse.git |
||||
$ cd synapse |
||||
$ virtualenv -p python3 env |
||||
$ source env/bin/activate |
||||
(env) $ python -m pip install --no-use-pep517 -e . |
||||
``` |
||||
|
||||
Every time you want to launch these test homeservers, type: |
||||
|
||||
```shell script |
||||
$ source env/bin/activate |
||||
(env) $ demo/start.sh --no-rate-limit |
||||
``` |
||||
|
||||
**Emulator/Device set up** |
||||
|
||||
When running the test via android studio on a device, you have to disable system animations in order for the test to work properly. |
||||
|
||||
First, ensure developer mode is enabled: |
||||
|
||||
- To enable developer options, tap the **Build Number** option 7 times. You can find this option in one of the following locations, depending on your Android version: |
||||
|
||||
- Android 9 (API level 28) and higher: **Settings > About Phone > Build Number** |
||||
- Android 8.0.0 (API level 26) and Android 8.1.0 (API level 26): **Settings > System > About Phone > Build Number** |
||||
- Android 7.1 (API level 25) and lower: **Settings > About Phone > Build Number** |
||||
|
||||
On your device, under **Settings > Developer options**, disable the following 3 settings: |
||||
|
||||
- Window animation scale |
||||
- Transition animation scale |
||||
- Animator duration scale |
||||
|
||||
## Run the tests |
||||
|
||||
Once Synapse is running, and an emulator is running, you can run the UI tests. |
||||
|
||||
### From the source code |
||||
|
||||
Click on the green arrow in front of each test. Clicking on the arrow in front of the test class, or from the package directory does not always work (Tests not found issue). |
||||
|
||||
### From command line |
||||
|
||||
````shell script |
||||
./gradlew vector:connectedGplayDebugAndroidTest |
||||
```` |
||||
|
||||
To run all the tests from the `vector` module. |
||||
|
||||
In case of trouble, you can try to uninstall the previous installed test APK first with this command: |
||||
|
||||
```shell script |
||||
adb uninstall im.vector.app.debug.test |
||||
``` |
||||
## Recipes |
||||
|
||||
We added some specific Espresso IdlingResources, and other utilities for matrix related tests |
||||
|
||||
### Wait for initial sync |
||||
|
||||
```kotlin |
||||
// Wait for initial sync and check room list is there |
||||
withIdlingResource(initialSyncIdlingResource(uiSession)) { |
||||
onView(withId(R.id.roomListContainer)) |
||||
.check(matches(isDisplayed())) |
||||
} |
||||
``` |
||||
|
||||
### Accessing current activity |
||||
|
||||
```kotlin |
||||
val activity = EspressoHelper.getCurrentActivity()!! |
||||
val uiSession = (activity as HomeActivity).activeSessionHolder.getActiveSession() |
||||
``` |
||||
|
||||
### Interact with other session |
||||
|
||||
It's possible to create a session via the SDK, and then use this session to interact with the one that the emulator is using (to check verifications for example) |
||||
|
||||
```kotlin |
||||
@Before |
||||
fun initAccount() { |
||||
val context = InstrumentationRegistry.getInstrumentation().targetContext |
||||
val matrix = Matrix.getInstance(context) |
||||
val userName = "foobar_${System.currentTimeMillis()}" |
||||
existingSession = createAccountAndSync(matrix, userName, password, true) |
||||
} |
||||
``` |
||||
|
||||
### Contributing to the UiAllScreensSanityTest |
||||
|
||||
The `UiAllScreensSanityTest` makes use of the Robot pattern in order to model pages, components and interactions. |
||||
Each Robot aims to return the UI back to its original state after the interaction, allowing for a reusable and consistent DSL. |
||||
|
||||
```kotlin |
||||
// launches and closes settings after executing the block |
||||
elementRobot.settings { |
||||
// whilst in the settings, launches and closes the advanced settings sub screen |
||||
advancedSettings { |
||||
// crawls all the pages within the advanced settings |
||||
crawl() |
||||
} |
||||
} |
||||
|
||||
// enables developer mode by navigating to the settings, enabling the toggle and then returning to the starting point to execute the block |
||||
// on block completion the Robot disables developer mode by navigating back to the settings and finally returning to the original starting point |
||||
elementRobot.withDeveloperMode { |
||||
// the same starting point as the example above |
||||
settings { |
||||
advancedSettings { crawlDeveloperOptions() } |
||||
} |
||||
} |
||||
``` |
||||
|
||||
The Robots used in the example above... |
||||
|
||||
```kotlin |
||||
class ElementRobot { |
||||
fun settings(block: SettingsRobot.() -> Unit) { |
||||
// double check we're where we think we are |
||||
waitUntilViewVisible(withId(R.id.bottomNavigationView)) |
||||
|
||||
// navigate to the settings |
||||
openDrawer() |
||||
clickOn(R.id.homeDrawerHeaderSettingsView) |
||||
|
||||
// execute the robot with the context of the settings screen |
||||
block(SettingsRobot()) |
||||
|
||||
// close the settings and ensure we're back at the starting point |
||||
pressBack() |
||||
waitUntilViewVisible(withId(R.id.bottomNavigationView)) |
||||
} |
||||
|
||||
fun withDeveloperMode(block: ElementRobot.() -> Unit) { |
||||
settings { toggleDeveloperMode() } |
||||
block() |
||||
settings { toggleDeveloperMode() } |
||||
} |
||||
} |
||||
|
||||
class SettingsRobot { |
||||
fun toggleDeveloperMode() { |
||||
advancedSettings { |
||||
toggleDeveloperMode() |
||||
} |
||||
} |
||||
|
||||
fun advancedSettings(block: SettingsAdvancedRobot.() -> Unit) { |
||||
clickOn(R.string.settings_advanced_settings) |
||||
block(SettingsAdvancedRobot()) |
||||
pressBack() |
||||
} |
||||
} |
||||
|
||||
class SettingsAdvancedRobot { |
||||
fun toggleDeveloperMode() { |
||||
clickOn(R.string.settings_developer_mode_summary) |
||||
} |
||||
} |
||||
``` |
||||
@ -0,0 +1,351 @@
@@ -0,0 +1,351 @@
|
||||
# Table of Contents |
||||
|
||||
<!--- TOC --> |
||||
|
||||
* [Overview](#overview) |
||||
* [Best Practices](#best-practices) |
||||
* [Project Conventions](#project-conventions) |
||||
* [Setup](#setup) |
||||
* [Naming](#naming) |
||||
* [Format](#format) |
||||
* [Assertions](#assertions) |
||||
* [Constants](#constants) |
||||
* [Mocking](#mocking) |
||||
* [Fakes](#fakes) |
||||
* [Fixtures](#fixtures) |
||||
* [Examples](#examples) |
||||
* [Extensions used to streamline the test setup](#extensions-used-to-streamline-the-test-setup) |
||||
* [Fakes and Fixtures](#fakes-and-fixtures) |
||||
|
||||
<!--- END --> |
||||
|
||||
## Overview |
||||
|
||||
Unit tests are a mechanism to validate our code executes the way we expect. They help to inform the design of our systems by requiring testability and |
||||
understanding, they describe the inner workings without relying on inline comments and protect from unexpected regressions. |
||||
|
||||
However, unit tests are not a magical solution to solve all our problems and come at a cost. Unreliable and hard to maintain tests often end up ignored, deleted |
||||
or worse, provide a false sense of security. |
||||
|
||||
### Best Practices |
||||
|
||||
Tests can be written in many ways, the main rule is to keep them simple and maintainable. Some ways to help achieve this are... |
||||
|
||||
- Break out logic into single units (following the Single Responsibility Principle) to reduce test complexity. |
||||
- Favour pure functions, avoiding mutable state. |
||||
- Prefer dependency injection to static calls to allow for simpler test setup. |
||||
- Write concise tests with a single function under test, clearly showing the inputs and expected output. |
||||
- Create separate test cases instead of changing parameters and grouping multiple assertions within a single test to help trace back failure causes (with the |
||||
exception of parameterised tests). |
||||
- Assert against entire models instead of subsets of properties to capture any possible changes within the test scope. |
||||
- Avoid invoking logic from production instances other than the class under test to guard from unrelated changes. |
||||
- Always inject `Dispatchers` and `Clock` instances and provide fake implementations for tests to avoid non deterministic results. |
||||
|
||||
## Project Conventions |
||||
|
||||
#### Setup |
||||
|
||||
- Test file and class name should be the class under test with the Test suffix, created in a `test` sourceset, with the same package name as the class under |
||||
test. |
||||
- Dependencies of the class are instantiated inline, junit will recreate the test class for each test run. |
||||
- A line break between the dependencies and class under test helps clarify the instance being tested. |
||||
|
||||
```kotlin |
||||
|
||||
class MyClassTest { |
||||
|
||||
private val fakeUppercaser = FakeUppercaser() |
||||
|
||||
// line break between the class under test and its dependencies |
||||
private val myClass = MyClass(fakeUppercaser.instance) |
||||
} |
||||
|
||||
``` |
||||
|
||||
#### Naming |
||||
|
||||
- Test names use the `Gherkin` format, `given, when, then` mapping to the input, logic under test and expected result. |
||||
- `given` - Uniqueness about the environment or dependencies in which the test case is running. _"given device is android 12 and supports dark mode"_ |
||||
- `when` - The action/function under test. _"when reading dark mode status"_ |
||||
- `then` - The expected result from the combination of _given_ and _when_. _"then returns dark mode enabled"_ |
||||
- Test names are written using kotlin back ticks to enable sentences _ish_. |
||||
|
||||
```kotlin |
||||
@Test |
||||
fun `given a lowercase label, when uppercasing, then returns label uppercased` |
||||
``` |
||||
|
||||
When the input is given directly to the _when_, this can also be represented as... |
||||
|
||||
```kotlin |
||||
@Test |
||||
fun `when uppercasing a lowercase label, then returns label uppercased` |
||||
``` |
||||
|
||||
Multiple given or returns statements can be used in the name although it could be a sign that the logic being tested does too much. |
||||
|
||||
--- |
||||
|
||||
#### Format |
||||
|
||||
- Test bodies are broken into sections through the use of blank lines where the sections correspond to the test name. |
||||
- Sections can span multiple lines. |
||||
|
||||
```kotlin |
||||
// comments are for illustrative purposes |
||||
/* given */ val lowercaseLabel = "hello world" |
||||
|
||||
/* when */ val result = textUppercaser.uppercase(lowercaseLabel) |
||||
|
||||
/* then */ result shouldBeEqualTo "HELLO WORLD" |
||||
``` |
||||
|
||||
- Functions extracted from test bodies are placed beneath all the unit tests. |
||||
|
||||
--- |
||||
|
||||
#### Assertions |
||||
|
||||
- Assertions against test results are made using [Kluent's](https://github.com/MarkusAmshove/Kluent) _fluent_ api. |
||||
- Typically `shouldBeEqualTo`is the main assertion to use for asserting function return values as by project convention we assert against entire objects or |
||||
lists. |
||||
|
||||
```kotlin |
||||
val result = listOf("hello", "world") |
||||
|
||||
// Fail |
||||
result shouldBeEqualTo listOf("hello") |
||||
``` |
||||
|
||||
```kotlin |
||||
data class Person(val age: Int, val name: String) |
||||
|
||||
val result = Person(age = 100, name = "Gandalf") |
||||
|
||||
// Avoid |
||||
result.age shouldBeEqualTo 100 |
||||
|
||||
// Prefer |
||||
result shouldBeEqualTo Person(age = 100, "Gandalf") |
||||
``` |
||||
|
||||
- Exception throwing can be asserted against using `assertFailsWith<T : Throwable>`. |
||||
- When asserting reusable exceptions, include the message to distinguish between them. |
||||
|
||||
```kotlin |
||||
assertFailsWith<ConcreteException>(message = "Details about error") { |
||||
// when section of the test |
||||
codeUnderTest() |
||||
} |
||||
``` |
||||
|
||||
--- |
||||
|
||||
#### Constants |
||||
|
||||
- Reusable values are extracted to file level immutable properties or constants. |
||||
- These can be parameters or expected results. |
||||
- The naming convention is to prefix with `A` or `AN` for better matching with the test name. |
||||
|
||||
```kotlin |
||||
private const val A_LOWERCASE_LABEL = "hello" |
||||
|
||||
class MyTest { |
||||
@Test |
||||
fun `when uppercasing a lowercase label, then returns label uppercased`() { |
||||
val result = TextUppercaser().uppercase(A_LOWERCASE_LABEL) |
||||
... |
||||
} |
||||
} |
||||
``` |
||||
|
||||
--- |
||||
|
||||
#### Mocking |
||||
|
||||
- In order to provide different behaviour for dependencies within tests our main method is through mocking, using [Mockk](https://mockk.io/). |
||||
- We avoid using relaxed mocks in favour of explicitly declaring mock behaviour through the _Fake_ convention. There are exceptions when mocking framework |
||||
classes which would require a lot of boilerplate. |
||||
- Using `Spy` is discouraged as it inherently requires real instances, which we are avoiding in our tests. There are exceptions such as `VectorFeatures` which |
||||
acts like a `Fixture` in release builds. |
||||
|
||||
--- |
||||
|
||||
#### Fakes |
||||
|
||||
- Fakes are reusable instances of classes purely for testing purposes. They provide functions to replace the functions of the interface/class they're faking |
||||
with test specific values. |
||||
- When faking an interface, the _Fake_ can be written using delegation or by stubbing |
||||
- All Fakes currently reside in the same package `${package}.test.fakes` |
||||
|
||||
```kotlin |
||||
// Delegating to a mock |
||||
class FakeClock : Clock by mockk() { |
||||
fun givenEpoch(epoch: Long) { |
||||
every { epochMillis() } returns epoch |
||||
} |
||||
} |
||||
|
||||
// Stubbing the interface |
||||
class FakeClock(private val epoch: Long) : Clock { |
||||
override fun epochMillis() = epoch |
||||
} |
||||
``` |
||||
|
||||
It's currently more common for fakes to fake class behaviour, we achieve this by wrapping and exposing a mock instance. |
||||
|
||||
```kotlin |
||||
class FakeCursor { |
||||
val instance = mockk<Cursor>() |
||||
fun givenEmpty() { |
||||
every { instance.count } returns 0 |
||||
every { instance.moveToFirst() } returns false |
||||
} |
||||
} |
||||
|
||||
val fakeCursor = FakeCursor().apply { givenEmpty() } |
||||
``` |
||||
|
||||
#### Fixtures |
||||
|
||||
- Fixtures are a reusable wrappers around data models. They provide default values to make creating instances as easy as possible, with the option to override |
||||
specific parameters when needed. |
||||
- Are namespaced within an `object`. |
||||
- Reduces the _find usages_ noise when searching for usages of the origin class construction. |
||||
- All Fixtures currently reside in the same package `${package}.test.fixtures`. |
||||
|
||||
```kotlin |
||||
object ContentAttachmentDataFixture { |
||||
fun aContentAttachmentData( |
||||
type: ContentAttachmentData.Type.TEXT, |
||||
mimeType: String? = null |
||||
) = ContentAttachmentData(type, mimeType) |
||||
} |
||||
``` |
||||
|
||||
- Fixtures can also be used to manage specific combinations of parameters |
||||
|
||||
```kotlin |
||||
fun aContentAttachmentAudioData() = aContentAttachmentData( |
||||
type = ContentAttachmentData.Type.AUDIO, |
||||
mimeType = "audio/mp3", |
||||
) |
||||
``` |
||||
|
||||
--- |
||||
|
||||
### Examples |
||||
|
||||
##### Extensions used to streamline the test setup |
||||
|
||||
```kotlin |
||||
class CircularCacheTest { |
||||
|
||||
@Test |
||||
fun `when putting more than cache size then cache is limited to cache size`() { |
||||
val (cache, internalData) = createIntCache(cacheSize = 3) |
||||
|
||||
cache.putInOrder(1, 1, 1, 1, 1, 1) |
||||
|
||||
internalData shouldBeEqualTo arrayOf(1, 1, 1) |
||||
} |
||||
} |
||||
|
||||
private fun createIntCache(cacheSize: Int): Pair<CircularCache<Int>, Array<Int?>> { |
||||
var internalData: Array<Int?>? = null |
||||
val factory: (Int) -> Array<Int?> = { |
||||
Array<Int?>(it) { null }.also { array -> internalData = array } |
||||
} |
||||
return CircularCache(cacheSize, factory) to internalData!! |
||||
} |
||||
|
||||
private fun CircularCache<Int>.putInOrder(vararg values: Int) { |
||||
values.forEach { put(it) } |
||||
} |
||||
``` |
||||
|
||||
##### Fakes and Fixtures |
||||
|
||||
```kotlin |
||||
class LateInitUserPropertiesFactoryTest { |
||||
|
||||
private val fakeActiveSessionDataSource = FakeActiveSessionDataSource() |
||||
private val fakeVectorStore = FakeVectorStore() |
||||
private val fakeContext = FakeContext() |
||||
private val fakeSession = FakeSession().also { |
||||
it.givenVectorStore(fakeVectorStore.instance) |
||||
} |
||||
|
||||
private val lateInitUserProperties = LateInitUserPropertiesFactory( |
||||
fakeActiveSessionDataSource.instance, |
||||
fakeContext.instance |
||||
) |
||||
|
||||
@Test |
||||
fun `given no active session, when creating properties, then returns null`() { |
||||
val result = lateInitUserProperties.createUserProperties() |
||||
|
||||
result shouldBeEqualTo null |
||||
} |
||||
|
||||
@Test |
||||
fun `given a teams use case set on an active session, when creating properties, then includes the remapped WorkMessaging selection`() { |
||||
fakeVectorStore.givenUseCase(FtueUseCase.TEAMS) |
||||
fakeActiveSessionDataSource.setActiveSession(fakeSession) |
||||
|
||||
val result = lateInitUserProperties.createUserProperties() |
||||
|
||||
result shouldBeEqualTo UserProperties( |
||||
ftueUseCaseSelection = UserProperties.FtueUseCaseSelection.WorkMessaging |
||||
) |
||||
} |
||||
} |
||||
``` |
||||
|
||||
##### ViewModel |
||||
|
||||
- `ViewModels` tend to be one of the most complex areas to unit test due to their position as a coordinator of data flows and bridge between domains. |
||||
- As the project uses a slightly tweaked`MvRx`, our API for the `ViewModel` is simplified down to `input - ViewModel.handle(Action)` |
||||
and `output Flows - ViewModel.viewEvents & ViewModel.stateFlow`. A `ViewModel` test asserter has been created to further simplify the process. |
||||
|
||||
```kotlin |
||||
class ViewModelTest { |
||||
|
||||
private var initialState = ViewState.Empty |
||||
|
||||
@get:Rule |
||||
val mavericksTestRule = MavericksTestRule(testDispatcher = UnconfinedTestDispatcher()) |
||||
|
||||
@Test |
||||
fun `when handling MyAction, then emits Loading and Content states`() { |
||||
val viewModel = ViewModel<State>(initialState) |
||||
val test = viewModel.test() // must be invoked before interacting with the VM |
||||
|
||||
viewModel.handle(MyAction) |
||||
|
||||
test |
||||
.assertViewStates(initialState, State.Loading, State.Content()) |
||||
.assertNoEvents() |
||||
.finish() |
||||
} |
||||
} |
||||
``` |
||||
|
||||
- `ViewModels` often emit multiple states which are copies of the previous state, the `test` extension `assertStatesChanges` allows only the difference to be |
||||
supplied. |
||||
|
||||
```kotlin |
||||
data class ViewState(val name: String? = null, val age: Int? = null) |
||||
val initialState = ViewState() |
||||
val viewModel = ViewModel<State>(initialState) |
||||
val test = viewModel.test() |
||||
|
||||
viewModel.handle(ChangeNameAction("Gandalf")) |
||||
|
||||
test |
||||
.assertStatesChanges( |
||||
initialState, |
||||
{ copy(name = "Gandalf") }, |
||||
) |
||||
.finish() |
||||
``` |
||||
Loading…
Reference in new issue