TP/projet : réflexion préalable

bonsoir
J’ai terminé le cours de base (le bleu) “Apprendre à créer des apps pour iphone” et je souhaite tenter une mise en application dans un petit projet en utilisant une tableView.

Je vais avoir besoin de vos éclairages pour avancer car beaucoup de choses sont encore obscures pour moi.

Je pense qu’avant toute chose, il est nécessaire de faire un point sur le projet afin de ne pas partir vers n’importe quoi.

Alors voilà !

Le projet se décline sur 3 écrans :

  • un écran A affiche des listes nommées contenant des mots (liste A avec des mots en A, liste B avec des mots en B, liste C avec des mots en C, etc…) ; je compte donc utiliser une tableView pour cela avec un titre (liste A…) et un sous-titre contenant les 1ers mots.
  • selon le système MVC, je prévois une classe contenant ces listes dans un fichier .swift à part. C’est bien cela ?

2è question : Il faudra un tableau avec les mots et un tableau avec le nom des listes pour pouvoir les afficher dans la tableView ?

  • un écran B qui affiche les mots selon la liste choisie sur l’écran A. Je fais cela comme dans le cours, à priori (j’en ris d’avance :wink: ) pas de problèmes.

  • un écran C : celui-ci utilisera les mots de la liste choisie en A et affichés en B. L’activité de l’utilisateur consistera à recopier un des mots de la liste qui s’affichera, puis à passer au mot suivant, et ainsi de suite, jusqu’à épuisement de la liste.

Ma question : comment indiquer à l’écran C la liste choisie par l’utilisateur et donc utiliser seulement les mots de cette liste ?

Dans ce 1er projet, je ne prévois pas que l’utilisateur puisse lui-même faire ses listes de mots. Il ne pourra qu’utiliser celle déjà entrées par Bibi :wink:

Avant de me lancer dans ce projet, pensez-vous qu’il y a d’autres aspects à anticiper ?

merci pour votre aide.

Fanfan

Hello Fanfan,

Tu peux expliquer un peu plus en détail le but de ton application ? Ou alors le parcours que l’utilisateur aura dans ton app ?

Pour ce qui est du passage de l’écran B à l’écran C, à priori, si j’ai bien compris, ça se fait assez simplement au moment de la segue. Tu définis ton écran C comme écran de destination, dans le ViewController de ton écran C, tu définis les variables que tu auras à récupérer de ton écran B et tu les passes au moment de la segue.

@schtipoun Oui, en effet, ce n’est pas très clair.

C’est une activité pour apprendre à écrire des mots.

L’utilisateur arrive sur l’écran A et choisit la liste des mots qu’il veut étudier. Comme il ne peut voir dans la tableView que le début de la liste de mots (il y en aura de 10 à 15 à chaque fois), lorsqu’il clique sur cette liste, l’écran B s’ouvre et affiche la totalité des mots de la liste sélectionnée.

L’utilisateur peut alors valider en cliquant un bouton qui le dirige vers l’écran C pour l’activité. Il s’agira de recopier les mots qui apparaitront un à un.
L’écran C doit donc récupérer le choix de la liste effectué sur l’écran A pour travailler avec ces mots uniquement. Il n’a pas besoin de tous les afficher d’un seul coup, au contraire, il faudra qu’il les récupère un à un.

Voilà, j’espère avoir été plus clair.

Utilise une base de donnée (Realm ou Firebase, facile à exploiter) :
Tu la construis de la façon suivant : mot, catégorie…
Appprendre → verbe
Coder → verbe
Reflechir-> verbe
… etc

Tennis → sport
Rugby → sport
Escrime → sport
… etc

Courgette → aliment
Tomate → aliment
Oignons → aliment
… etc

Cela te permettra de charger tes tableviews très facilement.

Tu déclares une :

class WordManager {
// exemple de filtrage avec une base de donnée Realm: let foodList : Results = realm.objects(Word.self).filter(« catégorie == aliment »)
}

Cette réponse est une piste pour t’orienter vers une façon de faire. Je suis sur mon iPhone donc un peu compliqué d’expliquer plus en détail.

Le principe est de déclencher une fonction avec la tableview A qui va filtrer ta base de donnée pour n’affiche dans la table view B que les résultats correspondant.

N’hésite pas à me demander de clarifier mon idée si besoin. Je prendrai le temp sur un ordi pour répondre.

C’est une idée intéressante Alexandre, mais je n’ai pas encore étudier les bases de données.
L’idée de départ était de construire un projet à partir du cours du1er niveau que j’ai terminé.
Mais si l’utilisation d’une base est vraiment bénéfique, ce peut être aussi l’occasion pour moi d’avancer dans le cours. :+1:

N’hésite pas à me demander de clarifier mon idée si besoin.

Je veux bien d’autres précisions si tu as un peu de temps.

Comme le dit @alexandre.cane, l’utilisation d’une base de données me paraît assez indispensable (surtout si tu veux rajouter des mots au fur et à mesure).
Car si tu stockes tout sur le téléphone, tu seras obligé de faire une mise à jour à chaque fois que tu veux rajouter des mots et c’est donc un peu contraignant.

Et pour la partie projet, c’est encore plus simple que ce que je croyais (tu n’as même pas besoin de faire passer des paramètres en segue puisque tu liras tout depuis la base de données).

J’imagine un truc un peu comme ça, dis moi si je me trompe (bon, c’est fait rapidement, hein :wink: )

Tu peux commencer avec des tableaux standards pour rester dans le cadre de ce que tu as déjà abordé, mais @alexandre.cane et @schtipoun n’ont pas tord en disant que sur le long terme tu seras plus à l’aise avec une base de données.
Mais pour le moment tu peux commencer avec des tableaux sans problème.
Quand tu es sur le point de faire une transtion de ton écran A à ton écran B, utilise la fonction prepareForSegue pour faire passer le bon tableau à l’écran B (le tableau sélectionné par l’utilisateur), puis même chose de l’écran B à l’écran C.
Ainsi tu auras bien récupéré les informations de ton écran A dans ton écran C.

C’est Balsamiq mockups ? :slight_smile:

C’est Balsamiq mockups ? :slight_smile:

Tu as l’oeil :wink:

1 « J'aime »

Je ne connais pas. C’est pour faire des maquettes visuelles ?

C’est pour faire des wireframes oui. C’est à peu près la première étape quand tu définis tes users stories, ça te permet de dessiner les écrans “grossièrement” et de repérer les premiers couacs avant de passer sur des designs plus approfondis.
Ça peut aussi servir à présenter l’application dans les premières semaines du projet sans avoir, encore une fois, à trop investir dans le design.

Bref, c’est souvent l’étape qui suit le dessin d’écrans à la main sur le papier :slight_smile:

J’avais fait mon mémoire de fin d’études sur l’ergonomie logicielle et j’avais passé pas mal de temps avec Balsamiq, je l’aimais beaucoup ce logiciel :+1: