Qui sommes nous ? Nous contacter
Ouverture de session :

Pseudonyme

Mot de Passe
Enregistrement
Rechercher :
SOMMAIRE
INFORMATIONS
MMT-fr
Ce site respecte les principes de la charte HONcode.
Ce site respecte les principes de la charte HONcode de HON 
Vérifiez ici.
Licences GNU FSF !
Licence Open Source
EN  LIGNE
Il y a actuellement 3 invités et 0 membres en ligne

Vous êtes un visiteur anonyme. Inscrivez-vous gratuitement en cliquant ici.

Écrire de bonnes applications pour Symbian OS

Page: 1/2
(4549 total des mots dans ce texte)
(2821 lectures)   Format imprimable

Écrire de bonnes applications pour Symbian OS

Introduction

> Lorsque vous écrivez une application pour Symbian OS, de nombreux facteurs entrent en ligne de compte – depuis le stade de la conception jusqu'à la touche finale d'édition de votre fichier .SIS – pour obtenir une application de qualité qui soit robuste. Ce document réunit quelques conseils utiles, des astuces et des liens que vous pourrez utiliser en tant que développeur afin de produire l'application Symbian OS la plus fiable possible.

> Au sommaire

  • Conseils d'ordre général
  • Conseils pour la conception
  • Conseils pour le codage
  • Conseils pour les tests
  • Conseils pour le débogage

Conseils d'Ordre général

1. Le réseau Symbian Developer Network héberge un grand nombre d'informations précieuses destinées à vous aider pour l'écriture d'applications Symbian OS. Visitez ces pages régulièrement afin de bénéficier des SDKs et informations techniques les plus récents, ainsi que d'exemples de code. Il vous est également conseillé de souscrire à la lettre de diffusion du Symbian Developer Network – qui est distribuée mensuellement par courriel et qui constitue le meilleur moyen de vous tenir au courant des dernières nouveautés de Symbian à l'adresse des dévelopeurs.

2. Les firmes qui développent des produits sous licence Symbian ont aussi leur propre réseau destiné aux développeurs. On vous conseille également de vous y enregistrer afin de pouvoir accéder aux informations et aux conseils spécifiques concernant leurs téléphones.

3. Hébergée sur le site internet de Symbian Developer Network, la base de donnée des FAQ concernant le Symbian OS est une source inestimable d'informations pour les développeurs qui couvrent les questions les plus fréquentes à propos des problèmes de conception et de codage. Les Standards Symbian OS de Codage C++ y sont également hébergés. Lors du développement du Symbian OS lui-même, Symbian a défini plusieurs normes de codages (coding idioms) et de styles importantes. Le document Coding idioms qui s'adresse aux développeurs d'une tierce partie, les explique. En utilisant ces conventions testées et éprouvées, vous bénéficierez de tout le savoir faire que Symbian a acquis en travaillant sur Symbian OS.

4. Enfin, il existe un nombre croissant de publications disponibles concernant le Symbian OS. Symbian Press met à votre disposition plusieurs ouvrages couvrant toute une gamme de sujets, tous destinés à vous aider à écrire du code pour Symbian OS plus facilement et de façon plus fiable.

Conseils pour la Conception

1. L'astuce la plus importante concernant la conception pour Symbian OS, c'est de bien séparer le code du “moteur” de votre application d'une part et le code de l'interface utilisateur (UI = user interface) d'autre part dans des modules différents. Symbian OS est lui-même conçu de cette façon et cela facilite le portage des applications sur des systèmes différents d'UI.
Tout le code qui n'est pas lié à l'UI doit être mis dans un fichier moteur (engine file) de type .DLL . L'interface utilisateur de votre application peut alors être lié à cette .DLL pour accéder aux fonctionnalités de ce moteur. Par exemple, le code qui ouvre une connexion avec l' Agenda Server (RAgendaServ) n'utilise aucun composant de l'UI et constitue clairement du code appartenant au moteur. L'Agenda Server est commun à toutes les éditions du Symbian OS depuis la Version 6.0 et ainsi votre code moteur devrait fonctionner sur tous les téléphones sans aucune modification.

En codant de la sorte, vous vous simplifiez la tâche de portage vers de nouvelles plateformes disposant d'un UI différent. Comme cela est illustré précédemment, le code purement moteur peut souvent tourner sur n'importe quelle plateforme sans aucune modification. Cela signifie que tout ce que vous avez à porter et optimiser pour le nouvel UI, c'est la couche d'interface utilisateur que vous avez pris soins de séparer.

