1 commentaire »
Aucun commentaire
Pietro les a rendu disponibles sur le Slideshare Hortis: http://www.slideshare.net/hortis/mardi-gras-du-2-juin-2010-csim2
Evidemment, le développement du projet continue et si vous êtes intéressés par celui-ci en tant qu’utilisateurs, n’hésitez pas à nous contacter
Aucun commentaire
Le mercredi 2 juin, une session de présentation est programmée pour 18h15, elle pourrait se nommer “mardi gras”… si ce n’est qu’elle se déroule un mercredi 
Durant cette session, Pietro vous fera découvrir (aux friends & family hortis) le plug-in Eclipse que hortis développe en partenariat avec HEG afin d’aider à se ré-approprier du code legacy (code oublié pourrait-on dire) et de pouvoir le manipuler et le changer pour le maintenir. Il s’agit d’aider à facilement cibler “quoi toucher” pour apporter les améliorations ou corrections là où il faut. Ce plug-in comporte également, pour les besoins de notre approche, un module entièrement dédié à la gestion des Use-Cases d’un projet afin de décrire les actions métiers de celui-ci, avec possibilité d’exports des scénarios de manière joliment formatée et personnalisable.
Ce besoin de réappropriation à des fins de maintenance est fréquent dans les entreprises, et notre approche innovante. Je vous invite à vous rendre à cette session qui permettra de mieux comprendre l’intérêt et la technique de cette approche. Notez que suite à cette présentation un petit concours sera lancé durant les semaines suivantes pour trouver un nom à ce projet.
Inscrivez-vous sur le doodle suivant : http://www.doodle.com/86h66kvvrfretyef
En nous espérant nombreux à cette session, tant le sujet est intéressant.
2 commentaires »
 |
 |
Les défis à relever : Permettre la compréhension, la ré-appropriation et la maintenance du code « oublié » d’un logiciel en vue de le faire évoluer vers de nouvelles fonctionnalités pour ses utilisateurs.
L’opportunité : Livrer aux équipes techniques un outil de maintenance destiné à mettre à jour régulièrement leurs applications internes en toute autonomie, sécurité et fiabilité.
2 commentaires »
En codant une application iPhone, on utilise très souvent un élément graphique, la TableView. Pour cela, on utilise un objet de type UITableView.
Cette vue peut être gérée par un contrôleur de type UITableViewController, mais dans les faits, il n’est pas souvent utilisé. Apple, dans son guide de programmation, le déconseille dès que la TableView est une vue parmis celles qui seront affichées en même temps. On va donc plutôt utiliser un contrôleur de type UIViewController.
Dans l’iPhone HIG d’Apple (iPhone Human Interface Guidelines), Apple explique qu’il faut toujours indiquer la taille d’une TableView à l’utilisateur, et ne pas l’induire en erreur dans la sélection d’une ligne. Un contrôleur de type UITableViewController le fait tout seul, mais pas un de type UIViewController.
Le code va vérifier à l’affichage qu’aucune ligne n’est sélectionnée (surtout qu’en on revient en arrière dans une UINavigationBar) et que l’utilisateur voit la taille de la TableView, en lui montrant la barre de scroll à droite, quelques instants.
Dans notre fichier d’entête du UIViewController, on doit avoir une variable qui pointe vers la TableView.
IBOutlet UITableView *_tableView;
Dans le fichier d’implémentation, on va utiliser réécrire 2 méthodes d’instance pour déselectionner la possible ligne sélectionnée, et afficher le scroll, si et seulement si la TableView est plus grande que la taille de l’écran.
- (void)viewWillAppear:(BOOL)animated {
[super viewWillAppear:animated];
[_tableView deselectRowAtIndexPath:[_tableView indexPathForSelectedRow] animated:animated];
}
- (void)viewDidAppear:(BOOL)animated {
[super viewDidAppear:animated];
[_tableView flashScrollIndicators];
}
Voilà, notre TableView est bien affichée par un contrôleur de type UIViewController, en respectant le guide de l’interface homme-machine pour iPhone d’Apple.