Using flutter_webrtc library create an application for audio/video calls between two users.

Application should work on Android platform.

Design | Prototype

This is a GitHub template repository, so you need to click on Use this template button above and do all the development in your own repository which uses this one as template only.

1. Display video and play audio of a partner participant.
2. Publish video from the frontal camera of a device.
3. Publishing user's audio.
4. Preview of the published video.
5. Ability to enable/disabled published video/audio.

1. Code should be documented with dartdoc and the generated documentation should be available on GitHub Pages.
2. Code should be covered with unit tests.
3. E2E (end-to-end) tests should cover all the required features.

For signaling between clients you may use simple WebSocket server provided within this project (or write your own). Messages sent to this server, will be broadcast to the all other clients connected to the same server without any changes. It's up to you to define the format of messages.

1. Create account on Heroku (if you don't have one).
2. Copy Heroku API key from the account page.
3. Go to Actions Secrets settings in your GitHub repository.
4. Add the following repository keys:
   • HEROKU_API_KEY - API key which you copied at step 2;
   • HEROKU_EMAIL - email with which you registered on Heroku.
5. Go to 'Deploy signaling server to Heroku' GitHub workflow.
6. Run workflow on master branch.

Now your instance of a signaling server can be accessed at wss://flutter-sandbox-{{ YOUR GITHUB USERNAME }}.herokuapp.com.

1. Alice initiates a WebSocket connection on wss://flutter-sandbox-ferris.herokuapp.com endpoint.
2. Bob initiates a WebSocket connection on wss://flutter-sandbox-ferris.herokuapp.com endpoint.
3. Alice sends message with text Hello Bob.
4. Bob receives message with text Hello Bob.
5. Bob sends message with text Hello Alice.
6. Alice receives message with text Hello Alice.

Use stun:stun.stunprotocol.org:3478 and stun:stun.l.google.com:19302 as ICE servers in your application.

To release your application run make release command.

Or you can do it manually:

$ git tag -d latest
$ git tag latest
$ git push origin latest --force 

CI will build your application and create a release on GitHub with .apk built automatically.

Once you finish the development, release the application to GitHub as described in the previous section.

Firstly, you should demonstrate that application can make calls between devices and disabling/enabling audio/video works correctly.

At the end, your application should be able to make video call with a reviewer.

Please, before demonstration make sure that your Heroku instance is not sleeping.

All the assets required for this application are located in the assets/ directory.

Final design of the implemented application may vary from the provided one. The provided design aims only to explain the expected result better.

• Basics of WebRTC
• Basic WebRTC glossary
• Basics of WebRTC signaling
• WebRTC glossary
• Flutter WebRTC usage examples
• Flutter WebRTC demo
• Dead simple WebRTC example written with JS

Repository must NOT contain (so have them Git-ignored to avoid accidents):

• configuration files of developer's local toolchain (unless this configuration is suitable for all project developers);
• compilation/build results/artifacts of source code;
• any caches or temporary files;
• configuration files for running application (except examples or Dockerized development environment configurations which are the same for all project developers).

For keeping an empty directory in a repository use the .gitkeep file inside that directory.

Start directory with . if it contains some temporary files which do not require direct manipulations and are going to be omitted by tools (caches, temp files, etc.). This is a quite common practice (see .git/, .idea/, .gradle/, etc.).
Also, all temporary cache files must be placed inside a .cache/ top-level directory of the repository, unless this is impossible for somewhat reasons.

To emphasize toolchain directories (ones which do not contain project sources itself, but rather contain files of a project toolchain) their name may be started with _, which will make them to "bubble-up" in a repository source tree, so will allow easily to distinguish them from actual project sources (both for humans and tools).

Every repository contains the following branches:

• master - mainline version of the project. Any new project release is usually created from this branch. Developing directly in this branch is forbidden. It accepts new changes via PRs (pull requests).

Any other possible branches and tags can be created and used by developers as they need.

Git branch name must meet the following requirements:

• consist of English words;
  👍 fix-tests-failure
  🚫 fix-defectum-probat
• use only dashes to separate words;
  👍 fix-tests-failure
  🚫 fix_tests_failure
• use imperative mood for verbs;
  👍 fix-tests-failure
  🚫 fixes-tests-failure
• start with the issue number when branch is related to some issue (but DO NOT use PR (pull request) numbers);
  👍 23-fix-tests-failure
  🚫 fix-tests-failure
• reflect the meaning of branch changes, not the initial problem.
  👍 23-fix-tests-failure
  🚫 23-problem-with-failing-tests

Every commit message must contain a short description of its changes that meet the following requirements:

• be on English (no other language is allowed);
• start with a capital letter;
• has no punctuation symbols at the end (like ;, : or .);
• use imperative mood for verbs (as if you are commanding someone: Fix, Add, Change instead of Fixes, Added, Changing);
• use marked list for multiple changes, prepended by one summary line and one blank line, where each list item must:
  • start with a lowercase letter;
  • has no punctuation symbols at the end.

Update Employee salary algorithm

Implement employees salary and ajax queries

- update Employee salary algorithm
- remove unused files from public/images/ dir
- implement ajax queries for /settings page

• Summary line starts with a lowercase letter:

  update Employee salary algorithm
  

• Verb is not in the imperative mood:

  Updates Employee salary algorithm
  

• Unnecessary punctuation is present:

  Update Employee salary algorithm.
  

  Implement employees salary and ajax queries:
  
  - update Employee salary algorithm;
  - remove unused files from public/images/ dir.
  

• Missing blank line between the summary line and the marked list:

  Implement employees salary and ajax queries
  - update Employee salary algorithm
  - remove unused files from public/images/ dir
  

• Marked list is indented:

  Implement employees salary and ajax queries
  
    - update Employee salary algorithm
    - remove unused files from public/images/ dir
  

• Marked list items start with a capital letter:

  Implement employees salary and ajax queries
  
  - Update Employee salary algorithm
  - Remove unused files from public/images/ dir
  

FCM (final commit message) is a commit message of a pull request to a master branch.

As it will be saved in a repository history forever, it has extra requirements that must be met:

• contain references to related PR;
• do not contain any non-relative helper markers (like [skip ci]);

Common commit messages which are not FCM must NOT contain any references, because references create crosslinks in mentioned PRs, which leads to spamming issues/PRs with unnecessary information. Only saved in history forever commits are allowed to create such crosslinks.

If а PR contains some side changes which are not directly relevant to the task, then such changes must be described as a marked list in the Additionally: section (separated by a blank line) of a FCM.

Implement employees salary and ajax queries (#43, #54)

- update Employee salary algorithm
- remove unused files from public/images/ dir

Additionally:
- update Git ignoring rules for TOML files

• Bad formatting of [references][103]:

  Implement employees salary and ajax queries(#43,#54)
  
  - update Employee salary algorithm
  - remove unused files from public/images/ dir
  

• Side changes are not separated:

  Implement employees salary and ajax queries (#43, #54)
  
  - update Employee salary algorithm
  - remove unused files from public/images/ dir
  - update Git ignoring rules for TOML files
  

• Bad formatting of side changes:

  Implement employees salary and ajax queries (#43, #54)
  
  - update Employee salary algorithm
  - remove unused files from public/images/ dir
  Additionally:
  - update Git ignoring rules for TOML files
  

All merges to the mainline project version (master branch) must have an individual PR (pull request) and must be done only in fast-forward manner. This is required to keep mainline history linear, simple and clear.

To achieve fast-forward merge, all branch commits (which doesn't exist in mainline) must be squashed and rebased onto the latest mainline commit. Notable moments are:

• Before rebase do not forget to merge your branch with latest mainline branch updates, otherwise rebase result can break changes.

Performing squash merge correctly can be quite tricky when doing manually. To avoid complexity and mistakes in a day-to-day routine the GitHub UI squash merging is the most preferred way for merging and a developer should use it whenever it's possible.

0. Merge with latest master branch.

1. Click on Squash and merge button.

2. Paste first line of FCM to title field.

3. Paste FCM without first line to body field.

4. Click Confirm squash and merge.

• First line of FCM must go as a title of the squash commit and everything after as a message.

Squash merging via GitHub UI also preserves the whole branch commits history in the PR, which is good for history purposes.

Developer must push all his changes to the remote at the end of his working day. This both prevents from accidental work losses and helps a lead to track developer's progress.

All features of application should be added with PRs. Direct push to master is forbidden.

PRs (pull requests) are created to make changes in the repository and to solve some problem (fix a bug, implement a task, provide an improvement, etc).

PR must contain related changes only. Any other unrelated changes of repository must be done via separate PR. This rule keeps project history clear and unambiguous.

PR name must:

• shortly and clearly describe its meaning;
• contain Draft: prefix until PR is merged or closed.

Not merged or closed PRs should be in draft mode.

PR description must contain details of the solution (background/summary, solution description, notable moments, etc).

Project have PR template which standardize PRs. Developer must use PR template whenever it's possible.
If there is no template for some rare case, then the PR must be formatted in the same manner as available templates.

PR cannot be assigned to nobody and always must have an assigned developer.

PR cannot go without any labels and must have all required labels correctly applied.

Labels are used for issues/PRs classification, as they:

• reflect the current state of issue/PR;
• improve understanding of issue/PR, its purpose and application;
• provide advanced search of issues/PRs;
• allow to sum up statistics of how project is going on.

There are several label groups:

• Type labels declare what the current issue/PR actually represents. These labels are mandatory: each issue/PR must have at least one such label.
  • feature applies when something new is implemented (or is going to be implemented).
  • enhancement applies when changing of existing features is involved (improvement or bugfix).
  • rollback applies when some existing changes are going to be rolled back.
• k:: labels describe what the current issue/PR is relevant to and which project aspects are involved. These labels are mandatory: each issue/PR must have at least one such label.
  • k::ui applies to UI (user interface) and UX (user experience) changes. Use it when end-user are directly affected by this changes.
  • k::api applies to API (application interface) changes. Use it when you're changing application interfaces, like: HTTP API method parameters, library exported interfaces, command-line interfaces, etc.
  • k::deploy applies to changes that involve application deployment. Use it when you're changing the way application is deployed.
  • k::design applies to changes of application architecture and implementation design. Use it when you're changing architecture and algorithms.
  • k::documentation applies to changes of project documentation.
  • k::logging applies to changes in application logs.
  • k::performance applies to application performance related changes.
  • k::refactor applies to refactor changes of existing code.
  • k::security applies to application security related changes.
  • k::testing applies to changes of project tests.
  • k::toolchain applies to changes of project toolchain.

All Dart source code must follow Effective Dart official recommendations. For code formatting dartfmt must be used (and verified on CI).

Project contains .editorconfig file with both general and project-specific code style rules.

Applying .editorconfig rules is mandatory.

Make sure that your IDE supports .editorconfig rules applying. For JetBrains IDE the EditorConfig plugin may be used.