Données de données non-core dans un UITableView soutenu par des données de base

Question

Jetez un coup d'œil à Music.app (ou iPod.app). La vue Albums racine comporte une ligne "Toutes les chansons". La vue des morceaux racine a une rangée "Shuffle". La vue Racines des playlists a une ligne "Ajouter Playlist ...". Données statiques mélangées dans la même UITableView avec (probablement) des données de base. Je me demande comment Apple a réalisé cela.

J'ai essayé deux approches différentes, les deux ont échoué. Comme le Music.app, mes vues ont aussi un UISeachBar dans la tableHeaderView. Ma première tentative a tenu compte du nombre de lignes "statiques" que j'avais et ajusté l'indexPath fourni aux diverses méthodes UITableView et NSFetchedResultsController qui nécessitent des informations de section et de ligne. Tout fonctionnait parfaitement jusqu'à ce que j'implémente les méthodes NSFetchedResultsControllerDelegate pour permettre la création, l'édition et la suppression. La méthode insertRowsAtIndexPaths:withRowAnimation: (et similaire) est déclenchée sur mes indexPaths ajustés. Les indexPaths par défaut ne fonctionnent pas comme l'est non plus.

Ma seconde tentative a consisté à imbriquer un autre UITableView dans la tableHeaderView de mon UITableView primaire à utiliser pour les lignes statiques (et à héberger le UISeachBar dans son propre tableHeaderView). Cette approche ne l'a même pas rendu à la phase éditable. L'UISearchBar finit par être chevauché par l'épurateur de sectionIndex racine de UITableView et ne glisse plus derrière l'UINavigationBar lors du défilement d'une liste courte.

Donc, plutôt que de diagnostiquer mes problèmes spécifiques, je demande des suggestions sur la façon dont Apple réalise cela. Pourraient-ils extraire les données une fois, les mettre en cache dans un NSArray et construire un NSArray imbriqué de sections et de lignes qui inclut à la fois les lignes statiques et les données de base?

Answer 1

J'ai récemment rencontré ce même problème. Je voulais ajouter une rangée en haut de la table avec du contenu statique (Toutes les chansons). J'ai contourné le problème en insérant simplement ma propre section pour la section 0, puis en incrémentant les sections de données de base. 0 devient 1, 1 devient 2, etc.

- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView { 
    return [_fetchedResultsController sections] + 1; 
} 

- (NSInteger)tableView:(UITableView *)tv numberOfRowsInSection:(NSInteger)section { 
    if(section == 0) { 
     return 1; 
    } 
    id <NSFetchedResultsSectionInfo> sectionInfo = [[_fetchedResultsController sections] objectAtIndex:section-1]; 
    return [sectionInfo numberOfObjects]; 
} 

- (UITableViewCell *)tableView:(UITableView *)tv cellForRowAtIndexPath:(NSIndexPath *)indexPath { 
    // All Charts 
    if(indexPath.section == 0 && indexPath.row == 0) { 
     // Set up the custom cell 
    } 
    // Sets 
    else { 
     // Set up the core data cells 
    } 
} 

Le reste est juste une question de réglage des sections de indexPath lors de la suppression des lignes et autres.

Answer 2

C'est ce que je ferais (construire mon propre cache). La ride de votre application par rapport à iPod.app semble être le bit NSFetchedResultsControllerDelegate. Je ne pense pas iPod.app offre cette interface particulière, non? Donc, pas de création/modification/réorganisation automagical.

Comme vous l'avez vous-même déclaré, il a été ajouté que cela a causé votre indexPath en train de s'arrêter de fonctionner.

Je pense que vous aurez juste à rouler la main. Cela semble assez typique des API d'Apple: une fois que vous vous êtes écarté des cas d'utilisation simples, leur fonctionnalité pratique commence à rencontrer des problèmes. Vous devriez déposer des bugs dans bugreport suggérant comment vous souhaitez que cela fonctionne - espérons qu'ils vont venir avec quelque chose dans le futur, car cela semble être un cas d'utilisation que d'autres pourraient rencontrer. En outre, je ne sais pas si vous devez aller jusqu'au stockage dans NSArrays, mais si vous le faites, mettez en page vos extractions et cachez seulement ce qui est nécessaire dans la RAM si l'ensemble peut devenir vraiment grand.

J'ai une application photo simple sur laquelle je travaille et le cache est soutenu par quelque chose qui fonctionne efficacement comme un curseur. Pour l'instant, je garde tout en mémoire, mais les détails sont cachés derrière une interface que je vais pouvoir refactoriser assez facilement. L'interface ressemble à un tableau, mais elle sait automatiquement aller sur le réseau pour extraire des ensembles de résultats supplémentaires, les mettre en cache dans CoreData et mélanger les résultats de différentes pages. Donc, mon délégué UITableView fait juste [cursor objectAtIndex: blah] et la magie est cachée derrière les scènes. C'est très faisable.

Sujal