E-mission est désormais géré au sein du labo fédéral NREL que sa conceptrice à rejoint début 2020. Pour l'instant, e-mission continue à être maintenu, ce qui permet d'avoir une appli à jour des évolutions des OS des smartphones (notamment iOS13).

La crise sanitaire a retardé quelques mois les développements, mais la feuille de route 2021 pour le logiciel est désormais assez claire, la priorité est d'industrialiser le produit pour faciliter sa réutilisation, notamment via une modularisation du code de l'appli mobile (dont SDK natif) et du serveur (communication avec le mobile et pipeline d'analyse des données), sur la base d'un financement du ministère de l'énergie américain à confirmer bientôt. Ces évolutions se feront progressivement au cours de l'année 2021 et bénéficieront aux réutilisations en France, notamment celle prévue à La Rochelle dans le cadre du projet Agremob.

En anglais dans le texte,

  1. Modularization: Modular software systems with well-defined interfaces improve security, robustness, and extensibility. They also encourage community contributions, since they clarify ownership credit.

    • The native sensing code is already structured into separate modules, but the interface between the modules have blurred over time. We will revisit the modules and refactor them to have cleaner interfaces.
    • The native sensing code is published as cordova plugins. The cordova interface is a thin layer over native code. We will extract and publish the core functionality as native libraries. This would allow our partners to integrate with their existing mobility-as-a-service (MaaS) apps. It would also allow them to easily create plugins for modern hybrid frameworks such as React Native and Flutter.
    • The User Interface (UI) code is split into multiple angular modules, but they are all checked into one codebase. This complicates reuse, since module changes can only be adopted through copy-paste. Creating and publishing separate, configurable modules (e.g. diary-in-angular) will make it much easier to compose modules into a custom UI.
    • The server and analysis tiers are currently combined into a single codebase. Separating them, and publishing individual python modules will aid composability. It will also allow the community to more easily contribute improved versions of the analysis modules.
  2. Testing: Frameworks that intend to nuture a vibrant community must invest is a strong testing and Continuous Integration (CI) pipeline to keep themselves "enterprise ready". Such piplines reduce the burden for testing contributions and ensure interoperability.

    • The phone repository currently only has a build CI pipeline for the native code. As we modularize the native code and the UI, we will introduce native and UI test harnesses, write unit and integration tests, and achieve 80%+ code coverage.
    • The server code currently has a build and test CI pipeline with unit and feature tests. We will improve the test examples, add support for mocking external calls, and achieve 80%+ code coverage.
  3. Documentation: Since the framework is so flexible, deployers typically have questions related to prior usage. Typical questions are around deployment costs, customization effort, and feature selection. Deployers also like to see showcase examples and tutorials that offer a starting point for their customization. If resources permit, we would like to create showcases and tutorials, and provide a standard structure for the community to contribute use cases.