Hirdetés
- MWC 2026: Bajnoki címre pályázik a Xiaomi Watch 5
- Xiaomi 17 Ultra - jó az optikája
- MWC 2026: Kezünkben a frissen bemutatott Motorola Edge 70 Fusion
- Milyen okostelefont vegyek?
- Nemzetközi vizekre evezett a Realme GT 7 és GT 7T
- Android alkalmazások - szoftver kibeszélő topik
- Honor Magic8 Pro - bevált recept kölcsönvett hozzávalókkal
- MWC 2026: Kezünkben a minden tekintetben európai okostelefon
- Szívós, szép és kitartó az új OnePlus óra
- Google Pixel topik
Új hozzászólás Aktív témák
-
thon73
tag
Í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
- Garancia kérdés, fogyasztóvédelem
- Formula-1
- Gitáros topic
- Horgász topik
- WoW avagy World of Warcraft -=MMORPG=-
- MWC 2026: Bajnoki címre pályázik a Xiaomi Watch 5
- Azonnali alaplapos kérdések órája
- MWC 2026: Munkahelyi igásló lehet a Lenovo ThinkTab X11
- AliExpress tapasztalatok
- Gyúrósok ide!
- További aktív témák...
- P14s Gen2i 14" FHD IPS i7-1165G7 T500 16GB 512GB NVMe magyarított (lézerezett) bill ujjolv gar
- X12 Gen2 12.3" FHD IPS érintő Ultra 5 134U 16GB 256GB NVMe IR kam gar
- LG 32MR50C-B. 31.5 hüvelykes ívelt 1500R, 1920x1080 Full HD, 100Hz, AMD FreeSync, VA, Dönthető
- Eladó Lenovo Legion Y530-15ICH, FHD IPS, i5-8300H, NVIDIA 1050Ti, magyar vil.bill.
- 512GB M.2 NVMe SSD-k nagy tételben eladók.
- HP EliteBook 840 G7 14" i5 10210u, 16GB RAM, SSD, jó akku, számla, 6 hó gar
- AKCIÓ! LENOVO ThinkPad P15 Gen 1 munkaállomás - i7 10875H 32GB DDR4 512GB SSD Quadro T2000 W11
- ÁRGARANCIA!Épített KomPhone i7 14700KF 32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- BESZÁMÍTÁS! ASRock A520M R5 3600 16GB DDR4 512GB SSD RX 6600 8GB Rampage SHIVA Cooler Master 600W
- Bomba ár! HP EliteBook 850 G2 - i7-5GEN I 16GB I 512GB SSD I 15,6" FULL HD I Cam I W10 I Gari!
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
?). 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.))
