- Honor Magic5 Pro - kamerák bűvöletében
- Magisk
- Huawei P30 - kell ennél több?
- Mobil flották
- iPhone topik
- ReVanced patch-elt alkalmazások és Youtube Android alkalmazás alternatívák reklámszűréssel / videók letöltése
- Fotók, videók mobillal
- Xiaomi 13T és 13T Pro - nincs tétlenkedés
- Honor Magic V2 - origami
- Samsung Galaxy A55 - új év, régi stratégia
Hirdetés
-
Hordozható monitor azoknak, akik igénylik a megnövelt méretű munkaterületet
ph A Távol-keleti Hanx a megszokottnál nagyobb képátló helyett a 2 az 1-ben megközelítést alkalmazná.
-
Úgy tűnik, hogy befellegzett a The Division Heartlandnak
gp Az Ubisoft évek óta fejlesztette az ingyenes akciójátékot, amely már nem fog megjelenni.
-
Retro Kocka Kuckó 2024
lo Megint eltelt egy esztendő, ezért mögyünk retrokockulni Vásárhelyre! Gyere velünk gyereknapon!
Új hozzászólás Aktív témák
-
lanszelot
addikt
A gondom csak annyi, hogy sehol se találom a file-t.
ES File Explorer-be beírtam, hogy keresse meg az összes .db file-t de nem volt közöttük.
Rákerestem a data szóra is, de ott se volt. DataDB-re is kerestem, de semmi.
A program nevére is rákerestem, de azt se találta.
Pedig elvileg valahova mentett.[ Szerkesztve ]
-
thon73
tag
Köszönöm. Bár ezzel a válasszal nem sokra mentem.
Megpróbálom kicsit érthetőbben elmagyarázni. Az InputMethodService több billentyűzet adatait tartalmazza a nagyjából a következő módon:
InputMethodService - KeyboardView - GeneralKeyboardData - Keyboard - Button - Text
Természetesen egy kicsit összetettebb az egész, de a sor minden egyes gomb esetén ezen alaposztályok leszármazottaiból áll össze. A sor végén álló "Text" pl. definiálja az "A" karaktert (néhány egyéb tulajdonsággal, pl. hogy . után legyen nagy, meg ilyesmi.)
A mi szempontunkból az egyetlen lényeges dolog, hogy amikor a "Text" osztály el szeretné küldeni az 'A' karaktert, akkor az InputMethodService osztály metódusaira van szüksége. (Amire viszont senki másnak.)
Eddig pont ugyanúgy oldottam meg, ahogy pl. a Context-nél történik (Tehát nem a service-t szerettem volna contextből kinyerni.), vagyis az InputMethodService szépen végigutazott az egész soron, és az összes "Text" példány tárolta a hivatkozást, hogy tudjon kommunikálni.
A változáson pedig azért kezdtem el gondolkodni, mert szerettem volna az egész adatstruktúra legenerálását leválasztani a Service-ről. Emiatt viszont az InputMethodService nem áll rendelkezésre akkor, amikor az adatstruktúra elkészül.
Több lehetőséget találtam:
Amikor a kész adatstruktúrát a Service-hez kapcsolom, végigmegyek az összes elemen és megadom az InputMethodService-t.
Vagy egyedül a GeneralKeyBoardData (az adatstruktúra legalsó eleme) kapja meg, és a Text ettől kérdezi le.
Vagy valahogy kiszedem az InputMethodService hivatkozását magából az InputMethodService-ből, amiből egyébként egyetlen van, és addig folyamatosan él, amíg nem váltok másik billentyűzetre (ilyenkor viszont az adatstruktúra sem létezik tovább.)Amúgy eddig az "erőltetett objektumokkal" szépen működik, de azt gondoltam, kell legyen ennek egyszerűbb módja is. Csak éppen még nem jöttem rá, mi az, ezért kértem segítséget az utolsó elgondoláshoz.
((A fentiektől függetlenül filozófiailag "sok hülye meg erőlteti itt az objektumokat" kijelentésnek igen komoly háttere van. Nagyon sok, nálamnál sokkal komolyabb programozó vitatja az objektum-orientált programozás előnyeit szemben a hagyományos, lineáris programozással. Mielőtt mindenki nekem ugrana és szétszedne, nem állást foglaltam mellettük, csak tényként megemlítettem ezt az iskolát is. Én ugyan nem tudom megítélni, de valószínűleg amúgy a java egy objektum-orientált android környezetben nem is alkalmas erre.))
-
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!
-
thon73
tag
Hát, ne egy hétköznapi billentyűzetre gondolj. Valójában akivel terveztük/teszteltük könyveket ír rajta több nyelven. Az eredetileg gigantikusnak gondolt határértékek a keze között akadállyá váltak: jelenleg 10 (külön keskeny és széles) layout a teszt, akár több, mint 1000 tényleges billentyűvel.
Ha ehhez hozzávesszük, hogy egyetlen billentyű leírásához akár 20 token is kellhet; ill. hogy ez legalább 2500 objektum; ráadásul egy igen részletes log is tartozik hozzá - akkor már nem is olyan sok az az idő. De az oroszlánrészét az objektumok veszik el, meg persze GC is dolgozik közben - a log tanúsága szerint.Mindegy, három próbálkozáson keresztül jutottunk ide, és ez jónak tűnik: nagyon gyorsan és könnyen módosítható, és mindent tud, amit szeretnénk. No persze, az okostelefon elgondolásba ez a (mondjuk log nélkül talán) 10 másodperc már nem fér bele, tegyük hozzá a három sem. Ezért szeretném pontosan ezt: szétválasztani a kettőt. Akár install során legyártja a szükséges adatokat, aztán a mentés meg a töltés már nem sok idő.
A Broadcast ötleten is gondolkodtam (ez jó, hogy példa is van hozzá), de az egyik előző elgondolásban az előző karakter átírását a DELETE majd ÚJKARAKTER elküldésével oldottam meg. legnagyobb meglepetésemre teljesen összekeveredett a sorrend, az elküldött értékek nem ugyanabban a sorrendben érkeztek meg. (A doksi csak arra hívja fel a figyelmet, hogy ez ún. IPC - vagyis nagyon lassú. De keveredésről nem volt szó.) Megoldható persze, egy blokkban kell a kettőt (néha többet) elküldeni. Épp csak attól tartottam, hogy a Broadcast még tovább rontja ezt az időt - talán az editor kellene a receiver legyen, de ez persze nem realitás.
Ebben a Broadcast megoldásban elmélyedek, mennyire nehéz bele-aplikálni. (Loadernél használtam, ott nagyon jó volt)
Még egy kiegészítés:
Amúgy a Broadcast megoldás is singletonnal operál a példában (ami gyári); no ezt csak azért írom, hogy csak azért betenni, hogy egy másik singleton-szerű megoldást kiváltson, lehet h. felesleges.Szerintem kipróbálom mind a hármat (referncia átadása - service elérése singletonként - broadcast; aztán meglátom, mennyire idő/helyigényes és mennyire dönti romba a kód szépségét
[ Szerkesztve ]
-
sztanozs
veterán
Hajóra kell egy nem túl olcsó átalakító - ez a legnagyobb hátránya az egésznek.
A SeaTalk <-> NMEA átalakító nagyon drága mulattság.JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
?). 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.))
Új hozzászólás Aktív témák
- Kingston Fury Renegade M.2 4TB
- Eladó egy fekete és egy ezüst szinű Apple Watch S8 45mm GPS+CELLULAR Steel HERMES okosóra. 2év gari
- Acer Nitro XV275 UP3 27" - QHD - 170Hz - 10bit - FreeSync Premium - HDR1000
- ÁRON ALUL ELADÓ VADONATÚJ IPHONE 13 MINI 128GB FEKETE, 2 ÉV GARI 2026.05.15-ig
- Fanatec bazár (Mclaren v2 perec, CSL DD, SQ v1.5 váltó, V2 pedal, P1 v2 perec, NLR Wheelstand, stb.)
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Alpha Laptopszerviz Kft.
Város: Pécs