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
    #3311
    #3310 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
    #3310 Szmeby
    #3310 Szmeby

    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. :D

    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. :D

    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...

    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 :)

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