A bada alkalmazások általában...
Minden bada alkalmazás belépési pontja az OspMain függvény, mely a parancssori paramétereket előkészíti (bár parancssor jelenleg számunkra nem elérhető), majd átadja a vezérlést az Application Frameworknek. Át kell adni egy factory metódust, amivel majd a keretrendszer az alkalmazásunkat példányosítja, ugyanis teljes hosszában a keretrendszer felügyeli az életciklust. Nekünk semmi dolgunk nincs itt igazából, az ehhez szükséges a kódot az IDE generálja, ha Form vagy Frame alapú alkalmazássablont kértünk.
Az alkalmazásobjektum feladata a képernyőre kerülő űrlapok (vagy az ezeket felügyelő FormManager) létrehozása és kezelése, az erőforrások felszabadítása kilépéskor, valamint az akkumulátor- és képernyőesemények lekezelése. Ezekről, valamint az innen elérhető egyéb szolgáltatásokról (AppControlok) a "bada Tutorial: Application" részletesebben szól.
És specifikusan...
Fontos kérdés, hogy a hálózati műveletek a UI szálban fussanak-e, vagy külön, új szálat létrehozva. Egyes platformokon, mint például Java ME-ben a második út az egyetlen lehetőség, itt bada alatt összesen négy lehetőség van: blokkoló socket a UI szálban (legrosszabb megoldás), blokkoló/nem blokkoló socket külön szálban, végül nem blokkoló socket a UI szálban. Én az utolsó megoldást fogom követni, mert ezt szoktam meg Symbianban, és igazából nincs hátránya.
Aktív objektumok puszta kézzel írogatása helyett a rendszer kezeli az eseménykezelő ciklust, nekünk csak meg kell hívni az aszinkron függvényeket, és implementálni a megfelelő EventListener interfészeket. Lehetne egyszerűbb? Nem nagyon. Főleg ha hozzávesszük azt is, hogy egy új eseménykezelő ciklus indítása annyi, hogy megfelelő paraméterrel példányosítjuk az új szálat — de ez most nem kell.
Mivel központi szerepet tölt be és bárhonnan elérhető — szemantikailag singleton —, az alkalmazásosztály ideális hely az IRC kapcsolat elhelyezésére. Az IRC szerverrel felépített kapcsolatot a Session osztály reprezentálja, elrejtve a bada hálózatkezelést és egyéb komponenseket a tisztaság kedvéért — ezeket a SessionPrivate osztály kezeli, a Session csak egy bridge a kliens és ez között. Mivel a hálózati műveletek alapvetően aszinkronok, observerek teszik lehetővé a kapcsolat állapotváltozásainak kezelését.
A libircclient-qt könyvtár forráskódjának vizsgálata során találtam egy érdekes mintát, melyet kisebb módosításokkal átveszek: a csatornákkal és felhasználókkal folytatott kapcsolatot a Conversation osztály (eredeti nevén Buffer) reprezentálja. A lényeg az, hogy míg az előbbiből egyetlen példány létezik (legalábbis amíg nem multiszerver-képes a kliens), az utóbbiakból több is létrejön, konkrétan ahány aktív beszélgetést tart fenn a felhasználó; továbbá üzeneteket küldeni és fogadni csak a Conversation interfészén keresztül lehet. Ez csökkenti az érvénytelen üzenetek vagy az inkonzisztens állapot valószínűségét.
A Conversation nem tárolja el az átmenő üzeneteket egyik irányban se, kvázi olyan, mint két konzervdoboz feszes zsinórral összekötve. Ennek a képnek van egy fontos következménye: az üzenetek tárolását, megjelenítését máshol kell megoldani — itt is az observer minta használata szükséges.
Két funkciót gondoltam első körben megvalósítani: a naplózást (HistoryManager) és természetesen a megjelenítést a felhasználói felületen (ConversationAdapter). Az előbbiből egy példány, az utóbbiból n példány kell — minden beszélgetéshez egy, úgyhogy létrehozásukért egy factory osztály felelős. A Session létrehozza az új Conversationt, erről értesíti az observerét, aki létrehozza az új adaptert, összeköti a Conversationnel, és végül a felhasználói felületnek is jelez. Az üzenetek meg már közvetlenül futnak az objektumok között. Itt még vannak nyitott kérdések, valószínűleg amikor odaérek, bőven lesz komplikáció, de optimista vagyok.
A teljes modellről készítettem egy ábrát (és ezzel a lendülettel ajánlom az OmniGraffle-t mindenkinek, mert a Visio 2010-zel is elég kényelmetlen a dobozok elrendezése):
[+]
Most már "csak" implementálni kell. Hamarosan jelentkezem a fejleményekkel.
Karma
