30 votes

Meilleures pratiques pour la journalisation des erreurs et / ou la génération de rapports pour iPhone

Quand je fais du développement web, j'utilise un logger qui intercepte les erreurs fatales et ajoute une trace dans un fichier et affiche un message à l'utilisateur. Je peux occasionnellement coup d'œil pour voir si le fichier a changé, ce qui signifie que l'utilisateur a rencontré une erreur et je peux creuser pour voir ce qu'ils ont vécu.

J'aimerais quelque chose de similaire sur l'iphone, avec quelques mises en garde:

  • Pendant le développement, il doit être facile de réinitialiser la liste des erreurs ou désactiver la notification.
  • Pendant le développement, les messages d'erreur devrait également apparaître dans certains endroit évident, comme sur l'écran de la console
  • Une fois déployées, les erreurs doivent poliment être envoyé à la mère pour l'analyse (pour un bug corrigé dans la prochaine mise à jour)
  • Activer le traçage/Info journalisation lors de traquer un problème en cours de développement
  • Désactiver la journalisation de la console pour "Libération" pour accélérer les choses pour l'utilisateur
  • Doivent nettoyer après lui-même pour être un bon citoyen sur le téléphone

Certains Liens Connexes

Il semble qu'il y aurait une commune de la trousse d'outils pour ce faire - comment gérez-vous cela?

[Mise À Jour Octobre 2011] Il y a eu certains développements, de différentes de la maturité...

  • PLCrashReporter.
  • Quincy est assis sur le dessus de la PLC.
  • Bugsense commercial crash reporter.
  • Crittercism accident et les rapports d'erreurs (certains programmes gratuits, d'autres payants).
  • Le vol d'essai a maintenant un SDK que les captures se bloque (mais pas encore pour les apps de l'app store, juste dev apps).
  • Comme le Vol d'Essai, le Hockey vise à combiner la distribution ad hoc avec des rapports d'incidents.

38voto

Dan J Points 7314

Voici ce que nous faisons:

  • Laisser l'iPhone gérer son propre vidages sur incident par le biais de l' existant App Store mécanismes. Mise à jour: ayant trouvé iTunes Connect pour ne pas être fiables à fournir des rapports de plantage, j'ai commencé à utiliser Crittercism et arceau de sécurité dans certaines de mes applications. Il ne le travail est bien fait, et a un plan gratuit.
  • Notre produit sorti a aucune trace dans, ce qui semble cohérent avec ce que la plupart des autres applications de l'iPhone ne.
  • Si un bug est signalé alors nous le reproduisons à l'aide d'un tracé de construire.

Plus en détail:

  • Nous avons définir des macros pour NSLog trace dans de nombreux et différents niveaux de granularité.
  • Utiliser Xcode construire des paramètres pour modifier le niveau de trace, qui contrôle la quantité de trace sera compilé dans le produit, il y a par exemple Release et Debug configurations.
  • Si pas de trace de niveau est défini ensuite nous montrer plein de trace dans le Simulateur, et aucune trace lors de l'exécution sur un Périphérique réel.

J'ai inclus un exemple de code ci-dessous montre comment nous avons écrit ceci, et à quoi ressemble la sortie.

Nous définir plusieurs niveaux de suivi qui permet aux développeurs d'identifier les lignes de trace sont importants, et peuvent filtrer le détail des niveaux inférieurs si ils le veulent.

Exemple de code:

- (void)myMethod:(NSObject *)xiObj
{
  TRC_ENTRY;
  TRC_DBG(@"Boring low level stuff");
  TRC_NRM(@"Higher level trace for more important info");
  TRC_ALT(@"Really important trace, something bad is happening");
  TRC_ERR(@"Error, this indicates a coding bug or unexpected condition");
  TRC_EXIT;
}

Exemple de trace de sortie:

2009-09-11 14:22:48.051 MyApp[3122:207] ENTRY:+[MyClass myMethod:]
2009-09-11 14:22:48.063 MyApp[3122:207] DEBUG:+[MyClass myMethod:]:Boring low level stuff
2009-09-11 14:22:48.063 MyApp[3122:207] NORMAL:+[MyClass myMethod:]:Higher level trace for more important info
2009-09-11 14:22:48.063 MyApp[3122:207] ALERT:+[MyClass myMethod:]:Really important trace, something bad is happening
2009-09-11 14:22:48.063 MyApp[3122:207] ERROR:+[MyClass myMethod:]:Error, this indicates a coding bug or unexpected condition
2009-09-11 14:22:48.073 MyApp[3122:207] EXIT:+[MyClass myMethod:]