2. Toujours concevoir en prenant en compte le support des langues.
Ne codez jamais directement des chaînes de caractères ou des littéraux dans vos fichiers sources – utilisez toujours le mécanisme de Fichier de ressources fourni par le Symbian OS pour stocker ces chaînes de caractères.

3. Prendre soin de s'en tenir à n'utiliser que les APIs documentées et supportées pour un SDK et une version de Symbian OS donnée. L'utilisation d'APIs non supportées ou réprouvées peut être la source de problèmes futurs – par exemple, Symbian se réserve le droit de changer ou de retirer les APIs qui ne sont pas sensées être utilisées par les développeurs externes à Symbian.

Conseils pour le Codage

> Dans les paragraphes suivants vous trouverez un ensemble de conseils généraux que nous vous conseillons de garder en tête lors de l'écriture effective de votre code.

1. S'assurer que l'application réponds aux événements de fermeture du système.
Il est vital que votre application réponde à EEikCmdExit (et tout autre événement plateforme spécifique tel que EAknSoftkeyBack et EAknCmdExit sur les appareils Series 60) dans votre méthode AppUi::HandleCommandL().

2. Répondre aux événements système entrants.
Vous devez garder à l'esprit que votre application tourne sur un téléphone doté d'un OS multitâche. Vous devez prêter un attention particulière aux événements gagnés/perdus, etc. pour être certain de donner une réponse adaptée lorsque l'utilisateur reçoit une notification hautement prioritaire. Par exemple, assurez vous d'avoir sauvegardé votre état (status) et vos données (datas) lors d'un appel téléphonique entrant qui fait perdre la main à votre application. En d'autres mots, vous devez agir de façon appropriée sur les événements standards ‘to background’ (mise en arrière-plan) – voir le SDK pour plus de détails.

3. Sur le Symbian OS, la gestion de la mémoire doit être un sujet majeur de préoccupation.
Notez que le comportement sur le téléphone peut parfois différer de celui de l'émulateur. Il est vital de tester votre application sur le téléphone réel avant de le proposer au banc de test.

4. Les crashes KERN-EXEC 3 sont souvent symptomatiques de corruption/dépassement de pile de données (stack corruption-overflow), conformément aux recommandations du SDK de Symbian, donnez la préférences aux files (heap) plutôt qu'aux piles (stack).

5. Dans les situations de saturation de mémoire, il est important d'échouer élégamment.
Une application qui panique signe de la présence d'un sérieux bogue dans le code. Voici quelques erreurs clés fréquentes :

  • Échec de l'ajout correct d'une variable non-membre, heap-allocated, sur la pile CleanupStack.
  • La double destruction - par exemple, l'échec d'utlisation correcte de la fonction Pop() sur un item déjà supprimé de la pile CleanupStack qui provoque ultérieurement une nouvelle tentative de destruction par la pile.
  • Tentative d'accès à des fonctions qui risquent de ne pas exister dans votre destructeur, par exemple :

      CMaClasse::~CMaClasse()
      {
        iUnServeur->Close();
        delete iUnServeur;
      }

    devrait toujours être codé de la façon suivante

      CMaClasse::~CMaClasse()
      {
        if (iUnServeur)
        {
          iUnServeur->Close();
          delete iUnServeur;
        }
      }

  • Mise de variables membres sur la pile CleanupStack - ne faites jamais ainsi, détruisez les normalement dans votre destructeur.

6. Toujours utiliser CleanupClosePushL() avec les classes ‘R’, classes dotées d'une méthode Close().
De cette façon vous serez certain d'obtenir un nettoyage correcte en cas de sortie impromptue d'application (Leave). Par exemple :

  RFile file;
  User::LeaveIfError(file.Open(…));
  CleanupClosePushL(file);
  …
  CleanupStack::PopAndDestroy(); // file

7. De plus, garder en mémoire que la pile CleanupStack est un mécanisme extensible qui peut être utilisé pour nettoyer n'importe quoi en cas de sortie d'application.
Si vous devez gérer une situation plus complexe, ne faites pas l'impasse sur un nettoyage correct. Pour plus d'informations, consultez la documentation du SDK à la rubrique TCleanupItem. Cela peut vous être utile pour vous assurer du nettoyage correcte des autres classes ‘R’ qui ne sont pas dotées de méthode Close() (par exemple, celles qui possèdent une méthode Release() ou Destroy() à la place).

