Storyboard : scrollview avec autolayout
09/02/2015
J'ai vu pas mal de galères avec l'intégration d'un scroll view avec autolayout. J'ai donc fait mon premier screencast (faut être indulgent) qui montre comment mettre une view de 1000 points de hauteur dans un scroll view. Les subtilités : ne pas travailler avec les marges, égaler la largeur de la content view avec la largeur de la view du controller afin qu'autolayout fasse tous les calculs de positionnement.

Faire des screncasts
08/02/2015
Envie de partciper à la communauté qui nous aide bien ? Le screencast c'est pratique pour partager des connaissances. Voici les résultats de mes recherches pour faire un travail acceptable assez vite. D'abord pas de screencast avec QuickTime player. Le l'ai peut-être utilisé comme une buse, mais plus de 60 MB pour une minute, ça craint.

• Prendre le screencast. En free, 15 minutes maxi. Pas besoin d'autre chose pour l'instant.
• iMovie, pour réduire la taille de l'image, générer le jpg d'illustration.
• Billet de Pierre Hirel qui explique comment intégrer une vidéo en HTML5. Il parle entre autre de l'outil de conversion de format vidéo ffmpeg.
• Pas habitué à compiler des lib et pas l'envie d'apprendre ça maintenant, j'ai chargé cet outil qui wrappe ffmpeg. Ca marche super. Ne par oublier de faire un don aux gens moins fainiasses comme moi.

Couverture de code : Xcoverage
09/02/2014
Xcoverage

Faire des tests unitaires c'est bien, connaître sa couverture de code, c'est encore mieux. Je n'ai pas vu cette possibilité dans les présentations de la WWDC que ce soit dans Xcode 5 avec XCTest ou sur le serveur avec les produits d'intégration continue. Effet collatéral : j'ai l'air malin face aux collègues Java fans de Jenkins -). Xcode génère bien les fichiers destinés à l'analyse de couverture de code et laisse le soin à d'autres de développer les outils. Après avoir utilisé CoverStory, j'utilise maintenant Xcoverage.

Etapes à respecter pour la mise en place de la couverture de tests.

1. Télécharger et installer l'application Xcoverage.
2. Dans Xcode, pour la target de test, dans Build phase, ajouter une phase 'Run Script'. Voir comment faire dans l'application Xcoverage Menu Xcoverage/Integration...
3. Mettre en place les tests unitaires avec XCTest -).
4. Pour la target de l'application et uniquement pour le Debug, setter Xcode pour qu'il génère les fichiers .gcda et .gcno qui servent de base à l'analyse de couverture de code :
   --> /Build Settings :
   --> Generate Test Coverage File : YES
   --> Instrument Program Flow : YES
   
5. Malgré ce setting, il faut dire à Xcode de remplir les fichiers lors des test ! C'est expliqué ici.
6. Les fichiers sont alors générés lors des tests dans ~/Library/Developer/Xcode/DerivedData/MyApp-/Build/Intermediates/MyApp.build/Debug-iphonesimulator/MyAppTests.build/Objects-normal/i386/.
7. Aller dans Xcoverage qui a démarré suite au point 2. L'ouverture d'un fichier cgda ouvre tous les autres fichiers.

Documentation : Appledoc
20/10/2013
Url du projet
Un site d'info
Un site d'info

But : générer une doc automatiquement, donc dans une phase de build. De base il y'a headerdoc de Apple. Il y'a l'outil Doxygene qui a l'air très complet notamment avec des diagrammes de classes. Je prends l'outil AppleDoc sur git. Le but étant de prendre l'habitude de faire de la doc et donc de démarrer vite sur un outil simple (du moins en apparence).

Installation.

- Charger le projet en local :
git clone git://github.com/tomaz/appledoc.git

- On peut faire une installation directement en locale par “sudo sh install-appledoc.sh”. Ca n'a pas marché chez moi, j'ai donc buildé dans xcode et placé l'exécutable appledoc dans /usr/local/bin (car comme dit la doc /usr/local/bin et bien dans mon $PATH). Enfin je fais un appledoc –help et vois que c'est un outils très riche au vue des arguments possibles.

