Android-fejlesztők Szegeden: Vélemények és kedvező árak

Android-fejlesztő magánügyfeleknek

Az Android-fejlesztő akkor hasznos magánügyfélnek, ha egy telefonos alkalmazás ötletét működő, ellenőrizhető és később bővíthető formába kell vinni. Ez lehet egyszerű időpontfoglaló, belső családi nyilvántartó, kis közösségi felület, okoseszközhöz kapcsolódó vezérlés vagy egy már meglévő alkalmazás javítása. A legtöbb megbízás nem nagyvállalati projekt. Inkább konkrét gond van, kevés idő, bizonytalan műszaki háttér és sok kérdés a költségről. Ilyenkor a Qjob.hu felületén különböző szakemberek közül lehet választani, nem egyetlen cég csomagajánlatát kell elfogadni.

Magánügyfélként általában nem az a cél, hogy minden funkció az első változatba bekerüljön. Fontosabb, hogy az alap jól működjön. Legyen belépés, adatmentés, érthető képernyő, gyors betöltés és olyan felépítés, amelyhez később hozzá lehet nyúlni. Szerintem sokkal jobb egy kisebb, tisztán megírt első verzió, mint egy nagyra tervezett alkalmazás, amely félúton elakad. Az Android alkalmazás fejlesztés nem csak kódolás. Dönteni kell adatokról, jogosultságokról, frissítésekről, tesztelésről és arról is, mi történik, ha a telefon típusa vagy a rendszer verziója eltér.

Szeged környékén gyakori igény a helyi szolgáltatáshoz kötött mobilos megoldás. Ilyen lehet egy rendelési felület, privát oktatási segédprogram, sportklubos jelenléti ív vagy lakóközösségi bejelentő. Ezeknél a feladatoknál jó, ha az alkalmazásprogramozó nem csak a kódot nézi, hanem a valódi használatot is. Ki fogja megnyitni. Milyen telefonon. Milyen internet mellett. Milyen adatot nem szabad elveszíteni.

Android alkalmazás tervezése

Az első lépés a cél pontosítása, mert a rosszul megfogalmazott ötlet drága fejlesztést okoz. Sok ügyfél úgy indul neki, hogy csak egy app kell. Ez kevés. Tudni kell, kik használják, milyen képernyőkkel induljon, kell-e belépés, lesz-e értesítés, szükséges-e fizetés, térkép, kamera, fájlfeltöltés vagy külső adatkapcsolat. Nem minden funkció nehéz, de minden funkciónak van következménye.

Személyes tapasztalatom szerint a legtöbb félreértés nem a programozásnál keletkezik, hanem a leírás hiányánál. A fejlesztő mást ért kész alkalmazáson, az ügyfél mást. Ezért érdemes rövid folyamatábrát és képernyőlistát készíteni. Nem kell hozzá szép tervrajz. Elég egy érthető leírás, amelyből látszik, mit kell megnyomni, hova jut a felhasználó, mikor kap visszajelzést és mi történik hibánál.

Volt eset, amikor egy ügyfél egyszerű jegyzetelő alkalmazást kért, de később kiderült, hogy több családtag is ugyanazt az adatot akarta látni külön telefonon. Ez már nem sima helyi mentés volt, hanem közös adatkezelés. A munka iránya megváltozott, az ár is más lett. Ha ez az elején kiderül, nincs vita, nincs újrakezdés. Ezért szoktam azt javasolni, hogy a mobilalkalmazás-fejlesztő először kérdezzen sokat, és csak utána mondjon végleges díjat.

Android-fejlesztő árak

Az ár főleg a feladat részletességétől, a képernyők számától, az adatkezeléstől és a tesztelés mélységétől függ. Egy kisebb javítás olcsóbb lehet, mint egy teljes új alkalmazás. De olcsónak tűnő ajánlatnál figyelni kell, hogy benne van-e az átadás, a hibajavítás, az alap dokumentáció és a telepíthető csomag. 25.000 forint alatt ritkán lesz minőségi, ha valódi fejlesztési munkáról van szó, nem csak egy apró beállításról.

A táblázat nem helyettesíti az egyedi ajánlatot. Inkább kapaszkodó. Egy Android-fejlesztő akkor tud tisztességes árat mondani, ha látja a képernyőket, az adatok útját és a kívánt működést. Személy szerint jobban bízom abban az ajánlatban, amelyik külön bontja a tervezést, a fejlesztést és a tesztelést. A túl kerek ár néha azt jelzi, hogy a részleteket még senki nem nézte át.

Megfelelő Android szakember kiválasztása

A megfelelő szakember nem csak azt mondja, hogy megoldható. Megkérdezi, milyen telefonokon kell futnia az alkalmazásnak, milyen adat kerül bele, hogyan történik a mentés, és ki fogja karbantartani. Egy jó Android szakember a korlátokról is beszél. Például arról, hogy egyes telefonokon az energiatakarékos beállítások késleltethetik az értesítéseket, vagy hogy a háttérben futó folyamatokat nem lehet minden helyzetben biztosra venni.