8. Toujours réinitialiser les variables HBufC membres à NULL (zéro) après les avoir détruites.
Dès lors qu'un Leave peut éventuellement survenir lors de l'allocation ( ou la ré-allocation) de HBufC, vous pouvez vous retrouver dans la situation où votre destructeur cherche à détruire un HBufC qui n'existe plus.

9. Si vous avez l'occasion d'utiliser un TRAP de votre propre chef, n'ignorez pas l'ensemble des autres erreurs.
Voici une faute fréquente de codage :

  TPAPD(err, FaireQuelqueChoseL());
  if (err == KErrNone || err == KErrNotFound)
  {
    // Faire autre chose
  }

Codé de la sorte, tous les autres codes d'erreur seront ignorés. Si vous devez utiliser un modèle comme celui qui précède, quittez l'application également pour les autres erreurs  :

  TPAPD(err, FaireQuelquechoseL());
  if (err == KErrNone || err == KErrNotFound)
  {
    // Faire autre chose
  }
  else
  User::Leave(err);

10. N'attendez pas pour appliquer la méthode PushL()qui place les choses sur la pile CleanupStack.
Tout objet nouvellement déclaré (à l'exception des variables membres) doit être immédiatement ajouté sur la pile. Par exemple, ce qui suit n'est pas correct :

  void doExempleL()
  {
    CUnObjet* monObjet1=new (ELeave) CUnObjet;
    CUnObjet* monObjet2=new (ELeave) CUnObjet;
    …
    // Faire quelque chose avec les variables
    …
    CleanupStack::PopAndDestroy(2); // monObjet2, monObjet1
  }

car, si l'assignation de monObjet2 échoue, elle laisse monObjet1 ‘suspendu’ sans méthode de nettoyage.
Le code précédent doit être rédigé de la façon suivante :

  void doExempleL()
  {
    CUnObjet* monObjet1=new (ELeave) CUnObjet;
    CleanupStack::PushL(monObjet1);
    CUnObjet* monObjet2=new (ELeave) CUnObjet;
    CleanupStack::PushL(monObjet2);
    …
    // Faire quelque chose avec les variables
    …
    CleanupStack::PopAndDestroy(2); // monObjet2, monObjet1
  }

11. Notez que les fonctions dont le nom commence par un ‘C’ mettent automatiquement l'objet sur la pile CleanupStack.
Vous ne devez donc pas placer vous-même ces objets sur la pile sinon ils seront présents deux fois. Les fonctions commençant par ‘C’ sont utiles lorsque vous assignez des variables non-membres.

12. La construction en deux phases est la clé de voûte de la gestion de mémoire du Symbian OS.
La règle de base, c'est qu'un constructeur ou un destructeur Symbian OS ne doit jamais quitter l'application (Leave). Si un constructeur C++ quitte l'application, il n'y a ancun moyen de nettoyer l'objet partiellement construit car il n'existe aucun pointeur qui le marque. Pour cette raison, les constructeurs Symbian OS effectuent simplement l'instanciation de l'objet qui fournit alors une méthode ConstructL() où les données membres peuvent être instanciées. Si ConstructL() quitte l'application (Leave), le destructeur standard sera appelé pour détruire tout objet qui aura été alloué avec succès jusqu'à cette étape. Il est essentiel que votre code reflète cette organisation afin d'éviter un gaspillage de mémoire. Pour chaque ligne de code écrite, la bonne question que vous devez vous poser c'est « Cette ligne permet-elle de quitter l'application ? ». Si la réponse est « Oui », alors pensez « Toutes les ressources seront-elles libérées ? »

13. Ne pas utiliser la macro _L() dans votre code.
Cette fonction a été mise à l'écart depuis le Symbian OS v5 – vous devez lui préférer _LIT(). Le problème de la macro _L(), c'est qu'elle appelle le constructeur TPtrC(const TText*) qui doit appeler lui-même une fonction strlen() pour traiter la longueur de la chaîne de caractère. Si cette opération ne requière pas de place supplémentaire en RAM, elle induit un coût en terme de cycles d'unité centrale à l'exécution. À l'opposé, la macro _LIT() construit directement une structure qui est complètement initialisée à l'exécution, économisant ainsi la surcharge de travail de l'unité centrale liée à la construction de TPtrC.

14. Lors de l'utilisation de descripteurs en tant que paramètres de fonction, utilisez par défaut la classe de base.
Dans la plupart des cas, faites passer les descripteurs sous forme de constructeur TDesC&. Utilisez TDesC& pour les descripteurs modifiables.

15. Les Objets Actifs (AO = Active Objects) sont la pièce maîtresse des fonctionnalités du Symbian OS.
Vous devez étudiez soigneusement la documentation du SDK et les articles du Symbian Developer Network concernant ce sujet afin de bien comprendre la façon dont cela marche. Voici quelques conseils utiles :

  • Vous n'avez pas besoin d'appeler TRAP() à l'intérieur de RunL(). L' Active Scheduler TRAP déjà lui-même RunL() et appelle CActive::RunError() après avoir quitté. À cette fin, vous devez implémenter votre propre fonction RunError() pour prendre en charge les sorties de RunL().
  • Faites en sorte que les opérations RunL() soient courtes et rapides. Une opération longue à exécuter bloquera l'exécution des autres AO.
  • Implémentez toujours une fonction DoCancel() et appelez toujours Cancel() dans le destructeur d' AO.

16. De même, il est conseillé d'utiliser la structure d'Objet Actif partout où cela est possible.
Une invitation soutenue à émettre dans une boucle est particulièrement inappropriée sur un appareil fonctionnant sur batterie et peut aboutir à une vraie saignée d'énergie. Portez-y une attention toute particulière lors de l'écriture de jeux – consultez à titre d'exemple le document technique sur le site internet du Symbian Developer Network ici et une discussion plus détaillée ici.

17. Les paniques ViewSrv 11 sont un danger lors de l'écriture d'applications très actives telles que des jeux par exemple.
Elles surviennent lorsqu'un objet actif Viewsrv dans votre application - ou dans toute autre application - ne répond pas dans le délai apparti au serveur de vues. Un délai de réponse de 10-20 secondes est le maximum autorisé. Consultez la FAQ-0900 pour obtenir des explications plus détaillées et la FAQ-0920 pour les conseils pratiques qui permettent d'éviter ce problème. Elles sont toutes deux disponibles dans la base de donnée des Symbian OS FAQ .

18. Il n'est pas nécessaire de vous servir de HBufC::Des() pour entrer dans un tampon HBufC.
Tout ce que vous devez faire, c'est de déreferencer le tampon HBufC avec l'opérateur * – ceci est particulièrement approprié par exemple lors du passage d'un HBufC en argument d'une méthode qui prend un paramètre TDesC& (comme cela est recommandé précédemment).

19. Lorsque vous utilisez la fonctionnalité de Fichier .INI pour application standard (en utilisant l'API Application()->OpenIniFileLC(); dans votre classe Application UI), écrire dans les flux en prenant soin de renseigner le numéro de version.
Cela permet de créer d'autres flux pour les versions ultérieures de votre application, ce qui évite après installation d'une nouvelle version de votre produit, qu'un ‘ancien’ fichier .INI ne provoque une panique de cette nouvelle version si elle ne s'avérait pas à même de trouver les bons paramètrages ou les bons flux.

20. Faire attention lors de l'implémentation des classes de structure dans votre application. Toujours les faire dériver des classes de structure spécifiquement fournies pour la plateforme.
Par exemple, en ce qui concerne la plateforme UIQ, ne faites pas dériver votre classe AppUi de CEikAppUi, faites la dériver de CQikAppUi. Toutes les classes de la base d'applications (CQikAppUi, CQikApplication, et CQikDocument) ajoutent des fonctions sur lesquelles les plus grandes structures reposent pour faire en sorte que les applications fonctionnent correctement.

   Suivant (2/2) Suivant

[ Retour PROGRAMMATION | Index des Rubriques ]

Accueil Actualités Articles Projets Téléch. Livres Liens Top10

Site internet motorisé par PostNuke ADODB database libraryLangage PHP

Tous les logos et toutes les marques de fabrication sont la propriété de leurs détenteurs respectifs. Les commentaires appartiennent aux personnes qui les ont postés, et tout le reste est Copyright© 2003-2010 de www.smart-doc.org
Ce site internet est réalisé avec PostNuke. Ce système de gestion de portail écrit enPHP est un Logiciel Libre distribué sous licence GNU/GPL license.