Újraélesztjük az elavult Android/iOS verziókat!

Régi verziók támogatása magánügyfeleknek

A régi verziók támogatása akkor fontos, ha az alkalmazásnak nem csak az új telefonokon kell stabilan működnie. Sok magánügyfél csak akkor veszi észre ezt, amikor egy felhasználó jelzi, hogy a belépés, a fizetés, az űrlap vagy egy egyszerű gomb már nem működik a régebbi készülékén. A feladat ilyenkor nem látványos, mégis komoly hatása van a használhatóságra. Egy tapasztalt fejlesztő átnézi, hol szakad meg a működés, milyen rendszerverzión jelentkezik a hiba, és mit lehet javítani úgy, hogy az újabb készülékeken se romoljon el semmi.

Én azt látom, hogy a legtöbb megrendelő nem külön régi rendszerre akar fejlesztést kérni. Inkább azt szeretné, hogy az app ne veszítsen felhasználókat feleslegesen. Ez érthető. Egy magánprojektben, kisebb szolgáltatói appban, oktató alkalmazásban vagy rendelési felületen minden hibás belépés és minden lefagyott képernyő bizalmat ront. A Qjob.hu felületén olyan szabadúszó szakember kereshető, aki távolról tud dolgozni a kódon, a hibajelentéseken és a tesztelési eredményeken.

A régi rendszerverziók kezelése nem azt jelenti, hogy mindent örökre támogatni kell. Inkább arról szól, hogy ésszerű határt kell húzni. Szerintem az a jó megoldás, amikor a fejlesztő először megnézi a célközönséget, az alkalmazás típusát és a hibák gyakoriságát. Utána lehet eldönteni, hogy érdemes e régebbi Android vagy iOS verzióra javítást készíteni, vagy inkább egy tiszta figyelmeztetést, alternatív folyamatot, esetleg verziókorlátot kell beállítani.

Régi verziók támogatása alkalmazásoknál

A régi verziók támogatása alkalmazásoknál általában akkor kerül elő, amikor a kód már több frissítésen ment át. Új könyvtárak kerültek be, változtak a jogosultságok, módosultak a rendszerfüggő hívások, és bizonyos elemek régebbi eszközön másképp viselkednek. A felhasználó ebből csak annyit lát, hogy az app lassú, hibát dob, kilép, vagy nem tölt be egy fontos képernyőt.

Tapasztalatom szerint itt az első lépés mindig a pontos hibakép. Nem elég annyit írni, hogy régi telefonon nem jó. Kell a rendszerverzió, a készülék típusa, a hiba ideje, a képernyő, ahol megjelent, és ha van, akkor napló vagy képernyőkép. Ettől a fejlesztő gyorsabban tud dolgozni. Kevesebb a találgatás, kisebb a költség, és a javítás is célzottabb lesz.

Volt olyan eset, amikor egy ügyfél azt hitte, hogy teljes app újraírásra van szükség, mert több régi készüléken is megállt a rendelési folyamat. A vizsgálat után kiderült, hogy egy újabb függőség nem kezelte jól az egyik régebbi rendszerengedélyt. A javítás nem volt nagy, de a tesztelésre oda kellett figyelni. Ez jól mutatja, hogy a hiba mérete nem mindig látszik kívülről.

Régi Android és iOS verziók felmérése

A régi Android és iOS verziók felmérése segít eldönteni, hogy a javítás valóban indokolt e. Egy magánügyfélnek ez azért hasznos, mert nem mindig éri meg minden régi verziót támogatni. Ha csak néhány elavult készülékről van szó, más megoldás is elég lehet. Ha viszont sok felhasználó érintett, akkor a javítás üzleti szempontból is indokolt.

A szakember ilyenkor megnézi az alkalmazás jelenlegi rendszerkövetelményeit, a használt fejlesztői eszközöket, a külső csomagokat, a hibajelentéseket és a felhasználói visszajelzéseket. De nem csak a hibát kell nézni. Fontos az is, hogy a régebbi rendszer mennyire biztonságos, milyen funkciók érhetők el rajta, és lehet e ugyanazt az élményt adni, mint újabb rendszeren.

Sokan ott hibáznak, hogy túl széles támogatást kérnek, mert félnek elveszíteni bármelyik felhasználót. Ez érthető, de nem mindig jó döntés. Minél régebbi verziót kell kiszolgálni, annál több kerülőmegoldás, teszt és karbantartás kell. Egy pont után a régi verziók támogatása drágább lehet, mint amennyi hasznot ad.

Régi verziók támogatása árak

A régi verziók támogatása árak szempontjából erősen függ attól, hogy csak egy hibát kell javítani, vagy teljes kompatibilitási vizsgálatra van szükség. A túl olcsó munka ezen a területen gyakran gyengébb minőséget jelent, mert a fejlesztő kihagyhatja a tesztelést, nem nézi meg az eltérő rendszerverziókat, vagy csak felületes javítást ad. Ez rövid távon olcsóbbnak tűnik, de később új hibákat okozhat.

