Actions avancées de gestion des erreurs pour les applications mobiles

MobileTogether 2.1 inclut de nouvelles actions de gestion des erreurs "Try/Throw" et "Catch" pour les applications mobiles, permettant aux développeurs de créer des routines de gestion des erreurs sophistiquées qui améliorent l'expérience utilisateur. Par exemple, si une application tente de se connecter à un service Web tiers, mais que le serveur n'est pas disponible, les actions de gestion des erreurs permettent une reprise en douceur.

Les mécanismes de gestion des erreurs de MobileTogether pour les applications mobiles fonctionnent de la même manière sur toutes les plateformes, ce qui permet aux développeurs de gagner du temps, car il n'est pas nécessaire de personnaliser la gestion des erreurs en fonction des exigences de chaque système d'exploitation mobile.

Dans notre article précédent, intitulé « Les services REST comme sources de données pour les applications mobiles », nous avons utilisé une application de démonstration qui appelle un service REST hébergé par l'USGS afin d'obtenir des valeurs d'altitude précises pour des coordonnées géographiques.

Nous pouvons utiliser les blocs Try/Catch pour gérer les deux types d'erreurs différents qui pourraient survenir lors de l'exécution du service REST :

• Il est possible que nous rencontrions une erreur de connexion au serveur du USGS
• Nous pourrions recevoir une valeur d'altitude de -1000000, ce qui indique que le service géologique américain (USGS) ne dispose d'aucune donnée d'altitude pour les coordonnées fournies

Nous pouvons intégrer l'ensemble de l'appel au service REST et les actions suivantes permettant de manipuler les données à l'intérieur d'un bloc "Try", comme illustré ci-dessous :

Si la connexion au service web échoue, toutes les actions suivantes à l'intérieur de l'action "Try" sont interrompues. Si nous ne recevons aucune donnée du USGS, il est inutile de tenter l'action "Mettre à jour le(s) nœud(s)" mentionnée ci-dessus. Dans cet exemple, une seule action serait interrompue, mais vous pouvez placer plusieurs actions, des groupes d'actions, ou même des groupes d'actions qui appellent d'autres groupes d'actions à l'intérieur de l'action "Try".

De même, l'action "Catch" peut également effectuer plusieurs opérations qui ne sont exécutées que lorsque l'erreur se produit. Dans la capture d'écran ci-dessus, "Catch" affiche une boîte de message indiquant que la connexion a échoué, et elle effectue la mise à jour des nœuds en utilisant la même valeur d'altitude que le USGS fournirait en cas d'erreur de plage. Bien sûr, vous pouvez placer plusieurs actions, groupes d'actions, ou même des groupes d'actions qui appellent d'autres groupes d'actions à l'intérieur de l'action "Catch", tout comme dans le bloc "Try".

Contrôle de flux plus complexe avec gestion des erreurs pour les applications mobiles

La véritable puissance de la gestion des erreurs avec les mécanismes try/catch/throw se révèle pleinement lorsque l'application mobile nécessite une logique de programmation plus complexe.

Considérons le cas où un groupe d'actions contient une série d'opérations – comme des commandes de base de données ou des appels à des services web – qui doivent toutes être exécutées de manière séquentielle, et où chaque appel dépend du succès de l'opération précédente. Il devient rapidement trop complexe de vérifier le résultat de chaque étape à l'aide d'une structure conditionnelle if-else. Au lieu de cela, vous pouvez définir de manière claire et élégante une action de base de données qui déclenche une exception en cas d'erreur, puis utiliser un seul bloc de gestion des exceptions à la fin pour afficher l'erreur.

Cette capture d'écran illustre l'utilisation des blocs try/catch dans une application mobile qui permet d'explorer et d'analyser automatiquement les rapports financiers de haut niveau des entreprises américaines, à partir des données extraites des déclarations XBRL disponibles dans la base de données EDGAR de la SEC

Si l'une des cinq requêtes de la base de données échoue, une erreur est générée, le reste des actions incluses dans le bloc "Try" est ignoré, et la variable contenant le message d'erreur indique quelle requête a échoué.

Gestion des erreurs avec des blocs try/catch imbriqués

Vous pouvez même définir un gestionnaire d'erreurs try/catch dans un groupe d'actions et laisser l'erreur se produire dans un sous-groupe d'actions distinct, qui est appelé à partir de l'action principale. En réalité, cela peut être imbriqué de manière profonde, et l'erreur peut se produire quelque part dans une action imbriquée plusieurs fois.

À ce stade, le contrôle est directement renvoyé à la branche de gestion des erreurs de la fonction externe, où l'erreur est traitée, exactement comme le fonctionnent les mécanismes try/catch/throw dans d'autres langages de programmation.

Le logiciel MobileTogether Designer, qui intègre des fonctionnalités de gestion des erreurs (try/catch/throw) pour les applications mobiles, est gratuit. Téléchargez votre copie dès maintenant