Alkalmazások frissítése az Android API szint követelményeinek megfelelően

Alkalmazások frissítése Android API-szinthez

Az alkalmazások frissítése akkor válik szükségessé, amikor egy régebbi Android app már nem felel meg az áruház követelményeinek, hibásan fut új készülékeken, vagy a beküldésnél elakad az API-szint miatt. A magánügyfél ilyenkor általában nem teljes új fejlesztést keres, hanem olyan online szakembert, aki átnézi a meglévő kódot, kijavítja az ütközéseket, frissíti a függőségeket, és előkészíti az új kiadást.

Én azt látom, hogy sok régi mobilalkalmazás nem azért kerül bajba, mert rossz az alapötlet. Inkább azért, mert éveken át nem volt karbantartva. Közben változik az Android rendszer, módosulnak az engedélyek, új szabályok jönnek az adattárolásra, az értesítésekre, a háttérfolyamatokra és a célzott API-szintre. Egy tapasztalt Android fejlesztő ezt nem csak technikai listaként kezeli. Megnézi, hogy mi akadályozza a stabil működést, mi kell a közzétételhez, és mi az, amit nem érdemes feleslegesen átírni.

Alkalmazásfrissítés régi kódbázisnál

Régi kódbázisnál az első feladat a helyzet felmérése. Nem elég annyit mondani, hogy az appot frissíteni kell. Meg kell nézni a fejlesztői környezetet, a használt könyvtárakat, a célzott és minimális API-szintet, a build beállításokat, valamint azt, hogy az alkalmazás milyen funkciókra támaszkodik. Egy egyszerűbb appnál ez gyors folyamat. Egy több éve nem frissített alkalmazásnál viszont előjöhetnek rejtett hibák.

Tapasztalatom szerint a legtöbb gond a régi függőségekből, elavult Gradle beállításokból, inkompatibilis beépülőkből és rosszul kezelt engedélyekből indul. Sok ügyfél azt gondolja, hogy csak át kell írni egy számot a beállításokban. Ez néha működik, de gyakran új hibákat hoz. Ilyenkor az online fejlesztő nem csak módosít, hanem ellenőriz. Lefuttatja a fordítást, nézi a hibajelzéseket, és lépésenként választja szét a valódi hibát a mellékes figyelmeztetéstől.

Volt olyan eset, amikor egy ügyfél csak azt kérte, hogy az app újra beküldhető legyen. A munka elején kiderült, hogy a bejelentkezési rész régi azonosítási módszert használt, a képfeltöltés pedig újabb eszközökön már nem működött megbízhatóan. Ha csak a célzott API-szintet emelték volna meg, az alkalmazás átment volna az első ellenőrzésen, de a felhasználók hibákkal találkoztak volna. Ezért szerintem a biztonságos frissítés mindig tartalmaz legalább egy alap tesztelési kört.

Android API-szint frissítés menete

Az Android API-szint frissítés menete akkor átlátható, ha a szakember először nem a kódolással kezd, hanem rövid technikai ellenőrzéssel. A magánügyfélnek ehhez általában hozzáférést kell adnia a forráskódhoz, a build fájlokhoz, az áruházi hibaüzenethez és azokhoz az információkhoz, amelyek alapján az alkalmazás jelenlegi állapota megérthető. Nem kell mindent szakmai nyelven megfogalmazni. Elég, ha a probléma világos.

A munkafolyamat gyakran négy részre bomlik. Először jön a kódbázis és a beállítások ellenőrzése. Utána a célzott API-szint és a kapcsolódó csomagok frissítése. A harmadik rész a hibák javítása, mert a változtatások után fordítási vagy futási gondok jelentkezhetnek. Végül jön a tesztelés és az átadás. Ez lehet javított forráskód, új build, rövid hibajegyzék vagy kiadási javaslat.

Sokan ott hibáznak, hogy nem adnak teljes képet a szakembernek. Csak egy hibaüzenetet küldenek, de nem mondják el, hogy mikor frissült utoljára az app, milyen eszközön jelentkezik a gond, és van-e már korábbi sikertelen beküldés. Egy magán fejlesztő így is el tud indulni, de több időt veszít találgatással. A jó brief rövid, de tartalmazza a célt, a jelenlegi hibát, a határidőt és azt, hogy mit szeretne az ügyfél a munka végén kézhez kapni.

Alkalmazások frissítése árak

Az alkalmazások frissítése ára erősen függ attól, mennyire régi a kód, hány függőség érintett, kell-e áruházi beküldés, és milyen mélységű tesztelés szükséges. Egy kisebb módosítás nem kerül annyiba, mint egy több éve álló projekt rendbetétele. A túl olcsó munka ezen a területen gyakran gyengébb minőséget jelent, mert a fejlesztő csak a látható hibát javítja, de nem nézi meg, hogy a frissítés után stabil marad-e az app.

Szerintem az árnál nem csak az összeg számít, hanem az is, hogy mit tartalmaz a munka. Van, aki csak a fordítási hibát javítja. Más szakember röviden dokumentálja is, hogy mit módosított, milyen kockázat maradt, és mit kell később figyelni. Magánügyfélként ez fontos, mert így nem marad teljesen kiszolgáltatott helyzetben a következő frissítésnél.

Megfelelő Android fejlesztő kiválasztása

