Problème tableView cellForRowAtIndexPath

[malabar63]

Bonsoir tout le monde,

Je suis débutant en développement iOS et je rencontre un problème.
Je veux développer pour m'entrainer une application genre VDM, mais très simple. Il y a 3 vues (dernières, best of et aléatoire). J'ai un fichier XML avec quelques blagues.
J'ai créé un projet tabBar. Mon tabBarController est relié à mes 3 views. Sur la première j'ai mit une Table View. J'ai créé le IBOutlet dans le .h du fichier controller correspondant héritant de UIViewController, et je l'ai relié au TableView dans mon storyboard.
J'ai ensuite créé ma fonction "tableView cellForRowAtIndexPath" et mis des breakpoints, mais mon programme ne passe pas dedans, donc pas moyen d'afficher les résultats. Par contre je récupère bien toutes les blagues.
Le problème ne viendrait-il pas du fait que mon controller de vue n'hérite pas de TableViewController?

Qui aurait une solution à ce problème?

Merci d'avance.

 

[tatouille]

setDelegate -> attention weak
setDatasource -> attention weak

UITableView
UITableViewDataSource
UITableViewDelegate

élève dissipé, doit se ressaisir d'urgence.

 

[malabar63]

Bonnre réponse,

Merci, ça m'a bien aidé.
Du coups il faut lier le files owner au datasource ainsi qu'au delegate.

 

[tatouille]

tu peux le faire dans le code at your option, evite d'avoir un seul objet,

un controller, un data source, un UI delegate est la construction recommandée tu comprendras plus tard... pourquoi il faut tout de suite adopter ce design et surtout arreter urgemment de copier betement les exemples fournis par Apple qui sont sur le telephone/pad de tres tres mauvaises qualités

 

[Rez2a]

tu peux le faire dans le code at your option, evite d'avoir un seul objet,

un controller, un data source, un UI delegate est la construction recommandée tu comprendras plus tard... pourquoi il faut tout de suite adopter ce design et surtout arreter urgemment de copier betement les exemples fournis par Apple qui sont sur le telephone/pad de tres tres mauvaises qualités

Ça ça m'intéresse, si tu peux être un peu plus précis sans m'envoyer chier...

Dans la plupart des bouquins sur Cocoa Touch et dans les examples d'Apple, il me semble toujours avoir vu le même objet qui était à la fois un UIViewController incluant une UITableView et qui était en même temps son delegate et dataSource en implémentant les protocoles correspondants.
En quoi c'est déconseillé comme approche ?

 

[tatouille]

short OOP

pour ne pas finir avec un controller qui est a la fois le model et la vue, pour pouvoir changer de datasource utilisant le meme controller, pour gérer des constructions automatisées comme les paginations (remote data, grouper/degrouper, tabulation, sub tabulation, ordering, filters differentes cells et cetera), avec un controller tu peux gérer 30 tableviews en 10 lignes, une class de plus de 600 lignes/ la plupart de mes class meme en c++ n'excedent jamais 300 lignes avec retour ligne et vendor-header (voir OOP), n'est plus une class mais un dépotoir, cela veut dire que le truc, est a la fois boulanger aviateur et president de la république, c'est pour cela que la personne qui a écrit cette objet la fait (et avait en tete ce qui suit)

un code concis, compact et correctement inlined est un code rapide a executer, rapide a optimiser, rapide a faire évoluer (par toi ou autres personnes), bug free, quand j'ecris une classe c'est pour qu'elle soit toujours vraie dans 10 ans, moralité je code avec ma tete et pas mes doigts, je suis sur qu'avec mes classes je construit la meme app que toi en 10 fois moins de temps et 200 fois plus optimisées (ce qui me laissera le temps d'ajouter 400 cerise sur le gateau et etre sur de vendre), apres tout c'est le pourquoi de l'OOP, pour preuve la fondation d'Apple certains Objets sont la depuis le debut de Next et ont evolué rapidement sans trop d'effort gardant meme une large compatibilité, on en revient a cet exemple populaire: je peux faire un simple web-browser en une ligne de code.

moralité quand je code une app il y a au maximum une 10eme de class qui soient application specifique, a chaque fois que j'ai besoin d'un traitement generique, je cree le traitement generique et le place dans l'une de mes framework appropriées qui ont elle meme de nombreux utilitaires ce qui rend l'implementation du nouveau concept tres rapide, optimisé et bug free, je produit tres rarement des bugs la pluspart du temps quand je suis fatigué et sont immediatement identifiable, pourquoi? la méthodologie (le gout de l'effort et d'apprendre ce qui est devenu chose rare une generation de fonctionnaire mercenaire), la clareté du code donc de la pensé je release toujours en -Wextra -Werror et je ne sleep jamais un thread j'utilise Producer/Consumer c'est du baba mais la plupart des apps qui crashent c'est directement liée a la violation de ce modele pourtant tres simple.

je ne peux pas donner de nom mais des applications tres complexes et populaires sur lesquelles j'ai travaillé sont nées en moins de 2 semaines pour la premiere version (petite equipe 2/5 graphisme inclus, ui polissé (je suis tres chiant avec ce point aussi)), donc tres bien vendues.

welcome chez les ingenieurs , il y a beaucoup d'employés avec ce titre, tres peu le sont en faite, voila un peu de pourquoi de la chose qui pour moi me semble t-il devrait etre naturel dans la tete d'un ingenieur.

moralité: ce n'est pas parce ce que quelqu'un fait un commentaire pittoresque et idiot sur Platon, que Platon en est l'auteur et somme toute que ce commentaire dépasse et remplace sa pensée, il n'est pas, non plus responsable des 3000 idiots qui suivent et déforment encore plus la source corrompue, ce n'est parce que l'idiot est légion qu'il a raison.

exemple: