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

• #17 thiclyoon aktív tag Wesiz #16

  Új Válasz 2021-09-30 13:17:11 #17

  Ú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 Wesiz #16 üzenetére

  Nem várható sajnos. Előzőleg említettem, hogy volt a "régi" Android layout rendszer (Activity, Fragment, .xml fájlok), és van az "új" rendszer (Compose). Erre nem adtam egyértelmű választ, de kiderítettem, hogy maga az Activity logika megmaradt a Compose "alatt" ("a motorháztető alatt nem történt sok változás"), ami azt eredményezi, hogy a képernyő elforgatás működése ugyanúgy megvan a fancy, újabb layout rendszerben is.

  Ez viszonylag rossz hír, hiszen iOS-re is kb. ezzel egyidőben jött ki az új layout rendszer (SwiftUI), amit ground-up építettek fel, tehát az régi dolgokat bár supportálják, de a SwiftUI nem arra épít. Persze erre több erőforrást allokált az Apple, a Google-nek viszont nem központi része az Android, nem tud és szerintem nem is akar annyit rászánni, mint amire az Apple hajlandó. Vissza Androidhoz: ez azért nem jó hír, mert így az a bizonyos kód, ami ezt a működést eredményezi, ugyanúgy ott van a rendszerben, ugyanúgy arra építenek, így nem kerül(t) ki a kódbázisból.

  Azért nem magától értetődő ezt a "hibát" javítani, mert igazából nem tipikus hiba, hanem a rendszer működésének sajátossága, úgymond arhictekturális örökség. Természetesen javítható az egész, ennek a legegyszerűbb megközelítése az, ami a legtöbb munkát igényli:
  - fel kell térképezni a publikus apikat, amiket érint ez a dolog (publikus api az az, amit a programozó elér, és tud használni). Ha ezek változnak egy új Android verzióban, törik az egész app, crash-ek lesznek, ami természetesen nem kívánatos
  - ez a publikus api halmaz óriási kódmennyiséget jelenthet, hiszen ez egy core funkció, amire nagyon sok dolog épül
  - a publikus apit meg kell hagyni, és a benne lévő implementációt ki kell cserélni (kb. "meghagyjuk az autó külsejét, így a színe nem változik, de beleteszünk egy teljesen másik motort, váltót stb."). Ez óriási meló, és nagyon-nagyon nem triviális. Ezen belül először ki kell találni egy jó (jobb) architektúrát, amivel nincs ez a képernyő megsemmisítés és újra létrehozás. Ez nem olyan vészes, mivel ha egy az egyben lemásolják az iOS felépítését, akkor sokat nem hibázhatnak itt. A második része maga a kódolás, ami az egész projekt legnehezebb része: megfelelni egy publikus apinak úgy, hogy belül módosíthatsz ugyan bármit, de nagyon meg van kötve a kezed, azt nagyon nehéz megcsinálni, ha csak nem lehetetlen*.
  - release, és mindenki boldog

  Bonyolultabb megoldás, ami pedig összességében kevesebb szenvedést igényel, de kompatibilitási gondok lehetnek, egyéb dolgok merülhetnek fel:
  - a Compose-t ground-up felépíteni, Activity örökség nélkül. Ez sok munka, de nem annyira szenvedős, mint egy régi kódot turkálni.
  Sajnos a Google nem így csinálta már mikor kitalálta a Compose-t, úgyhogy az 99%, hogy ezt az utat nem akarja járni a Google. Marad az első, ha egyszer lesz valakinek elég ideje és türelme hozzá.

  *: nagyon leegyszerűsítve: tegyük fel, hogy van egy olyan függvény a mostani kódban, hogy rotateScreen() -> Screen, aminek az a jelentése, hogy "forgasd el a képernyőt, és add vissza az újonnan létrehozott képernyőt, hiszen a régit megsemmisítetted." Na most az új architektúra szerint ennek nincs értelme, pedig magának a függvény "fejlécének" meg kell maradnia, tehát ugyanúgy vissza kell adnia egy Screent. Mi az, hogy új képernyő? Hiszen az új rendszerben nem is lenne megsemmisítés. Ez csak egy nagyon leegyszerűsített, nem valós példa, az érthetőség miatt írtam le.

  Ahogy írtam, minden megoldható, csak idő és pénz függvénye, de itt van egy elég szoros kényszer: meg kell hagyni a publikus apikat, és csak a belsejét lehet módosítani. Emiatt egymásra hatások (dependenciák / függőségek) alakulnak ki, és olyan nagy a kódbázis, hogy ember legyen a talpán, aki megpróbálja ezt az egészet. Marad az a másodpercnek is törtrésznyi ideje delaynek elforgatáskor, és bízunk benne, hogy az újabb, egyre bikább CPU-k erőből elintézik

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