A megfelelő Android fejlesztő kiválasztásánál nem a legszebb bemutatkozás a döntő. Fontosabb, hogy a szakember értse az API-szinthez kapcsolódó szabályokat, tudjon régi kóddal dolgozni, és képes legyen érthetően leírni, mit fog megnézni. Egy magánügyfélnek nem kell minden technikai részletet ismernie. De érdemes rákérdezni néhány konkrét dologra.

Hasznos kérdés, hogy a fejlesztő dolgozott-e már régi Android projekttel. Az is lényeges, hogy vállal-e előzetes felmérést, hogyan adja át a javított fájlokat, és milyen módon jelzi, ha a kódban nagyobb gondot talál. A Qjob.hu felületén a magánszakemberek közül olyan embert érdemes keresni, aki nem csak általános alkalmazásfejlesztést ír magáról, hanem karbantartási, frissítési vagy hibajavítási tapasztalatot is mutat.

Én azt látom, hogy a jó szakember nem ígér azonnal biztos áruházi jóváhagyást. Inkább azt mondja el, milyen részek ellenőrizhetők, milyen kockázatok vannak, és mire van szüksége a pontos becsléshez. Ez elsőre kevésbé hangzik látványosan, de megbízhatóbb. Az alkalmazásfrissítés sokszor apró technikai részleteken múlik, ezért a túl gyors ígéret gyanús lehet.

Online munka és átadás

Az online munka ennél a szolgáltatásnál természetes forma. A forráskód, a hibalista, a képernyőképek és az áruházi üzenetek mind átadhatók távolról. A kommunikáció történhet írásban, rövid hívással vagy feladatlistán keresztül. A lényeg az, hogy a cél és a határidő egyértelmű legyen. Nem kell személyes találkozó, mert a munka a kódon, a beállításokon és a tesztelésen keresztül zajlik.

A feladat elején érdemes rögzíteni, hogy a szakember mit kap meg. Ilyen lehet a forráskód, a hozzáférés egy tárolóhoz, a jelenlegi build hiba, a régi és tervezett API-szint, valamint az app fő funkcióinak rövid leírása. Ha az ügyfél nem tudja, mi ezek közül fontos, elég elküldeni a rendelkezésre álló anyagokat. Egy gyakorlott fejlesztő ki tudja szűrni, mi hiányzik.

Az átadásnál jó, ha nem csak kész fájl érkezik. Hasznos a rövid leírás is. Ebben szerepelhet, hogy milyen csomagok frissültek, milyen hibák maradtak nyitva, készült-e teszt, és mi a következő javasolt lépés. Ez nem hosszú dokumentum. Néha pár mondat is elég. De később sok időt takarít meg.

Gyakori hibák alkalmazásfrissítésnél

A leggyakoribb hiba az, hogy az ügyfél csak az áruházi figyelmeztetést akarja eltüntetni. Érthető, mert a figyelmeztetés sürgetőnek tűnik. De a célzott API-szint emelése több részt is érinthet. Megváltozhat az engedélyek kezelése, a háttérben futó folyamatok viselkedése, az adatmentés, az értesítés vagy a fájlhozzáférés. Ha ezek nincsenek ellenőrizve, a felhasználó később hibát fog látni.

Másik gyakori gond a hiányos hozzáférés. A fejlesztő megkapja a forráskód egy részét, de hiányzik a kulcs, a beállítás, a dokumentáció vagy egy külső szolgáltatás adata. Ilyenkor a munka megáll. Nem azért, mert a szakember nem tud dolgozni, hanem mert a projekt nem teljes. Szerintem a legjobb megoldás az, ha az ügyfél már a kezdetkor összegyűjti az összes hozzáférést, de csak azt adja át, ami valóban kell.

Probléma lehet az is, amikor a frissítést egy nagyobb új funkcióval keverik össze. Az API-szint frissítése karbantartási feladat. Lehet közben kisebb javításokat végezni, de ha új fizetési rendszert, új képernyőket vagy teljes új felületet is kér az ügyfél, az már más költség és más határidő. Egy tiszta feladatleírás védi az ügyfelet és a szakembert is.

Minőségi alkalmazásfrissítés eredménye

A minőségi alkalmazásfrissítés eredménye nem csak az, hogy a projekt lefordul. Az appnak stabilan kell futnia, a fő funkcióknak működniük kell, és az áruházi követelményekhez is közelebb kell kerülnie. Nem minden régi projekt menthető egyetlen gyors javítással. De egy jó felmérés után világosan látszik, hogy mi javítható rövid távon, és mi igényel nagyobb átalakítást.

Magánügyfélként akkor jár jól az ember, ha nem csak árat kér, hanem munkamódszert is. Mit néz meg a szakember. Mennyi idő alatt ad visszajelzést. Lesz-e próba build. Kap-e az ügyfél rövid átadási jegyzetet. Ezek egyszerű kérdések, mégis sok félreértést megelőznek.

Az alkalmazások frissítése akkor lesz nyugodt folyamat, ha a feladat nem kapkodva indul. Először helyzetkép kell, utána javítás, majd ellenőrzés. Így az ügyfél nem csak egy módosított projektet kap, hanem jobban érti azt is, milyen állapotban van az alkalmazása. És ez a későbbi karbantartásnál legalább olyan fontos, mint maga a mostani javítás.