Hirdetés

  2. Fórumok
  3. Okostelefonok
  4. Gőzerővel optimalizál a Google hajlítható képernyőre

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

  • #8 thiclyoon aktív tag no1r #4
    Új Válasz #8
    Ú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

    thiclyoon

    aktív tag

    válasz no1r #4 üzenetére

    pontosan, végre valaki aki egyetért velem :D

    #5: iOS-es appok nem VM-ben, de sandbox-ban futnak. Androidon meg VM-ben és sandbox-ban, utóbbit szokták összekeverni a VM-mel

    #7: TL;DR: meg lehetne oldani, igen, programozással kapcsolatos dolgokra is igaz, hogy "minden megoldható, csak legyen pénz és idő."
    Kicsit hosszabban: az a helyzet, hogy a VM téma ennél sokkal mélyebb a dolog (én se értek mindent, sőt), és ezzel együtt sokkal "felszínközelibb" részeket is érint az Android (vagy bármelyik rendszer) architektúrája. Mondok egy konkrét példát, ami jól szemlélteti a problémát: adott egy use-case, a telefon elforgatása. Egyszerű, könnyen implementálható rész, a fejlesztőnek ezzel nem kell (nem kéne) foglalkoznia, hiszen az OS dönti el, hogy mikor forduljon el, OS szinten tiltható a funkció, stb. Nézzük meg, melyik platformon hogyan implementálták, ehhez nevezzünk egy képernyőnyi tartalmat Screen-nek (konkrétan ha valakit érdekel, iOS-en ez pl. a UIViewController, vagy újabban View, Androidon meg a nem-compose időkben Activity, de ezt a részletet most fedjük el a Screen névvel):
    - Android: az OS eldönti, hogy forgatni kell a Screen-t, ekkor a Screent megsemmisíti, és létrehozza ugyanazzal a tartalommal, immár elfordított helyzetben
    - iOS: az OS eldönti, hogy forgatni kell a Screen-t, ekkor a Screen kap egy jelzést viewWillAppear néven (egyszerűen fogalmazva persze), amire kirendereli a tartalmát elforgatva (meg animálva). A modell nem semmisül meg, nem kell drága erőforrással újra létrehozni egy komplex felépítésű Screent

    Mi lett az eredménye ennek az eltérésnek?
    - Androidon még az újabb eszközökön is (de a középkategóriásoknál biztosan, és hiába már-már alig észrevehető, a forgatás előtt mindig van egy kis delay, és persze minél erősebb a CPU, annál inkább erőből megoldja). Ez egy régi kód, amit nem tudtak kivenni a kódbázisból, mivel olyan sokan használják, hogy nem tudnak breaking change-t tenni a source kódba (olyan változtatást, mely eltöri a régi appok működését). Úgyhogy maradt ez a működés. A mostani Compose-t már nem ismerem, ez egy új layout rendszer, lehet, hogy ez már javít a helyzeten, de meglepődnék, ha kigyalulták volna az egész problémát
    - iOS-en meg vígan forog a képernyő oda, ahova akarod. A fentiek következménye, hogy egy Screent akár fokonként is lehet(ne) forgatni, nem kell folyton törölni - létrehozni a modellt, ami felesleges erőforráspazarlás

    + infó: iOS-ben is vannak rossz, elavult, nem hatékony megoldások, hiszen ott is emberek dolgoznak. Sőt, mivel nem open source, így szerintem több hiba is van benne. Viszont ha találnak egy hibát, akkor azt egyből ki tudják javítani úgy, hogy kívülről nézve nem változik semmi (ezt megtehetnék Android oldalról is, csak sok változtatás publikus apikat is érinthet, ami ilyenkor iOS-en mondjuk deprecated lesz). És még egy: iOS-en nem félnek publikus apit módosítani. Konkrét példa ismét: a DatePicker komponens (az a jól ismert kerék, amiről dátumot választhatsz) iOS 13 előtt keréknek nézett ki, és nem volt más opció. Viszont 13.4-től és 14.0-től újabb részek jöttek be, és default módon nem keréknek nézett ki, amivel így eltörtek a képernyők, komponensek, UI-ok. Emiatt ki kellett javítani ezeket a régi appokban is, és pl. a gmail jópár hónapig bugos volt, és nem lehetett időzített emailt küldeni, mert a UI szétesett a fenti miatt. Egyik se jobb rendszer, mint a másik, tanulni kell a másiktól, és fejlődni :)

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