A DroidFociban bevett szokás volt a kliens nézetét cserélgetni. Ez akkor vált kellemetlenné, amikor a nézetben összetett viselkedést implementáltunk - lásd a korábbi bejegyzést. Mit szabad és mit nem szabad megtenni a nézetekkel? Mikor és hogyan lehet egy Activity-hez több nézetet rendelni, mikor használjunk inkább új Activity-t, és mihez elég egy egyszerű dialógus? Hogyan valósítsunk meg egy beállítás-szerkesztő felületet? Ezekre a kérdésekre kerestem a választ. Engedjétek meg, hogy megosszam az eredményeimet!
Az View setContentView metódussal való cseréje nem ajánlott. A hagyományos MVC szemléletnek teljesen megfelelő gyakorlatot, mely szerint a modell fölött lecseréljük a nézetet, ha az szolgálja céljainkat, úgy tűnik ebben a formában nem támogatja az Android. Több fórumon számoltak be kellemetlen mellékhatásokról a módszer alkalmazásakor. Ha különböző nézetek tartoznak az Activity-hez, akkor a FrameLayout-ot alkalmazhatjuk több nézet megjelenítésére ugyanazon területen. (Ezt ilusztrálja a mellékelt kép, a három gomb egy FrameLayout-on foglal helyet).
Az Android framework több alosztályát kínálja a FrameLayout-nak, ezek a TabHost, a ViewSwitcher és a ViewFlipper. A TabHost-ot be sem kell mutatnom, ez a JTabbedPane Androidos megfelelője. Érdekesebb azonban a másik kettő, hiszen ilyennel nem találkoztunk a J2SE-ben (bár a FrameLayout tagadhatatlan hasonlóságot mutat a JLayeredPane-nel). A ViewSwitcher két nézet közti, a Flipper tetszőleges számú nézet közti váltást tesz lehetővé futási időben rejtve el a nem használt nézeteket. A háttérbe kerülő View-kat GONE állapotba küldi, így azok akkor sem látszanak, ha nagyobbak a "fölöttük" lévő View-knál. Az előtérbe került View értelemszerűen VISIBLE állapotba kerül. Ha a nézetek ekvivalensek, és csak a megjelenítést szolgálják, akkor ez a megfelelő eszköz a nézetek cseréjére. A komponens által elfoglalt hely a választásunk szerint lehet mindig a megjelenített nézetnek megfelelő, ennek előnye, hogy a felületünkön nem jelennek meg üres foltok, de figyelembe veheti az éppen nem látható nézetek méretét is, ekkor nem esik szét a kicentizett felület, ha azt a legnagyobb komponenshez szabtuk. Ezt a FrameLayout setMeasureAllChildren() függvényén keresztül szabhatjuk meg.
Ez a megoldás alkalmas tehát mondjuk arra, hogy egy felhasználói profilnál váltsunk a képes vagy tömör megjelenítés közt, vagy mondjuk egy térképes vagy szöveges útbaiazítás közt. Nem tehetünk akkor sem mást, ha két külömböző elrendezés közt szeretnénk váltani, például egy játékban van egy védekező meg egy támadó felhasználói felület, melyeken keresztül ugyanazok a funkciók érhetőek el, csak más elrendezésben. Ezért nem megfelelő eszköz egy beállítás-ablak elkészítésére, nem illik ez a funkció a ViewFlipper szellemiségébe.
Mit tud ehhez képest a Dialog, ami meglepő módon nem is a View leszármazottja? Ha nem tekintjük szolgáltatásnak azt, hogy a dialógus körül átsejlik a mögöttes alkalmazás, akkor mindent, amit meg lehet dialógussal oldani, megoldhatunk ViewFlipper-rel. De a Dialog sok mindenre kényelmesebb. Természetesebb a használata, hiszen egy újabb rétegként kerül az alkalmazás fölé, így a vissza nyíl használata magától értetődik. Minden dialógusnál eldönthetjük, hogy újrahasznosítjuk, vagy friss példányt kérünk belőle, azzal, hogy töröljük a removeDialog() metódussal. A dialógus alkalmas lehet egy beállítás-ablak létrehozására, hiszen tetszőleges elrendezést adhatunk neki, kaphat saját opció menüt (ezzel érdemes is élni, főleg, ha az opciómenüből érhető el a beállítás dialógus, ha működési zavart nem is okoz, de bután néz ki).
Mikor érdemes ezek után mégis Activity-t hozni létre néhány beállítás szerkesztése végett? Amikor a beállítások szerkesztése módosítja az alkalmazás állapotát. Egy szívemhez közel álló példán keresztül szeretném elmagyarázni, mire is gondolok: a DroidFociban a beállítások piszkálása közben könnyedén lőhetünk akár öngólt is, hiszen elég kicsit megdönteni a telefont, és már neki is iramodik a játékos a saját kapu felé. A beállítások szerkesztéséhez tehát le kell állítani a klienst. Ezért a beállítások szerkesztése a játék állapotát befolyásolja, nem történhet a mögöttes Activity futásával párhuzamosan. Ezért érdemes saját Activity-t készíteni a beállításoknak. Ezzel elkerüljük redundáns kódrészletek írását: a jázékparamétereket az alkalmazás onResume metódusában töltjük be a SharedProperties-ből. A játékot az onPaused metódusban állítjuk le. Így akár kiléptünk a kettő közt, akár megnyitottuk a beállításokat, ugyanazt a viselkedést kapjuk egyetlen hozzáadott kódsor nélkül, míg ennek elérése Dialog-gal több eseménykezelő implementálását igényelte volna.