- Activation dans Xcode pour un projet.
La documentation dit de créer un target, c'est bien mais il est peut-être préférable de générer la doc à chaque build du projet, elle est toujours synchro. Encore un fois c'est comme en cuisine, on fait à son goût. J'appelle l'exécutable appledoc à chaque build via un scrip sh.

Dans Xcode 5.
Edition du xcodeproj/TARGETS/target principale/Build Phases/.
Menu Editor (vas savoir pourquoi Apple a retiré les boutons en bas de l'éditeur)/Add build Phase/Add Run Script Build Phase/.
On copie alors le script sh qu'on trouve sur le site GIT : https://github.com/tomaz/appledoc/blob/master/XcodeIntegrationScript.markdown.
Sans rien faire d'autre, on build la target, et la doc est générée dans ~/help.
Problème; Normalement un docset est aussi généré, mais chez moi il n'est pas lisible par Dash. J'ai ma doc html, c'est déjà bien.
Bon c'est ici que ça se complique, on veut modifier les paramètres d'exécution par exemple pour générer la doc dans le projet. Donc go vers les manuels et les exemples -).
Comme paramètres intéressant pour moi :
Génération dans le projet : --output "${PROJECT_DIR}/doc/" \
En tête de doc mettre des infos générales, le readme.txt par exemple : --index-desc "${PROJECT_DIR}/readme.txt" \

Documenter le code.

pour des exemples visuels

- Un commentaire pris en charge par AppleDoc commence par /** et fini par */.

- Pour une classe on peut mettre un commentaire global.

    /** This class demonstrates AppleDoc.
     
     A second paragraph comes after an empty line.
     
    	int i=0;
    	i++;
     
     And some sample code can also be in a block, but indented with a TAB.
     */
    

- Pour une méthode, on peut commenter les paramètres.

    /**------------------------------------------------------------------
     * @name A name under which this method appears under "Tasks"
     *  -----------------------------------------------------------------
     */
     
    /** This is the first super-awesome method.
     
     You can also add lists, but have to keep an empty line between these blocks.
     
     - One
     - Two
     - Three
     
     @param string A parameter that is passed in.
     @return Whatever it return
    */
    

- On peut ajouter des urls, des warnings qui seront affichés en fond bleu, des bugs en fond jaune.

    /** This is the second super-awesome method.
     
     Note that there are additional cool things here,
 like [direct hyperlinks](http://www.cocoanetics.com)
     
     @param number A parameter that is passed in, almost as cool as someMethodWithString:
     @return Whatever it returns.
     @see someMethodWithString:
     @warning *Warning:* A blue background.
     @bug *Bug:* A yellow background.
     */
    (NSString *)someMethodWithInteger:(NSInteger)number;
    

Transfer FTP : FileZilla 3.7.3
29/09/2013
FileZilla

Après avoir écrit sa prose, il faut la livrer (si, si). Ce n'est pas l'outil le plus cool (ha… Cyberduck), mais c'est libre, riche, facile, efficace.

Editeur html : Smultron 5
28/09/2013
Smultron sur AppStore

On a régulièrement besoin d'un éditeur texte prêt à l'emploi pour faire du html, cette page par exemple, sans pour autant passer par Xcode ou TextEdit qui n'est pas très pratique pour cet usage. Il y'a l'héritage Unix avec Emacs, MacVim, mais il faut apprendre ou ré-apprendre les commandes. Ok, c'est comme le vélo, ça ne s'oublie pas, quoique -). Bref, pas top si on veut faire sa page en 1 heure chrono. Il y'a de très beaux produits Cocoa comme BBEdit, TextMate ou Sublime Text. J'ai pris Smultron car il est Cocoa donc prise en main immédiate, il est reconnu et bien coté. Je n'avais pas envie de finasser en changeant régulièrement les versions démo pour ne pas payer une licence à 50 €. A 4,99 € Smultron 5 est plus qu'abordable à côté des 46,02 € de TextMate ou des 44,99 € de BBEdit. Je suis clean sur la licence, j'ai effectivement fait ma page rapidement (bon ok, un peu plus d'une heure), et le développeur reçoit sa juste rétribution. Malgré ça, RMS tu restes mon héros, juste après Steve bien-sûr -).

Copyright © Pascal Micha 2015 | Validations HTML5 & CSS3