Activités, Vues et Dialogues dans Android. Structure d'application correcte pour le jeu

Question

J'étais dans les moyens de bricoler dans Android avec le but d'essayer de faire ce petit jeu d'exploration. En fait, je suis assez loin jusqu'ici: un bon système de sprites, un écran de titre avec un menu principal qui est tout en code de jeu (pas de boutons d'interface utilisateur ou quoi que ce soit) qui lancent diverses activités. Une activité qui charge cette vue de carte sympa, qui, lorsqu'elle est cliquée, chargera une autre vue d'une partie plus détaillée de l'action «zoomée» d'une carte. Tout fonctionne plutôt bien mais maintenant je me demande comment je vais à ce sujet.

(Qu'arrive-t-il à une vue lorsque vous instanciez puis déplacez le contexte vers une nouvelle vue?) Je suppose que tant que l'activité est active, toutes les instanciations de diverses vues utilisées par une activité sont toujours bonnes. dans une activité onPause est quand id doit enregistrer les données qui sont changées dans ces vues pour persister l'état dans le cas où l'utilisateur quitte le jeu etc.?)

J'ai trois options de menu au début de la partie. La principale est:

Nouveau Jeu

• Le nouveau jeu, je lance ma carte principale activité qui peut lancer trois vues: Les deux premiers sont un écran de chargement pour le second, une carte écran.

• Troisième vue est une action plus détaillée orientée partie qui utilise ce sprite moteur que j'ai développé.

tout cela fonctionne assez bien que dans la vue de la carte vous cliquez sur une cellule, il indique l'activité d'appel par un auditeur pour commencer la vue d'action détaillé, et passe dans l'ID de la cellule (il sait ce que objets à charger dans la vue détaillée en fonction de la cellule cliquée en deuxième vue). (Cela m'a pris un peu de temps pour comprendre, mais quelqu'un a aidé ici sur une autre question pour obtenir ce.) Référence qui m'a aidé sur cette partie here. J'ai également utilisé les différentes informations ici sur ViewSwitcher.

J'ai même une boîte de dialogue oui non dans la deuxième vue qui demande s'ils veulent vraiment aller à cette cellule quand ils cliquent dessus, un oui indique à l'activité d'appel de définir la nouvelle vue. Ce qui m'a aidé à obtenir ce travail était cette référence here. J'ai également eu à jouer avec les appels à getContext et cela, je ne suis toujours pas sûr à 100% ce que getResources et getContext font pour moi.

Est-ce une mauvaise pratique d'appeler et de charger une boîte de dialogue à partir d'une vue? Si c'est le cas, alors je ne comprends pas comment si j'ai un événement dans la vue qui doit apparaître un dialogue comment je fais cela? Rappelez-vous à l'activité et laissez l'activité gérer la réponse de la boîte de dialogue, puis appelez une méthode sur la vue pour la réponse? Jusqu'à présent, tout cela fonctionne très bien, mais j'ai aussi appris à connaître les threads. Je génère un thread différent pour mon MenuView (gère la détection des clics et des réponses des boutons), ma vue CellMap qui gère la grande carte cool sur laquelle les utilisateurs peuvent cliquer pour voir la vue détaillée qui est ma vue SystemView.

Donc, fondamentalement, la liste des appels d'activité est comme ceci:

Home.Activity -> ScrollMap.activité qui écoute CellMap wher Ethe Oui/Non apperas dialogue (dans la vue de CellMap) et si la réponse est oui à la question, le onTouchEvent démarre la vue SystemView utilisant

    private CellMap.MapClickedListener onTouchEvent= 
     new CellMap.MapClickedListener() { 
     @Override 
     public void onMapClick(int id) {  
      setContentView(new SolarSystem(theContext,id));          
     } 
    }; 

Pour aider quelqu'un d'autre, cet écouteur devait être défini dans ma classe CellMap. Ensuite, dans l'activité ScrollMap lorsque je suis sur le point de démarrer CellMap, j'appelle une méthode à CellMap pour définir l'écouteur de clic de carte. Jusqu'à présent, c'est la seule façon dont j'ai pu obtenir des données à partir d'une boîte de dialogue (dans ce cas, il a été cliqué de manière à définir la nouvelle vue) sur l'activité d'appel. Est-ce une bonne pratique? Maintenant ma plus grande question est, j'ai une classe playerObject que je veux initialiser sur un nouvel événement de jeu (je sais comment détecter cette poussée) et qui est alors disponible pour n'importe quelle vue dans n'importe quelle activité pendant la durée de vie du cycle . Jusqu'à présent, l'activité de jeu a seulement deux (3 si vous comptez la barre de progression de chargement) vues. Je veux obtenir le nom des joueurs, est-ce une autre activité ou vue? Je ne peux pas trouver un tutoriel décent de la façon de faire une boîte de dialogue de saisie simple qui renverrait une chaîne.

Comment puis-je faire passer ces choses? Après avoir obtenu le nom des joueurs à partir de l'endroit où cette boîte d'édition doit être chargée, je veux définir le nom du joueur dans la classe et transférer cette instance vers une autre vue ou activité afin qu'ils puissent accéder à ces données. Tout ce que j'ai cherché sur ceci a semblé exagéré ou pas la bonne manière. Quel est le meilleur moyen de faire passer cette "classeClasse" pour que je puisse y accéder à partir d'autres vues (pour afficher le nom du joueur dans chaque vue).

J'ai aussi mon activité à la maison qui attend un onClick sur 3 boutons, puis lance leur activité qui montre la vue. Je me rends compte qu'un jeu continue et un nouveau jeu sont la même activité et vont juste changer dans les données chargées sur le disque pour restaurer un jeu de sauvegarde. Lorsque l'on clique sur le nouveau bouton de jeu, j'aimerais obtenir le nom des joueurs qu'ils veulent utiliser et, bien sûr, mettre le membre de la classe playerClass à ce nom pour qu'il persiste.

Où puis-je appeler (une boîte de dialogue d'édition?) Dans laquelle la boîte de dialogue d'édition? (plus sur comment puis-je en construire un qui peut prendre un bon bouton et l'entrée du clavier, etc). Id j'aime aussi le rendre joli, peut-être que je pourrais avoir une vue simple qui a une boîte d'édition dedans et un fond d'image gentil (bien que je n'ai pas compris comment placer les boîtes d'édition pour adapter bien un fond je dessine pour Je suppose que je suis comme une boîte de dialogue d'édition que je peux habiller pour regarder comment je le veux et adapter l'apparence du jeu).

Je suis en fait assez content de ce que j'ai obtenu jusqu'à présent, il ne semble pas trop mauvais, mais je ne suis pas sûr de certains détails comme obtenir une entrée de l'utilisateur pour un nom de joueur. Stocker cette information et la transmettre ensuite à d'autres activités et vues.

Est-il préférable d'avoir une activité GameMain, et une tonne de vues: Voir la carte Fiche caractère vue vue de l'inventaire, etc etc?

Ou devrait-il y avoir des activités diff quelque part aussi?

Answer 1

Vous avez beaucoup écrit ici, alors je vais aller de l'avant et répondre aux questions que vous me posez. D'abord, comment peut-on partager des informations entre les activités et les vues? Si vous ne faites que partager des vues dans une seule activité, stockez-la dans l'instance de la sous-classe Activity.

Le partage entre les activités nécessite un peu plus. Au lieu d'utiliser une instance de la classe Application par défaut, vous pouvez créer une sous-classe d'Application et l'utiliser à la place. Mettez vos données dans les champs de cette sous-classe.Pour dire à votre application pour utiliser votre sous-classe, de modifier le manifeste d'application comme ceci:

<application 
    .... 
    android:name=".YourAppClassNameHere"> 
    .... 
</application> 

Comme pour obtenir l'entrée d'utilisateur, la réponse simple est d'utiliser la vue EditText intégrée. Puisque vous semblez vouloir donner un style plus "personnalisé" à votre jeu, vous devrez peut-être créer votre propre zone de texte modifiable. Cela et les boutons devraient permettre la plupart des types d'entrée utilisateur de base.

Maintenant, bonne pratique vis-à-vis des activités et des points de vue. Je ne suis pas au courant d'une norme pour cela, mais lors de la conception, j'essaie généralement de considérer les activités comme des éléments plus conceptuellement séparés, alors que les vues sont inter-tissées conceptuellement. la ligne entre les deux dépend, en partie, de la portée de l'application; une application avec une focalisation étroite peut se permettre de répartir davantage d'actions en différentes activités que ne le ferait une approche beaucoup plus large. Votre exemple "GameMain" est un peu sur la clôture, mais je pense que vous avez fait le bon choix: l'activité est de "jouer le jeu", par opposition à un menu ou une table de scores élevés, et les vues présenter différents aspects du jeu en cours de lecture.