Portfóliót érdemes kérni, de nem kell nagy márkaneveket keresni. Magánügyfélnek sokszor az számít, hogy a fejlesztő tud-e érthetően válaszolni. Le tudja-e bontani a feladatot. Megmondja-e, mi fér bele az első verzióba, és mit hagyna későbbre. Én személy szerint azokat a szakembereket kedvelem, akik nem akarnak mindent egyszerre beígérni. A mobilos fejlesztésben a nyugodt, pontos munka többet ér, mint a gyors ígéret.

Sokan hibáznak, amikor csak az óradíjat nézik. Egy olcsóbb alkalmazásprogramozó is lehet jó, ha pontosan ugyanazt a feladatot vállalja. De ha nincs átadás, nincs forráskód rendezés, nincs rövid használati leírás, később minden javítás nehezebb lesz. Kérdezni kell a határidőről, a próbakörről, a javítások számáról és arról, milyen formában kapja meg az ügyfél az elkészült munkát.

Helyi munka Szeged városrészeiben

Szeged városában az Android fejlesztési megbízások nagy része távolról is elvégezhető, de a helyismeret néha mégis számít. Egy belvárosi szolgáltató, egy újszegedi oktató vagy egy rókusi kis műhely más módon használja az alkalmazást. Nem a városrész miatt lesz jobb a kód, hanem azért, mert a fejlesztő könnyebben megérti a helyzetet, ha a felhasználási környezet konkrét.

Helyi egyeztetés akkor hasznos, ha az app valamilyen eszközhöz, helyszíni folyamathoz vagy személyes munkarendhez kapcsolódik. Például műhelyben használt belső nyilvántartásnál látni kell, ki mikor nyúl a telefonhoz, mennyi ideje van adatot rögzíteni, és mi történik rossz internetnél. Szőreg, Tarján, Móraváros vagy Alsóváros említése önmagában nem műszaki kérdés. De a használat módja már az.

A környező települések, például Algyő, Deszk vagy Sándorfalva felől érkező ügyfeleknél gyakran az a fontos, hogy ne kelljen minden egyeztetéshez beutazni. Ilyenkor működhet a távoli bemutató, képernyőfelvétel és rövid írásos visszajelzés. Szeged ilyen szempontból kényelmes központ, mert sok informatikai szakember dolgozik helyben vagy a közelben.

Gyakori hibák fejlesztés közben

Az egyik gyakori hiba, hogy az ügyfél túl korán ragaszkodik a végleges kinézethez. A szép felület fontos, de előbb a működésnek kell stabilnak lennie. Ha az adat nem mentődik, ha a belépés bizonytalan, vagy ha a lista lassan tölt be, akkor a színek és ikonok nem oldják meg a bajt. A jó sorrend egyszerű. Alaplogika, adatkezelés, teszt, majd felület finomítása.

A másik gond a túl sok funkció. Egy kezdő Android alkalmazás fejlesztés gyakran azért csúszik, mert minden új beszélgetés után bekerül még egy ötlet. Ez természetes, mert munka közben tisztul a kép. De kell határ. Az első változatnak nem kell mindent tudnia. Elég, ha a fő feladatot megbízhatóan elvégzi. Utána lehet bővíteni.

Volt egy kisebb projekt, ahol a kliens ragaszkodott az offline működéshez, de közben valós idejű közös adatszerkesztést is szeretett volna. A kettő együtt nem lehetetlen, csak sokkal összetettebb. Végül két lépésre bontottuk volna a munkát. Először stabil helyi mentés, utána szinkron. Ez a fajta kompromisszum sok pénzt és idegeskedést tud megspórolni.

Átadás és későbbi karbantartás

Az átadás nem csak annyi, hogy az alkalmazás elindul egy telefonon. Kell telepíthető verzió, rövid leírás, ismert hibák listája, és tiszta megállapodás arról, mi számít garanciális javításnak. Ha külső tárhely, adatbázis vagy értesítési szolgáltatás is van, azok hozzáféréseit rendezni kell. Magánügyfélnél ez különösen fontos, mert később nem biztos, hogy ugyanaz a fejlesztő folytatja a munkát.

Az Android rendszer változik, a telefonok is változnak. Ami ma jól működik, egy év múlva frissítést kérhet. Ez nem feltétlenül hiba. Inkább a mobilos környezet része. Érdemes előre tisztázni, hogy a mobilalkalmazás-fejlesztő vállal-e későbbi javítást, milyen díjon nézi át a régi kódot, és milyen gyorsan tud reagálni sürgős gond esetén.

Nem minden projektből lesz nagy alkalmazás. Néha egy kicsi, személyes célú eszköz is elég. De akkor is legyen rendben. A jó fejlesztés nem attól jó, hogy sok funkciót mutat. Hanem attól, hogy a felhasználó érti, használja, és nem fél attól, hogy holnap elveszik az adata. Ez egyszerű elv, mégis sok munka múlik rajta.