Copyright, exemples de code Apple, etc
neospirit
Membre
Bonsoir,
je me pose pas mal de questions sur les droits et devoirs du développeur d'app iphone. Je suis rentré en phase de béta test et donc bientôt de release mais je me posais quelques questions concernant ce qu'on doit faire ou pas faire pour que notre appli soit bien validée par Apple. J'ai déjà lu le Appstore Review Guidelines et tous les guides utiles mais j'ai dû soit pas tout comprendre ou zappé quelques lignes.
1) Si on utilise les codes sources des exemples Apple (je pense à la Reachability), doit-on mettre/laisser le gros commentaire avec le numéro de version et le blabla ?
2) Une fois que l'application est publiée sur l'Appstore, le code est-il rendu public ?
3) Doit-on documenter notre code pour que la validation se fasse le mieux possible ? Par exemple dans le fichier .H :
Je dis pas que j'ai rien commenté, mais faut-il leur mâcher la compréhension du code ?
Merci pour vos éclaircissements
je me pose pas mal de questions sur les droits et devoirs du développeur d'app iphone. Je suis rentré en phase de béta test et donc bientôt de release mais je me posais quelques questions concernant ce qu'on doit faire ou pas faire pour que notre appli soit bien validée par Apple. J'ai déjà lu le Appstore Review Guidelines et tous les guides utiles mais j'ai dû soit pas tout comprendre ou zappé quelques lignes.
1) Si on utilise les codes sources des exemples Apple (je pense à la Reachability), doit-on mettre/laisser le gros commentaire avec le numéro de version et le blabla ?
2) Une fois que l'application est publiée sur l'Appstore, le code est-il rendu public ?
3) Doit-on documenter notre code pour que la validation se fasse le mieux possible ? Par exemple dans le fichier .H :
//Fonction de récupération des noms des utilisateurs<br />-(void)getNameUsers;
Je dis pas que j'ai rien commenté, mais faut-il leur mâcher la compréhension du code ?
Merci pour vos éclaircissements
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Ni Apple ni personne d'autre ne verra ton code...
La publication sur l'appstore consiste à fournir un binaire compilé. En aucun cas tu n'as a fournir le code source !
(Au passage, "class dump" n'est qu'un outil qui utilise otool avec les bons arguments et en reformattant la sortie de sorte que ça donne un ".h" lisible, et 2-3 autres trucs)
Dans tous les cas ça ne peut analyser que les fichiers objets et les images binaires. Si le binaire n'a pas été "strippé" il contient encore les debugging symbols relatifs à ton propre code, donc on peut savoir les noms des méthodes correspondant à celles dans ton application. Dans tous les cas si tu as les symboles d'une image binaire donnée, tu peux retrouver les noms des méthodes à partir des adresses mémoires appellées (et ça c'est partout pareil, en C, C++, ObjC, ...) : c'est ce que l'on appelle la "symbolisation" ("symbolication" en anglais)
Il se trouve que pour chaque librairie/framework qui se trouve dans le SDK, nous avons (tant Apple que nous puisqu'elles sont dans le SDK et heureusement) justement tous les symboles correspondant : ils sont livrés avec le SDK iOS, dans "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/<version-ios>/Symbols", au format DWARF.
C'est ce qui permet à partir d'un binaire quelconque donc de pouvoir savoir quelle méthode est appellée quand le code binaire exécute le code à telle ou telle adresse. Et c'est surtout ce qui permet entre autres, si ton application plante et que tu as un crashlog (avec la callstack), de symboliser ce crashlog pour savoir quelles sont les méthodes qui ont été appellées et dans laquelle ça a crashé et quelle méthode avait appellé celle-là et quelle méthode avant elle, etc. Sans ces symboles tu n'aurais que des adresses mémoires et pas des noms de méthodes dans la callstack et dans tes crashlogs.
Au final à partir du moment où tu as les fichiers de symboles de toutes les libs du SDK, c'est pas dur (enfin si tu connais le mécanisme sous-jacent) de savoir quelles méthodes (avec leur nom) sont appelées dans une application même une fois compilée. Par contre c'est pas pour autant que ça va retransformer le binaire en code, encore moins remonter aux noms que tu as utilisé pour les variables, et surtout encore moins aux commentaires que tu as pu mettre dans ton code qui sont tout bonnement passés à la trappe lors de la compilation puisqu'ils n'ont aucune incidence sur le code généré.
Merci Ali pour toutes ces précisions ! D'ailleurs, existe t-il a votre connaissance un tuto qui expliquerait un crashlog ? Se pourrait-être utile de voir dans un cas concret comment se servir de cette information.
PS: Je sais, je peux toujours programmer un petit bout de code simple et le faire crasher pour voir ce qui se passe.
Parmi les vidéos de la WWDC 2010, il y en a une qui concerne les crashlogs (je ne l'ai pas visionné, alors je ne sais pas ce que ça vaut).
Merci Ceroce. Oui ça faisait longtemps, en fait je fais pas mal d'autres choses et j'ai un peu "switché" sur QT4 pour les raisons que vous imaginez...
Il est assez intéressant à regarder, même si globalement de mon coté je n'en n'ai jamais eu besoin pour comprendre un crash logs. Il contient quand même quelques informations qui m'avaient échappées.