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

Hirdetés

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

  • #2852 Szmeby tag caindwan #2851
    Új Válasz #2852
    Ú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
    Privát üzenet küldése

    Szmeby

    tag

    válasz caindwan #2851 üzenetére

    Először is nem vagyok otthon a témában (sem adózás, sem play árusítás), de talán segít. Legfeljebb jól félrevezet. :P

    1. ÁFA: Úgy gondolom, a vásárló az app megvételével kifizeti a saját országa szerint fizetendő áfát, amit remélhetőleg a google elintéz és te csak a nettót kapod meg.

    2. SZJA: Mivel a szoftverfejlesztés önálló tevékenységből származó jövedelmet produkál, azt terheli a korábban említett 10% jövedelemadó (vagy adószámos magánszemélyként költségeket is leírhatsz belőle, de erre már nem emlékszem). A bevallásban szerepeltetni kell és persze befizetni.

    Szóval én úgy gondolom, az áfát a vásárló fizeti a saját országa törvényei alapján a saját országának kicstárába, a jövedelemadót meg te fizeted a magyar kincstárba (mármint ha Magyarországon végzed eme tevékenységedet).

    Persze egy könyvelő egy rövid tanácsadás keretében simán fel tud készíteni bárkit erről. Ő meg csak nem téved.

    [ Szerkesztve ]

  • #3017 Szmeby tag lanszelot #3015
    Új Válasz #3017
    Ú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
    Privát üzenet küldése

    Szmeby

    tag

    válasz lanszelot #3015 üzenetére

    Ez csak egy string, úgy nevezed el, ahogy akarod. Gondolom ilyen néven készül el a fájl, ami az adatbázist tartalmazza. Ha módosítod, akkor új adatbázis készül az új névvel, üres tartalommal.

    Mindenben segít a javadoc, vagy a javadoc, és persze a barátod.
    A neten amúgy tömegével találhatsz tutorialokat is.

  • #3027 Szmeby tag lanszelot #3018
    Új Válasz #3027
    Ú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
    Privát üzenet küldése

    Szmeby

    tag

    válasz lanszelot #3018 üzenetére

    Már bocsánat, ha megnyitottad volna a linkeket, akkor most nem írnád azt, hogy nem találod a fájlt. Én sem értek az Androidhoz - bár Javahoz igen -, mégis megtettem neked azt a szívességet, hogy helyetted rákeresek. Balga módon feltételeztem, hogy meg akarod érteni.

    Az első linken kiderül, hogy hova menti, a másodikon kiderül, hogy mégis mi az a DATABASE_NAME.
    A harmadik link első találata nem csak azt írja le, hogy hol találod a fájlt, azt is leírja, hogy védett területen van, de ott még az adatbázis SD kártyára exportálását végző kódrészletet is találhatsz. Úgy nézem azóta újabb linkeket kaptál, ami ezt elvégzi, mégsem nézed meg őket. Miért?

    Az idő pénz. Ha sajnálod arra az idődet, hogy ezeknek utánanézz, megértsd, milyen alapon várod el másoktól, hogy a saját idejüket ezzel töltsék? Ha ennyire nem érdekel a téma, akkor keress meg egy Android fejlesztőt és készíttesd el vele a kívánt programot, fizetségért. Egy csomó fejfájástól megszabadulhatsz.

    És tévedés ne essék, úgy gondolom itt a fórumon bárki nagyon szívesen segít annak, aki elakadt, aki meg akarja tanulni. A hozzászólásaidat olvasva, nekem egyértelműen az jött le, hogy meg sem akarod tanulni, a hátad közepére sem kívánod ezt a programot. Ez így nem megy.

    Arra nem gondoltál még, hogy ha mindenki "belédrúg", lehet, hogy nem a mindenkiben van a hiba?
    "Fogj neki egy halat, vagy tanítsd meg halászni."
    Te az előbbit szeretnéd, a fórum az utóbbiról szól. Óriási különbség.

  • #3306 Szmeby tag thon73 #3305
    Új Válasz #3306
    Ú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
    Privát üzenet küldése

    Szmeby

    tag

    válasz thon73 #3305 üzenetére

    A Servicenek van állapota?
    Amúgy próbáld meg unit tesztelni a singletonra hivatkozó osztályaidat, és rájössz, miért nem jó.
    Persze a célnak megfelel, csupa static hivatkozással is lehet programot építeni, a sok hülye meg erőlteti itt az objektumokat, mi? :)

    Én nem érteni Android, de minek van a context, ha abból sem nyerhető ki a kívánt service?

  • #3308 Szmeby tag thon73 #3307
    Új Válasz #3308
    Ú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
    Privát üzenet küldése

    Szmeby

    tag

    válasz thon73 #3307 üzenetére

    "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?

    [ Szerkesztve ]

  • #3310 Szmeby tag thon73 #3309
    Új Válasz #3310
    Ú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
    Privát üzenet küldése

    Szmeby

    tag

    válasz thon73 #3309 üzenetére

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

  • #3427 Szmeby tag Pampipapi #3426
    Új Válasz #3427
    Ú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
    Privát üzenet küldése

    Szmeby

    tag

    válasz Pampipapi #3426 üzenetére

    Itt szerintem hamar találsz embert.

    Nem kötekedésképpen, de nem egyszerűbb rádugni egy Raspberryt a hajó(?) központi buszára, és azon feldolgozni az adatokat? Jó kis oldschool madzaggal, nem holmi megbízhatatlan kékfoggal. A Pi-n még akár egy webszerver is futhat, így bármilyen böngészőből tudod nézegetni. Még csak Androidhoz sem vagy kötve, írhatod bármiben a kódot.

    [ Szerkesztve ]

  • #3429 Szmeby tag sztanozs #3428
    Új Válasz #3429
    Ú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
    Privát üzenet küldése

    Szmeby

    tag

    válasz sztanozs #3428 üzenetére

    Értem. Akkor nem szóltam.

  • #3736 Szmeby tag flash- #3733
    Új Válasz #3736
    Ú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
    Privát üzenet küldése

    Szmeby

    tag

    válasz flash- #3733 üzenetére

    Arról nem is beszélve, hogy van külön európai, amcsi szabadalmi hivatal, a szabályozás egyáltalán nem egységes, egy külön szakma úgy megfogalmazni egy szabadalmi bejegyzést, hogy az védelmet is nyújtson. És persze mondanom sem kell, hogy mocskosul sokba kerül (már csak a szabadalom életben tartása is egy folyamatos kiadás), ha meg még perre is kell menni miatta, az is egy kellemes dolog (nem az).

    Nyilván az ötlettől függ, hogy hol mit jegyeztetsz be, már ha egyáltalán be akarod. Ahogy az is, hogy hajlandó vagy-e saját vállalkozást indítani, vagy inkább elpasszolod az ötletet egy ilyen körben otthonosan mozgó cégnek. Polihisztorként egyedül is csinálhatod, mert nem ritka, hogy valakinek megy a könyvelés, a marketing, üzleti és jogi téren is megállja a helyét, a "csapat" másik fele pedig ért a frontendhez, backendhez, ad a minőségre, a biztonságra, etc. Ugye? :)
    Nyilván ha már felmerült a levédetés gondolata, akkor nagy dologról lehet szó. Hogy ezt egy kétfős csapat mennyire tudja jól megcsinálni, az már csak az ötletbe vetett hit kérdése... meg az elfogyasztott kávé mennyisége.

    Nem akarlak lelombozni, lehet csinálni ezek nélkül is, csak rizikósabb. Rosszul fizetett adó esetén rád szállhat a nav, rosszul megfogalmazott szabadalom esetén a versenytárs kihasználhat egy kiskaput, egy nem reklámozott terméket a kutya sem fog észrevenni, stbstb.
    De ez már nagyon nem android programozás, mellesleg nem is értek a szabadalmi témához :D, csak amit innen onnan hall az ember a tűzközelben lévőktől... hát botrányos, na.

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