mAPRS est mon projet personnel d’application pour les systèmes Android et iOS, conçue pour fonctionner avec APRS. Elle n’est pas née d’un manque d’applications compatibles avec APRS sur le marché — il en existe déjà plusieurs, dont beaucoup remplissent très bien leur rôle. La raison était bien plus simple. Lors de mon utilisation quotidienne d’APRS, la nécessité de modifier constamment les paramètres manuellement en fonction de ce que je faisais m’agaçait. Lorsque je suis en voiture, je veux être visible autrement que lorsque je me déplace à pied. Un autre ensemble d’informations devrait encore être envoyé lorsque je suis chez moi. Il fallait y penser à chaque fois. C’est alors qu’une question m’est venue à l’esprit : pourquoi l’application ne pourrait-elle pas le faire elle-même ? C’est ainsi que mAPRS a commencé à voir le jour.
D’où vient l’idée de mAPRS ?
Dès le début, l’objectif principal du projet était très concret : l’application devait fonctionner de manière aussi autonome que possible. Je ne voulais pas me demander avant chaque déplacement si j’avais sélectionné la bonne icône. Je ne voulais pas non plus modifier manuellement le profil après avoir garé la voiture et commencé à marcher. Je ne voulais pas davantage devoir penser à changer à nouveau les paramètres en rentrant chez moi. mAPRS doit reconnaître la situation et réagir en conséquence.
L’application détermine si, actuellement : je suis en voiture, je me déplace à pied ou je suis chez moi. Sur cette base, elle sélectionne automatiquement les éléments appropriés à transmettre à APRS — avant tout l’icône, le commentaire ainsi que le symbole approprié de la station. L’utilisateur n’a donc pas besoin de modifier la configuration manuellement à chaque fois. C’est précisément cette automatisation qui est la principale raison d’être de mAPRS et, en même temps, la caractéristique autour de laquelle je construis tout le projet.
Interopérabilité avec APRS-IS
mAPRS communique avec le réseau APRS-IS, c’est-à-dire la partie Internet de l’infrastructure APRS. L’application prépare les informations relatives à la station et les transmet au réseau. Ainsi, la position et les autres données peuvent également être visibles dans d’autres services et applications utilisant APRS-IS. Pour moi, il est très important de préserver la compatibilité avec APRS. L’automatisation ne doit pas créer une méthode de fonctionnement propriétaire et fermée. Au contraire, mAPRS doit exploiter l’infrastructure APRS existante, tout en exécutant à la place de l’utilisateur certaines opérations qui doivent habituellement être effectuées manuellement. Du point de vue du réseau lui-même, la différence est minime, mais elle est très importante pour la personne qui utilise l’application au quotidien.
La trace doit rester précise
L’enregistrement et l’affichage du trajet constituent l’un des éléments importants de l’application. Lors du développement de mAPRS, je tiens à ce que l’optimisation du fonctionnement de l’application ne se fasse pas au détriment de la qualité de la trace. Si je me déplace sur un itinéraire, je veux pouvoir en voir ensuite le tracé réel, et non quelques points placés au hasard et reliés par des lignes droites. C’est pourquoi les mécanismes responsables de l’envoi des informations à APRS et ceux liés à la création de la trace ne doivent pas nécessairement fonctionner exactement de la même manière. Pour fonctionner correctement et afficher le trajet, l’application peut avoir besoin d’informations détaillées sur les déplacements, même si toutes ces informations ne doivent pas être transmises immédiatement à APRS-IS.
Nouveau défi : la consommation d’énergie
Une application qui surveille la position pendant de nombreuses heures peut très facilement devenir l’une des plus grandes consommatrices d’énergie du téléphone. L’optimisation de la consommation de la batterie constitue donc une autre étape importante du développement de mAPRS. Il ne s’agit toutefois pas de choisir la solution la plus simple, qui consisterait à vérifier la position moins fréquemment. Cela pourrait dégrader la qualité de la trace ainsi que l’efficacité de la détection du mode de déplacement. L’objectif est de trouver une manière d’utiliser les mécanismes de localisation permettant à l’application de recevoir les informations nécessaires, tout en évitant de solliciter inutilement le téléphone. C’est particulièrement important lors d’un long trajet ou d’une journée entière d’activité en extérieur. mAPRS doit pouvoir fonctionner en arrière-plan pendant longtemps, sans que l’utilisateur ait constamment à se demander combien de batterie il reste au téléphone.
Une application développée par étapes
mAPRS est continuellement en développement. J’essaie toutefois de ne pas introduire simultanément de nombreux changements sans lien entre eux. Chaque nouvelle version a un objectif précis : améliorer un élément donné, modifier le comportement de l’application ou optimiser un mécanisme existant. La nouvelle version est ensuite soumise à des tests. Cette approche permet de vérifier beaucoup plus facilement si une modification a réellement produit le résultat attendu et si, par la même occasion, elle n’a pas eu d’effet négatif sur un élément qui fonctionnait correctement auparavant. Cela est particulièrement important pour une application qui utilise la localisation en arrière-plan. Certains problèmes n’apparaissent pas après cinq minutes d’utilisation. Ils ne deviennent visibles qu’au cours d’un long trajet, d’un arrêt, d’une promenade ou après plusieurs heures de fonctionnement. C’est pourquoi les tests en conditions réelles constituent une partie très importante du projet dans son ensemble.
Il ne s’agit pas de créer une application APRS de plus
mAPRS n’a pas vocation à rivaliser avec tous les programmes existants par le nombre de fonctionnalités. Ce n’était pas l’objectif du projet. Je souhaite avant tout résoudre un problème que j’ai moi-même rencontré en utilisant APRS. Si l’application peut détecter seule que je suis en train de conduire, pourquoi devrais-je modifier manuellement le symbole de la voiture ? Si, un instant plus tard, je me déplace à pied, pourquoi devrais-je encore ouvrir les paramètres ? Et si je suis rentré chez moi, le téléphone peut également le détecter. C’est précisément cette idée qui est la plus importante pour moi : APRS doit s’adapter à ce que fait l’utilisateur, et non l’utilisateur à l’application.
Un projet qui m’apprend moi-même beaucoup de choses
mAPRS est à la fois un projet pratique et technique. Pour le créer, je dois réunir plusieurs domaines totalement différents : le fonctionnement du système, la localisation, l’exécution de l’application en arrière-plan, les communications réseau, les spécificités d’APRS, l’analyse des déplacements ainsi que l’optimisation de la consommation d’énergie. À cela s’ajoutent la préparation des versions suivantes, les tests et tout le processus de distribution de l’application. Chaque nouvelle étape révèle de nouveaux problèmes qui sont souvent invisibles au départ. C’est précisément ce qui rend ce projet le plus intéressant. mAPRS n’est pas né comme un produit fini planifié du premier au dernier écran. Il évolue au fil des tests et des idées issues de l’utilisation réelle de l’application.
Quelle sera la suite pour mAPRS ?
L’idée fondamentale reste inchangée : automatiser au maximum l’utilisation d’APRS tout en gardant le contrôle sur ce que fait l’application. Les prochaines étapes du développement concernent principalement l’amélioration de la reconnaissance des situations, la commutation correcte des profils, le fonctionnement de la localisation, la manière de signaler la position ainsi que la réduction de la consommation d’énergie. Je souhaite également que l’utilisateur sache clairement ce que fait l’application à un moment donné et quelles données elle transmet à APRS-IS. En revanche, je ne tiens pas à ajouter des fonctionnalités uniquement pour allonger la liste. Je préfère que quelques mécanismes essentiels fonctionnent vraiment bien.
mAPRS – moins de commutations, plus d’APRS
Le projet a commencé par une irritation très simple : la commutation manuelle permanente des paramètres APRS. De là est née l’idée d’une application qui observe la situation et qui peut décider elle-même de la manière dont ma station doit être présentée à un moment donné. Je conduis. Je marche. Je suis chez moi. mAPRS doit le reconnaître et sélectionner en conséquence l’icône, le commentaire et le symbole APRS. Sans avoir à penser aux commutateurs. Sans devoir ouvrir les paramètres à chaque fois. C’est précisément l’idée principale de mAPRS — et c’est d’elle que tout le reste du projet est parti.
La politique de confidentialité de l’application mAPRS se trouve ici.