Blog d’un développeur multi-support

Bonjour, je recommence à développer sur iphone après quelques mois d’arrêt, j’en profite aussi pour tester l’Ipad (sur simulateur :p).

Cette semaine j’ai cherché à faire fonctionner une UISearchBar avec le controller qui va bien et j’ai eu quelque souci. Si techniquement c’est assez simple à mettre en place, graphiquement j’ai eu quelque souci.

Mon architecture :

Mon application a une UITabBar, puis sur une des sous vue j’ai une liste de résultat avec la SearchBar. Cet écran n’est pas  directement une UITableView, c’est un navigation controller qui contient une UITableView.

Ma UITableView est crée directement en code et est à hauteur fixe, et mes cellules ont une hauteur de 60:

1
2
3
4
5
6
7
8
9

- (void)viewDidLoad {  
	CGRect frame = CGRectMake(0, 75, 320, 262);
	// Initialise une table view.
	myTableView = [[UITableView alloc] initWithFrame:frame];
	myTableView.rowHeight = 60;
 
	// Ajout la tableView à l'écran et autres par la suite
 
}

Mes soucis

Les soucis viennent quand j’utilise la barre de recherche:

• Les cellules sont bien réutilisées mais la hauteur est celle par défaut du coup tout mes items sont mal placés. Joli bug graphique.
• Mes résultats sont bien filtrés, mais il est impossible de scroller. La liste revient toujours en haut. Comme si ma liste avait une hauteur tellement grande que le scroll était inefficace.

Solutions

Bon, j’en suis pas vraiment fier, ça tient plus de hooks qu’autres choses mais ça a le mérite de marcher et ça n’a pas l’air trop lourd en terme de performance sur mon 3GS.

En fait c’est simple, à chaque fois il faut refixer les hauteurs au moment oppertun.

• Pour les cellules, c’est à leur initialisation :
  ^?View Code C

  1 2 3 4

  - (CGFloat) tableView: (UITableView *) tableView heightForRowAtIndexPath: (NSIndexPath *) indexPath { return 60; }

• Pour la liste, c’est quand on lance une recherche :
  ^?View Code C

  1 2 3 4 5 6 7

  - (void)filterContentForSearchText:(NSString*)searchText scope:(NSString*)scope { CGRect frame = CGRectMake(0, 75, 320, 262); [[[self searchDisplayController] searchResultsTableView] setFrame:frame];   // faire sa recherche ensuite }

Donc en terme de performance y doit y avoir moyen de fixer ses tailles une fois pour toute mais je n’ai pas trouvé comment. Si quelqu’un a la solution je suis preneur.

J’espère que vous utilisé Doctrine car ce mini article pourrait vous plaire ! Quand vous débutez un projet, la partie conception BDD et création du fichier yml prennent du temps et on aimerait pouvoir faire tout d’un coup.

Personnellement je fais ma conception sur Workbench puis je repart « from scratch » pour faire mon (mes) fichier(s) yml. (Oui oui on peut en avoir plusieurs de yml :p).

Quand j’étais sur Propel J’avais perdu quelque cheveux quand j’avais essayé l’autre méthode (cad de générer le fichier SQL, l’insérer en base, et laisser faire symfony pour du reverse engineirng). Le souci du reverse c’est que ça produisait trop de code inutile (sur les foreign key par exemple) et au final repasser derrière pour arranger le model m’avait fait perdre pas mal de temps.

Hors ce soir j’ai trouvé, je ne sais comment, un plugin pour Workbench pour écrire le fichier yml directement à partir de celui ci, adieu les étapes « insertion bdd, reverse ». Et en plus sur les (mini) tests que j’ai fait tout à l’air propre, les conventions doctrines sont respectés, tout est bien indiqué. Il suffit de suivre la marche à suivre suivante : http://code.google.com/p/mysql-workbench-doctrine-plugin/wiki/WorkbenchPreparationForDoctrinePlugin

Bref, en un mot c’est bon plugin Workbench bien utile :p