2. Fórumok
  3. Szoftverfejlesztés
  4. Android programozás, Android alkalmazások készítése

Új hozzászólás Aktív témák

  • thon73 thon73 tag
    #3309
    #3308 Szmeby
    Új Válasz
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    thon73
    thon73
    tag
    #3308 Szmeby
    #3308 Szmeby

    "Bár ezzel a válasszal nem sokra mentem."
    Szóval van állapota? Van unit teszt?

    De mindegy is, inkább írok.
    A singleton önmagában nem ördögtől való. Probléma akkor lehet, ha van állapota, és azt a tőle függő komponensek változtathatják. Ugyanis ha a sigletonban van field, és az nem csak olvasható, akkor nem tudod előre megjósolni, hogy a singletonod éppen milyen állapotban van, mivel azt a komponensek kedvük szerint állítgatják. Sztochasztikussá válik a viselkedése. Ugyanez igaz a random vagy az idő használatára is. A random viselkedés pedig rejtett bugokat szül.
    Info: shared global state

    Tegyük fel, téged ez a veszély nem fenyeget, mert nincs benne field, vagy az csak olvasható. Ilyenkor még mindig probléma lehet, ha a singletont használó osztályaidat (unit) tesztelni akarod. Pl.:
    public class MyClass {

    //...

    public String doingSomethingCool(String id) {
    Entity e = MyDatabaseAccessorSingleton.getInstance().findById(id);
    // ...
    return coolStuff;
    }
    }

    Hogyan teszteled a metódust, ha nem szeretnél mellette egy működő adatbázist is futtatni. Sajnos sehogy.

    Lehetséges megoldás:
    public class MyClass {
    private final MyDatabaseAccessorSingleton db;

    public MyClass(MyDatabaseAccessorSingleton db) {
    this.db = db;
    }

    //...

    public String doingSomethingCool(String id) {
    Entity e = db.findById(id);
    // ...
    return coolStuff;
    }
    }

    A teszt immáron helyettesítheti az adatbázisos objektumot egy teszt double (mock) példánnyal. Ez esetben viszont már megkérdőjelezhetővé válik, hogy valóban szükséges-e singletonként definiálni azt. De ez már messzire mutat.

    Leszámítva a fenti két problémát a singleton egy tök jó pattern, és bátran alkalmazhatod, ha szükségét látod. Csak ésszel kell csinálni.

    Ez talán válasz arra a kérdésedre, hogy a contextet miért nem oldották meg így. A contextnek szerintem van változó állapota. Ebből singletont csinálni egyenlő a káosszal.

    -----

    Áttérve a konkrét problémára. Sajnos tényleg nem ismerem az android architektúráját, és lehet, hogy a singletonnal jársz jobban. Ezt megerősíteni és cáfolni sem tudom. Majd a tapasztalt androidosok biztos leírják a véleményüket.

    Remélem, nem értelmezem félre a dolgot, de nekem az jött le, hogy az InputMethodService megsérti az SRP principlet, mert nemcsak az a dolga, hogy felépítsen egy billentyűzetet (KeyboardView - GeneralKeyboardData - Keyboard - Button - Text), hanem ki is kell szolgálnia a billentyűzetre tapicskoló eventeket. Ezt talán célszerű lenne két külön osztályban megvalósítani. Talán te is pont ezt írtad.
    Legalábbis ha jól értem, hogy az "adatstruktúra" alatt a billenyűzetet érted, rajta a gombokkal, textekkel.

    Véleményem szerint az elnevezések alapján az event fogadása nem feltétlenül a text feladata, hanem a buttoné. Legalábbis ha én olvasok egy kódot, akkor arra számítok, hogy a text csak a gombon lévő szöveg tartalmáért felel, annak stílusáért, stb. Az esemény pedig a gombon keletkezik. De ez akár elnevezési probléma is lehet. Én mindenesetre a gombra fogok hivatkozni, a textet nagyon nem ideillőnek érzem.

    Szóval a gombok event listenere pedig továbbpasszolja az eseményt egy event handlernek (talán az InputMethodServicenek?), ami elvégzi a gombnyomás mögé rejtett logikát. A gombnak tehát szüksége van ebből egy példányra, hiszen mit ér a gomb, ha nem csinálhat semmit.
    Nincs sok lehetőség:
    1. Leküldöd a billentyűzet legyártásakor minden gombnak ezt a referenciát.
    2. Vagy csak a GeneralKeyBoardDatáig. Bár akkor a GeneralKeyBoardData példányt kell majd továbbpasszolnod a gombok felé, hogy azok lekérdezhessék. Tehát ígyis-úgyis utazik lefelé egy referencia, így ha ez a megoldás nem hoz látható javulást, akkor nem éri meg, csak ront az átláthatóságon.
    3. Használod a gombban a singletont.
    4. Használsz valamilyen android hókuszpókuszt. Az előző hozzászólásomban a contextre gondoltam, legalábbis a neve alapján arra asszociáltam, hogy ezen keresztül elérhetők ill. elérhetővé tehetők a szükséges komponensek. A válaszodból az jött le, hogy nem.

    "Vagy valahogy kiszedem az InputMethodService hivatkozását magából az InputMethodService-ből"
    Ezt nem értem, itt a singleton.getInstance()-ra gondoltál, ugye?

    Nekem ez az egész egyébként UI-szagúnak tűnik, és backend fejlesztőként én úgy gondolom a UI-t nem is igazán kell tesztelni. Legalábbis nem így. Állapota meg biztos nincs, ugye? Szóval menjen az a singleton! :D

    Sajnálom, hogy nem tudtam érdemben segíteni, csak a java oldalt ismerem.

    Senki sem fog programozási paradigmákról flame wart indítani, annyi féle létezik, imperatív, deklaratív, oo, stb, egyesek valamennyire átfedésben vannak másokkal, mindegyiknek van előnye és hátránya, ostobaság lenne erről vitatkozni. A programozás úgyis arról szól, hogy kiválaszd a neked/projektnek megfelelőt, és megtanulj együtt élni a hátrányaival.
    Vagy készítesz egy új programnyelvet, új megoldásokkal, és majd csak utána jössz rá, hogy a többinél nem jobbat alkottál, csak másabbat. :)
    Szóval a "komoly" emberek vitassák bátran az oo-t, ha nincs jobb dolguk. Én is fel tudok hozni egy csomó hátrányt az OOP-ben, de ugyanúgy a funkcionális nyelvekben is, stb. De miért tenném? A világ nem lesz jobb, ha elkezdek fikázni egy paradigmát, vagy egy nyelvet.
    Amit viszont én írtam (static hívások, globális állapottal, javaban) az egy erősen kisarkított példa volt, természetesen ironizáltam. Bele kell törődni, hogy a java egy oo nyelv, és a szabályokat ugyan meg lehet szegni, csak hosszútávon legtöbbször nem éri meg.

    A "lineáris programozás" alatt mit értesz?

    Így már értem, és az utolsó szaváig egyet is értek vele. Az ördög az Android felépítésében rejlik, ezért csak a konkrét részekkel foglalkozom, a többi az absz. úgy van, ahogy írod.

    Az InputMethodService felelős a billentyűzetért, ami ugye a képen van, tehát UI. Sajnos ez a Service igen gyengén dokumentált, többnyire a forráskódból meg próbálkozásokból jöttem rá egy-két dologra.

    A mi szempontunkból fontos: a billentyűzet kiválasztásakor elindul a service és örökön-örökké él, amíg új billentyűzetet nem választ ki a felhasználó. No, és persze egyetlen példányban él. De ha szigorúan akarok fogalmazni: nem singleton, legfeljebb hasonló.

    A service elindításakor szükség van valamilyen adatstruktúrára, ami a billentyűzetet reprezentálja. Az első megvalósításban ezt a struktúrát egy leírófájl alapján maga a service készíti el; ami leginkább idő. Ez a rész háttérszálon fut, de akkor sem tudom a billentyűzetet használni, amíg kész nincs. Ez persze idő, akár 10-20 másodperc is lehet; igaz csak a billentyűzet legelső kiválasztásakor kell kivárni. Nem tudom külön előkészíteni, mert a konkrét gép adatira is szüksége van. Viszont ezt szerettem volna úgy különválasztani, hogy mondjuk egy program legenerálja a használható adatstruktúrát (oké, ez egy fél perc), aztán azt az adatstruktúrát már azonnal tudja használni a service.

    A speciális View egyik metódusa (onTouch()) kerül meghívásra érintéskor, egy másik (onDraw()) rajzoláskor. Az eddigieket nem én találtam ki, ez gyárilag így van.

    Természetesen az onDraw() is eljut a példánkban Button-ként szereplő osztályig, ami megrajzolja a billentyűt (ennél kicsit bonyolultabb a dolog, mert egy köztes képet használ, de ez nem érdekes), és persze az onTouch() végrehajtása is a Button()-on keresztül történik, pontosabban a Text és Key további osztályokon, mert egy Button (joystick pl), akár négy ilyet is tartalmazhat. A lényeg csakis annyi, hogy az egész hosszú struktúrán végiggörgetem a referenciát, egészen pontosan úgy, ahogy írod. Mert ugyanis a leütött billentyűt CSAK a legelsőként szereplő Service tudja elküldeni. Van emögött persze logika, de néhány lépésben nehéz megfelelni neki.

    A végső kérdés abszolút android specifikus: ennek a nem-singelton, nem-teljesen-standard-service, nem-minden-ízében-ismert InputMethodService-nek a referenciáját - vagyis inkább annak az átadását ki tudom-e kerülni valahogy. Magával az InputMethodService-szel nagyon kevesen foglalkoznak (szerintem), ezért örülnék, ha lenne valakinek tapasztalata vele.

    Az állapot kérdésére meg nem tudok válaszolni. Ez egy bővített gyári osztály - fogalmam sincs arról (és doksi sincs), hogy egészen pontosan hogyan viselkedik. Azért persze valamennyit már tudok róla, csak félek, ez kevés, hogy egy ilyen huszárvágást bátran megcsináljak.

    Az apróságokra:
    jogos, én sem text-nek hívom, hanem packet-nek, amiből kettő van: vagy stringet vagy hard-keyt (kódot) tudok átadni. De ez a referencia utazása szempontjából csak még egy lépcső...

    A felsorolt opciók közül jelenleg 1-es működik. 2-est érzem megvalósíthatónak. A 4-es a kérdés, van-e ilyen, esetleg 3-assal kombinálva.

    ((A programozási cikket sajnos már nem találtam meg. Én magam nem vagyok elég felkészült, hogy bármi ilyen vitában részt vegyek, de a cikk nagyon érdekes volt. A "lineárisra" emlékszem, lehet, hogy rosszul idéztem, minden estre számomra a nem objektum-orientált, nem event-driven struktúrát jelentette (mondjuk basic :) ?). Nem ide tartozik, de nagyon tetszett a hasonlat, amit az egyik fél alkalmazott: Az objektum orientált programozás nagyon jó, de ha szükség van egy banánra, akkor meg kell teremteni hozzá a majmot is, meg az egész őserdőt. Bocs, ha ez se pontos. És még egyszer: részemről ez semmilyen állásfoglalás, tényleg nem tudok mit mondani róla; épp csak feldobtam, hogy ilyen is van a nap alatt.))

    Nagyon köszönöm a választ, mert segítettél továbbgondolni, és így a probléma is sokkal jobban kezd körvonalazódni bennem!

Új hozzászólás Aktív témák