SOCIALHORTIS

On ne dément pas le succès de l’IPad, et Hortis a su s’imposer comme un acteur majeur en Suisse pour le développement sur cette plate-forme.

Le carnet de commandes est plein. De grands noms de l’horlogerie et de la banque ont notamment fait appel à Hortis Le Studio pour évaluer les capacités de ce nouveau terminal, et l’intégrer au plus prêt de leur métier. De même des fédérations sportives internationales, le Touring Club Suisse ou des laboratoires pharmaceutiques, collaborent avec Hortis sur cette technologie.

Porté par le succès de ses réalisations sur IPhone, Hortis a pris le virage IPad avec une longueur d’avance.

Rançon du succès, l’équipe ne cesse de s’étoffer, s’offrant la collaboration de personnes d’expérience, tant dans la mobilité, le design que dans le monde Apple.

Pensons à eux qui, pour assurer la réussite des projets, remettront leurs vacances à plus tard.

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.

Source : Table View Programming Guide for iPhone OS

C’est de plus en plus fréquent lors d’un développement de site web : les clients demandent que leur site soit consultable à partir d’un mobile, en particulier à partir d’un iPhone qui représente un volume de plus en plus important dans le trafic d’un site.

Voilà un logiciel qui répond exactement à ce besoin : iPhoney n’est pas un “simulateur”, mais il permet de visualiser n’importe quel site sur l’écran d’un iPhone (résolution 320×480), même si on n’a pas de “vrai” iPhone sous la main.

iPhoney permet aussi de tester plusieurs User-Agents, ainsi que l’affichage en mode portrait et paysage. Et cerise sur le gâteau : Il simule également le non-fonctionnement des animations flash…

En théorie, sachant qu’iPhoney utilise le moteur Safari de votre Mac, le résultat devrait être très proche de ce qu’on peut voir sur un vrai iPhone, mais dans la pratique on peut remarquer de petites différences (cf ci-dessous). Mais le but est juste de détecter des bugs d’affichage, pas forcément d’avoir un iPhone dans une fenêtre Mac…

iPhoney est disponible pour MacOS, téléchargeable gratuitement chez MarketCircle.com

PS : pour ceux qui ne sont pas sous MacOS, vous pouvez essayer Air Phone qui fonctionne sur le même principe qu’iPhoney, mais sous Adobe Air.