Nos définitions de trace:

#ifndef TRC_LEVEL
#if TARGET_IPHONE_SIMULATOR != 0
#define TRC_LEVEL 0
#else
#define TRC_LEVEL 5
#endif
#endif

/*****************************************************************************/
/* Entry/exit trace macros                                                   */
/*****************************************************************************/
#if TRC_LEVEL == 0
#define TRC_ENTRY    NSLog(@"ENTRY: %s:%d:", __PRETTY_FUNCTION__,__LINE__);
#define TRC_EXIT     NSLog(@"EXIT:  %s:%d:", __PRETTY_FUNCTION__,__LINE__);
#else
#define TRC_ENTRY
#define TRC_EXIT
#endif

/*****************************************************************************/
/* Debug trace macros                                                        */
/*****************************************************************************/
#if (TRC_LEVEL <= 1)
#define TRC_DBG(A, ...) NSLog(@"DEBUG: %s:%d:%@", __PRETTY_FUNCTION__,__LINE__,[NSString stringWithFormat:A, ## __VA_ARGS__]);
#else
#define TRC_DBG(A, ...)
#endif

#if (TRC_LEVEL <= 2)
#define TRC_NRM(A, ...) NSLog(@"NORMAL:%s:%d:%@", __PRETTY_FUNCTION__,__LINE__,[NSString stringWithFormat:A, ## __VA_ARGS__]);
#else
#define TRC_NRM(A, ...)
#endif

#if (TRC_LEVEL <= 3)
#define TRC_ALT(A, ...) NSLog(@"ALERT: %s:%d:%@", __PRETTY_FUNCTION__,__LINE__,[NSString stringWithFormat:A, ## __VA_ARGS__]);
#else
#define TRC_ALT(A, ...)
#endif

#if (TRC_LEVEL <= 4)
#define TRC_ERR(A, ...) NSLog(@"ERROR: %s:%d:%@", __PRETTY_FUNCTION__,__LINE__,[NSString stringWithFormat:A, ## __VA_ARGS__]);
#else
#define TRC_ERR(A, ...)
#endif

Xcode paramètres:

Dans Xcode construire des paramètres, choisissez "Ajouter un Paramètre Défini par l'Utilisateur" (en cliquant sur le petit rouage en bas à gauche de la configuration de l'écran), puis de définir un nouveau paramètre appelé GCC_PREPROCESSOR_DEFINITIONS et lui donner la valeur TRC_LEVEL=0.

La seule subtilité est que Xcode ne sait pas faire un build propre si vous modifiez ce paramètre, donc n'oubliez pas de faire manuellement un Nettoyage si vous le changez.

4voto

bpapa Points 10188

Apple recueille automatiquement les journaux de plantage des utilisateurs pour vous, et vous pouvez les télécharger à partir d'iTunes connect.

Si cela ne vous suffit pas, je ne connais pas de boîte à outils mais je ne voudrais pas rouler quelque chose par moi-même, personnellement. Il semble que trop d'efforts pour développer quelque chose de robuste, pourrait soulever des problèmes de confidentialité, et au final, avec 100 000K applications dans l'App Store, combien d'utilisateurs utiliseraient à nouveau votre application après avoir découvert qu'elle était boguée?

4voto

Jens Kohl Points 2407

Savez-vous que CrashReporter pour iPhone existe?

Il y a un dépôt sur github qui fait la démonstration de ce code.

Il a des fonctionnalités intéressantes comme le mappage de la trace de la pile à votre code et gère certaines choses spécifiques à git comme les hachages de version.

2voto

dagnytaggart Points 147

Je recommande fortement CocoaLumberJack de Robbie Hanson: https://github.com/robbiehanson/CocoaLumberjack

Il est très flexible et puissant, peut-être même un peu excessif s'il est maltraité. Prend en charge différents niveaux de journalisation. La journalisation dans des fichiers peut être activée avec quelques lignes de code et même être envoyée sur le réseau.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X