Az ár akkor lesz pontosabb, ha a megrendelő átadja a forráskódot, a hibaleírást, a célzott rendszerverziókat és azt is, hogy mely funkciók a legfontosabbak. Egy fejlesztő így nem általános ígéretet ad, hanem konkrét feladatot becsül. Szerintem ez tisztább mindkét félnek.

Online munkafolyamat és átadás

Az online munkafolyamat akkor működik jól, ha a feladat elején minden hozzáférés és információ rendben van. A fejlesztőnek általában szüksége van a kódra, a hibajegyekre, a verzióinformációkra, a tesztfiókra és a korábbi frissítések leírására. Ha ezek hiányoznak, a munka lassabb lesz. Nem azért, mert a szakember nem tud dolgozni, hanem mert a hibát előbb újra kell építeni fejben.

A távoli fejlesztésnél a kommunikáció írásban a legbiztonságosabb. Rövid feladatlista, képernyőkép, napló, elvárt eredmény és határidő. Ennyi már sokat segít. Egy hosszabb videóhívás helyett sokszor jobb egy pontos leírás, mert később vissza lehet keresni. És ha módosítás kell, nem kell újra elmagyarázni mindent.

A régi rendszerverziókhoz kapcsolódó javításoknál az átadás része lehet a módosított kód, a tesztelési jegyzet, a javított hibák listája és a javasolt további lépések. Nagyobb munkánál érdemes külön kérni, hogy a fejlesztő jelezze, mely régi verziók maradjanak támogatottak, és melyeknél már nem indokolt a további munka. Ez nem csak technikai kérdés. Költség és kockázat is.

Fejlesztő választása régi verziókhoz

Fejlesztő választása régi verziókhoz nem csak portfólió alapján történik. Fontos, hogy a szakember értse a kompatibilitási problémákat, és ne csak új funkciók építésében gondolkodjon. A régi Android és iOS rendszerek kezelése türelmet kér. Néha apró eltérés okoz nagy hibát. Néha egy régi könyvtár, máskor egy rendszerengedély, egy képernyőméret vagy egy elavult hívás.

Érdemes olyan fejlesztőt keresni, aki először kérdez. Milyen app, milyen rendszerverzió, milyen hiba, milyen gyakran jelentkezik, mikor kezdődött, volt e frissítés előtte. Ezek nem felesleges kérdések. Ezek alapján lehet jól becsülni. Ha valaki azonnal fix árat mond minden részlet nélkül, az kényelmesnek tűnik, de kockázatos.

A jó szakember nem ígéri, hogy minden régi eszközön ugyanazt az eredményt adja. Inkább megmondja, hol van reális határ. Ez nekem fontos jel. A korrekt távoli munka része az is, hogy a fejlesztő leírja, mit javított, mit nem vállal, és mit javasol hosszabb távon.

Gyakori hibák régi verziók támogatásánál

A leggyakoribb hiba az, hogy a megrendelő csak a végső tünetet írja le. Például nem indul, rossz, lefagy. Ez kevés. A fejlesztőnek tudnia kell, melyik képernyőn történt, milyen rendszerverzión, milyen lépés után, és megismételhető e a hiba. Minél pontosabb a leírás, annál kevesebb idő megy el keresésre.

A másik hiba a túl sok cél egyszerre. Régi verziók támogatása, új funkció, gyorsítás, biztonsági javítás és design módosítás egy csomagban. Lehet ilyet kérni, de akkor a munka nehezebben mérhető. Jobb külön választani a kompatibilitási javítást, utána jöhetnek az egyéb fejlesztések. Így tisztább, mi okozott javulást, és mi hozott új kockázatot.

Van egy kellemetlen pont is. Néha a régi verzió megtartása visszafogja az egész alkalmazást. Ilyenkor a fejlesztőnek nem az a dolga, hogy mindent erőből megoldjon, hanem hogy jelezze a határt. Egy magánügyfélnek ez elsőre rossz hír lehet, de hosszabb távon jobb döntést eredményez. Az app stabilitása fontosabb, mint az, hogy papíron minden régi rendszer támogatott legyen.

Minőség és hosszabb távú karbantartás

A minőség ezen a területen nem csak azt jelenti, hogy a hiba eltűnik. A jó javítás nem rontja el az újabb rendszereket, nem tesz be felesleges kerülőmegoldásokat, és érthető marad a kód. Ez azért fontos, mert az alkalmazást később is frissíteni kell. Ha a régi verziók miatt rendezetlen megoldások kerülnek be, a következő fejlesztés drágább lesz.

Szerintem a legjobb eredmény akkor születik, ha a megrendelő nem csak az azonnali javítást kéri, hanem egy rövid javaslatot is a következő lépésekre. Mely verziók maradjanak, mit kell figyelni, milyen csomagokat kell frissíteni, milyen hibákat érdemes külön tesztelni. Ez nem nagy dokumentáció, de hasznos. Főleg akkor, ha később másik fejlesztő veszi át a munkát.

A régi verziók támogatása végül bizalmi kérdés is. A felhasználó nem látja a kódot. Csak azt érzi, hogy az alkalmazás működik e a készülékén. Ha igen, marad. Ha nem, gyorsan továbblép. Egy jól kiválasztott szabadúszó fejlesztő ebben tud segíteni, távolról, mérhető feladatokkal és világos átadással.