Je construis actuellement une application iPhone à onglets où chaque contrôleur d'affichage de l'onglet est une instance de Voir comme Apple dit dans leur documentation sur iPhone que l'on ne devrait pas sousclure merci! uinavigationcontroller , et où chaque sous-groupe de chacun des uinavigationController est un instance de utablevoller . Idéalement, je voudrais sous-classe uinavigationcontroller de sorte que le contrôleur de chaque onglet soit une sous-classe d'uoinavigationController qui (en plus de disposer de la fonctionnalité uinavigationController , évidemment) sert En tant que DataSource et le délégué pour chacune des vues de table associées à ses sous-performants. Essayer de faire cela semble casser la fonctionnalité de base uinavigationcontroller dans la sous-classe.
UinavigationController , et les choses semblent briser quand on le fait, je me demande comment je devrais aller sur l'extension de uinavigationController < / Code> Fonctionnalité sans sous-classement et d'une manière générale, comment il faut travailler autour des limitations de sous-classement lors du développement de cacao.
6 Réponses :
Parce qu'ils veulent éviter l'incohérence de l'interface utilisateur qui affrit chaque autre plate-forme.
Pourquoi sur Terre voulez-vous que le uinavigationController agisse comme une source de données pour la table? L'ensemble du point de utableviewController est-ce que vous sous-classez-le, et il agit en tant que DataSource pour le utableview qu'elle place également dans, et remplit, la vue parent.
D'accord. Dans ce cas, Apple vous permet de faire une décision de conception terrible. Si vous croyez vraiment que vous avez une bien meilleure idée, vous êtes libre d'écrire vos propres contrôles à partir de zéro.
Cette. Il n'y a pas de raison sain d'une sous-classe UinavigationController. UinavigationController ne contrôle pas réellement aucune UI modifiable réelle. L'ensemble du point de vue de la table est que le contrôleur de vue de la table contrôle le contenu. Vos contrôleurs de vue de table doivent être ce qui adapte les données de sa vue de modèle à la vue Table. De plus, un seul contrôleur contrôlant une bande de vues de table différentes sur un tas de vues de table différentes sonne comme une catastrophe en attente de se produire. Je recommanderais contre cela non pas à cause du sous-classement, mais cela ressemble à la manière la plus compliquée.
Si je comprends bien, le sous-classement n'est pas encouragé car l'objectif C permet une sous-classe une sous-classe d'accès au fonctionnement interne de sa superclasse.
L'alternative suggérée à la rédaction d'une sous-classe est d'écrire un délégué, dans ce cas une uoinavigationControllerdelegate. Vous pouvez ensuite encapsuler le comportement spécifique que vous souhaitez étendre dans cette classe de délégation et le lier à l'UinavigationController à chaque fois que vous en avez besoin.
Si l'héritière du contrôleur disponible ne répond pas à vos besoins en termes de traitement des données (mon hypothèse, car nous ne savons pas pourquoi vous voulez que un objet soit la source de données pour plusieurs vues), vous pouvez toujours créer des données supplémentaires et / / ou des classes de contrôleur (sous-classes de NsObject au moins).
Vous pouvez avoir une donnée ou un autre objet persistez lors de la modification des vues de différentes manières. (1) une propriété de votre classe de délégués d'application. Tout objet de votre application peut obtenir votre instance de délégation de l'application avec P>
[[UIApplication sharedApplication] delegate]
Je vais aller de l'avant et dire que votre idée a du mérite, si à chaque niveau, vous utilisez vraiment le même type de données et que chaque niveau a peut-être un délégué différent de gérer la création cellulaire.
Fondamentalement, il n'y a pas de raison pour laquelle vous ne pouvez pas sous-classer le contrôleur d'uoinavigation pour ajouter une couche totalement orthogonale de données, car elle n'a rien à voir avec l'interface utilisateur ou le comportement que UINAVIGATIONCONTROLLER est géré (qui est ce qu'est la pomme vous inquiète de jouer avec ). À ceux opposés à l'idée, pensez-y sous la forme d'un magasin de données par onglets que toutes les pages d'un onglet peuvent accéder au lieu de chaque page du système devant aller à l'Appdelegate ou avoir une bande de singletons. Eh bien, fondamentalement, c'est un singleton, mais au moins un qui est déjà là et obtient la référence transmise automatiquement.
Tout ce qui dit, je me terminerai par une proposition de conception alternative - je pense que ce que vous voulez probablement faire est d'explorer de multiples couches réutiliser le même code à générer des cellules et que vous avez les mêmes types de données à Chaque couche. Une meilleure approche de la manipulation consiste à avoir un contrôleur d'affichage que vous nourrissez le sous-ensemble de données à afficher, et lorsqu'un utilisateur percent simplement, il crée simplement une autre instance du même contrôleur d'affichage avec ce nouveau sous-ensemble de données. Cette approche est bien meilleure que l'idée d'avoir le contrôleur de navigation agir en tant que déléguée de table pour chaque niveau, car vous devriez faire une tonne de reconstitution de retour d'avant en arrière et qu'il faudrait encore plus de travail à se souvenir de la position de défilement à chaque niveau à démarrer. C'est pourquoi vous souhaitez conserver des forages en utilisant plusieurs instances de contrôleurs d'affichage, mais plusieurs instances n'ont pas à signifier plusieurs classes.
Entendu. Merci pour la clarification et la proposition.
Pour référence, notez que, puisque iOS 6, UinavigationController peut être sous-classée légalement .
Cette classe est généralement utilisée comme-objet mais peut être sous-classée dans iOS 6 et plus tard.
Référence de classe UinavigationController
Bien sûr, cela ne signifie pas que vous devriez toujours. Mais vous pouvez.
J'étais curieux de cela moi-même, et je vois que la documentation d'UinavigationController d'Apple indique désormais "cette classe est généralement utilisée comme celle-ci mais peut être sous-classée dans iOS 6 et plus loin."