Projet Vidéothèque
Tiff
Membre
Un projet tout simple :
Une fenêtre avec un tableau à quatre colonnes : Titre du film, Réalisateur, Année, Disponiblité
Un tiroir avec des infos supplémentaires, notamment un deuxième tableau avec la liste des acteurs principaux.
Quelque part un champ de recherche.
Pour l'instant, pratiquement pas de code ! Tout par bindings.
Plus tard :
Une barre d'outils pour les boutons Ajouter un film, Supprimer, Rechercher.
Un deuxième tableau dans la fenêtre avec quelques réalisateurs incontournables ; on clique dessus et la liste de leurs films apparait.
Une fenêtre avec un tableau à quatre colonnes : Titre du film, Réalisateur, Année, Disponiblité
Un tiroir avec des infos supplémentaires, notamment un deuxième tableau avec la liste des acteurs principaux.
Quelque part un champ de recherche.
Pour l'instant, pratiquement pas de code ! Tout par bindings.
Plus tard :
Une barre d'outils pour les boutons Ajouter un film, Supprimer, Rechercher.
Un deuxième tableau dans la fenêtre avec quelques réalisateurs incontournables ; on clique dessus et la liste de leurs films apparait.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Peut-être pourras-tu nous faire part de l'avancée du projet, avec des snapshots des grandes étapes ?
Au passage, je me demande si ça ne serait pas plus adapté au web ça. D'ailleurs les sites spécialisés dans le cinéma existent déjà.
J'ai deux questions :
Peut-on s'échanger des dossiers à travers le forum ?
Quelle est cette histoire de ZeroLink qui permet ou non à tout un chacun de lancer une application créée par d'autres ?
Je peux activer l'échange de pièces jointes pour le forum... :-)
Taille max du fichier : 1 Mo.
D'autre part, si vous ne l'avez pas vu, je vous conseille d'activer les réponses rapides dans votre profil, ce qui ajoute un champ pour répondre directement en bas des messages.
J'ai pour l'instant deux versions de Videothèque :
0.1 avec uniquement l'interface
0.2 fonctionnelle (23 lignes de code !)
et bientôt
0.3 sauvegarde des données dans un fichier
0.4 fonctions de recherche simple
puis
0.5 recherches complexes
Il ne s'agit pas de faire un inventaire de tous les filmes existants, mais seulement de gérer ma vidéothèque perso (ma dvdthèque perso dès que j'ai reçu mon SuperDrive !).
De plus, c'est une appli aisément transformable. Je vais m'en servir pour gérer toutes mes listes qui sont pour l'instant dans des tableurs AppleWorks, en ajoutant à chaque fois quelques fonctionnalités.
Pour ptit bras :
Voici les trois états successifs de mon projet
Vidéothèque 01 ne contient que l'interface (provisoire) du projet.
Vidéothèque 02 permet en quelques lignes et quelques "bindings" de créer une appli fonctionnelle
Vidéothèque 03 permet de sauver et récupérer ses données.
Mode d'emploi :
vérifier que les dossiers sont en lecture-écriture.
ouvrir videotheque.xcode
un coup de build and run et c'est parti
J'ai essayé de mettre quelques indications dans un fichier Lisez moi, mais c'est plus un aide mémoire perso que des aides pour débutant.
J'ai commenté, suffisamment j'espère, le code.
Dans Interface Builder, tout est dans la fenêtre Info et dans la fenêtre des instances; il faut savoir jouer avec pour découvrir tous les liens entre les objets. Mais là, on entre dans le champ d'un autre forum.
Une précision : en tant que programmateur débutant et très occasionnel, je revendique le droit à l'erreur. Je me suis très largement inspiré de multiples tutoriels, et mes applis fonctionnent. Néanmoins elles ne sont certainement pas des exemples à suivre aveuglément. Il y a sans doute des horreurs dans mon code, mais je m'en f?, tant que ça marche !
Par contre, les conseils sont les bienvenus ! ;D
Mais j'ai pu envoyer des images et des txt...
[Fichier joint supprimé par l'administrateur]
Videotheque 01
[Fichier joint supprimé par l'administrateur]
[Fichier joint supprimé par l'administrateur]
Attention, il faut créer un dossier ProjetVidéothèque dans son dossier Bibliothèque, sinon la sauvegarde va planter l'appli. On peut changer facilement le chemin dans le fichier AppliControleur.m (le chemin apparaà“t 2 fois dans le code).
[Fichier joint supprimé par l'administrateur]
Dis moi, pour avoir une table avec des lignes blanches/bleues et non simplement blanches, tu coches quoi ds IB ?
A mon avis, Interface Builder rentre tout à fait dans le cadre de ce forum. Le code Objective-C et tout les liens avec l'interface sont deux choses indissociables pour moi.
http://www.macbidouille.com/niouzcontenu.php?date=2004-05-27#8641
J'ai vu que dans ta méthode - init tu commentais:
Au cas où ce serait vraiment une question, la réponse est que certains objets peuvent renvoyer nil en réponse à init si l'initialisation échoue (dans [super init]) et libérer toutes les allocations déjà effectuées. Tester si self n'est pas nil permet de ne pas poursuivre avec un objet inexistant ou malformé.
Désolé si j'enfonce une porte ouverte.â€
Bonne continuation.
Mais dans mon cas où super est NSObject, pourquoi l'initialisation se passerait mal ?
Si l'initialisation se passe mal, que se passe-t-il alors ? L'appli est bloquée ?
Pourquoi, si j'omets la ligne self = [super init], l'appli tourne quand même ?
Je pense que si l'initialisation se passait mal, au mieux tu aurais un objet dont certaines variables d'instance ne sont pas allouées et qui risqueraient donc de causer un crash si une fonction essayait d'y accéder sans autre précaution. Ou cela laisserait l'objet dans un état supposé impossible ou aberrant.
Je pense que si tu peux omettre la ligne self = [super init] sans "casser" l'appli, c'est parce que dans ce cas la méthode init de la super classe n'alloue rien ou ne fait rien que tu utilises par la suite (mais c'est pure spéculation de ma part! Si quelqu'un connaà“t les détails, je suis intéressé aussi!). Toutefois, même si ton application fonctionne sans appeler [super init], c'est dangereux de laisser une classe sans cet appel. En effet, si un jour tu dérives une sous-classe de ta classe actuelle, celle-ci fera peut-être appel à des données de la classe de base qui ne porront pas être initialisées puisque ta première classe aura rompu la chaà“ne d'inititialisation. Du coup, ta première application qui utilise seulement ta première classe peut fonctionner, alors que la seconde ne fonctionnera pas, à cause d'un bug dans une classe qui "marchait auparavant".
En résumé, je crois qu'il vaut mieux utiliser dans le cas général les appels et les tests qui seraient inutiles dans un cas particulier: le temps perdu à l'exécution sera négligeable et on se met à l'abri de bugs bien difficiles à traquer quand on est descendu assez loin dans un arbre de classes...
(plus d'infos à ce sujet dans "The Objective C Programming Languge", pages 92 et suivantes: http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/index.html#//apple_ref/doc/uid/TP30001163)
Je suis d'accord pour prendre de bonnes habitudes, à condition qu'elles soient vraiment utiles. J'avoue que j'omets très souvent le (if self). Par contre le (self =[super init]) me parait extrêmement important.
Et mon Videotheque.zip, il est passé où ?
[Fichier joint supprimé par l'administrateur]
Un deuxième tableau dans le tiroir, avec encore quelques bindings.
Comme j'ai modifié la classe Film, l'ancien fichier VidéothèqueData ne sera plus lisible. Il vous faudra donc l'effacer manuellement.
[Fichier joint supprimé par l'administrateur]