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

• Szmeby tag

  #3310

  #3309 thon73

  2015-08-08 20:20:13

  Ú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

  

  Szmeby

  tag

  #3309 thon73

  #3309 thon73

  Í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!

  Nem sok az a 10-20 másodperc? Biztos nem lehet rajta gyorsítani? Ez borzasztóan soknak tűnik. Egy pc ennyi idő alatt megszámlálhatatlanul sok objektumot tud gyártani. Még néhány full gc is megfuthat közben.
  Gondolom az io viszi el az idő nagy részét, de kizártnak tartom, hogy az android ne tudná ezt a fájlt már induláskor cache-elni. Hiszen előszeretettel használ ui leíró config xml-t. A legkevesebb, hogy ezt gyorsan tudja is használni.

  Ha először váltok egy másik billentyűzetre, nekem azonnal megjelenik a cucc, szóval valahogy tuti meg lehet ezt oldani. Opensource, (elvileg) saját billentyűzetet is tartalmazó app: Keepass2Android. Talán segít.
  Az android dev tutorial egy mondattal elintézi a dolgot: preload, de semmi részletezés, hogy hogyan kellene. Egy pörgő animáció a billentyűzet helyén nem tűnik valami szép megoldásnak.

  Olyan lifecycle eseményhez nem tudod kötni az objektumok legyártását, vagy legalább a fájl felolvasását, ami nem a billentyűzet kiválasztása esemény? Hanem valami korábbi időpont. Mondjuk a telefon elindulása.

  Ezt találtam, nem egy komplex billentyűzet, de én nem látom, hogy az InputMethodService referencia bárkinek is átadásra kerülne. Viszont a getCurrentInputConnection() meg a BroadcastReceiveres megoldás érdekesnek tűnik azzal a queueval. Bármit is csinál...

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