Android i iOS aplikacije mogu da dele veliki deo poslovnog koda, uz posebne delove za funkcije svake platforme. Zajednički razvoj vredi razmotriti kada korisnici na oba sistema obavljaju slične zadatke. Odvojen razvoj postaje opravdan kandidat kada se interfejsi ili zahtevi uređaja znatno razlikuju, ili već imate aplikacije koje dobro rade i timove koji ih održavaju.
Odluku donesite prema istom spisku funkcija i proveri najneizvesnije integracije. Ako još birate da li je potrebna instalirana aplikacija, prvo pogledajte poređenje PWA i nativne aplikacije. Ovde je polazna odluka već doneta: proizvod treba da postoji za Android i iOS, a bira se način njegovog razvoja.
Šta znači jedna aplikacija za dve platforme?
Izraz „jedna aplikacija” obično opisuje zajednički proizvod i deo koda. Za Android i iOS i dalje pripremate odgovarajuća izdanja. Serverski deo može biti zajednički i kada su same mobilne aplikacije razvijene odvojeno.
Na primer, pravilo za obračun iznosa ili prikaz naloga može da bude zajedničko. Povezivanje sa određenim uređajem može da zahteva poseban kod. Flutter dokumentacija opisuje platform channels za povezivanje sa Android i iOS kodom. React Native podržava Platform modul i odvojene platformske datoteke. Postojanje tih mehanizama znači da zajednički razvoj može imati i zasebne implementacije.
U ponudi zato tražite da bude navedeno šta se deli, šta se posebno razvija i ko održava oba dela. Naziv tehnologije sam po sebi nije dovoljan opis obima.
Koje funkcije odlučuju o pristupu?
Zapišite šta korisnik radi i kojim uređajem, pre nego što izaberete framework. Pretpostavimo da distributeru treba aplikacija za prijem robe: radnik otvara isporuku, očitava artikle i potvrđuje količinu. Ovo je hipotetički primer za planiranje, bez izvršene probe ili potvrđene podrške za konkretan skener.
Pomerite tabelu levo ili desno da vidite sve kolone.
| Funkcija | Mogući zajednički deo | Šta proveriti za svaku platformu | Dokaz pre odluke |
|---|---|---|---|
| Spisak isporuka i unos količine | Podaci, poslovna pravila i deo ekrana. | Tastaturu, navigaciju i prikaz na dogovorenim uređajima. | Korisnik završi isti zadatak u obe verzije. |
| Očitavanje artikla kamerom | Obradu dobijene šifre i proveru artikla. | Izabranu biblioteku, uređaj i potrebne dozvole. | Čitanje dogovorenih uzoraka i ponašanje kada pristup nije dostupan. |
| Spoljni skener | Dalji tok po prijemu očitane šifre. | Tačan model, način povezivanja i podržanu verziju SDK-a. | Očitavanje, prekid veze i ponovno povezivanje na obe platforme. |
| Dovršavanje slanja nakon izlaska iz aplikacije | Status naloga i pravila ponavljanja zahteva. | Dozvoljeni način rada u pozadini i prekide. | Zabeležen ishod iste radnje u dogovorenim uslovima. |
| Različiti tokovi za dve grupe korisnika | Samo pravila koja su zaista ista. | Da li isti ekran uopšte odgovara radu obe grupe. | Odobreni prototipi i odvojeni kriterijumi prihvatanja. |
Uz svaki red vodite dva zapisa, Android i iOS: model uređaja, verziju sistema, verziju dodatka ili SDK-a, datum probe i ishod. Dok to nije provereno, upišite „nije provereno”. Tako obeležena nepoznanica može da se proceni pre ugovaranja cele aplikacije.
Šta zajednički kod ne rešava automatski?
Zajedničko poslovno pravilo ne potvrđuje da ista funkcija jednako radi na oba uređaja. Na Androidu, na primer, aplikacija treba da obradi i slučaj kada korisnik odbije ili opozove potrebnu dozvolu. Zvanične smernice za dozvole opisuju traženje pristupa u trenutku korišćenja funkcije i nastavak rada uz odgovarajuće ograničenje.
Posebno precizirajte zahtev „radi u pozadini”. Android razlikuje više načina izvršavanja zadataka, a Apple opisuje strategije u kojima sistem određuje vreme pokretanja odloženog rada. Definišite šta treba da se završi i kako aplikacija obaveštava korisnika ako se rad odloži ili prekine.
U našem hipotetičkom prijemu robe, potvrda naloga može da deli ista poslovna pravila. Povezivanje skenera i ponašanje pri izlasku iz aplikacije ostaju zasebne stavke za dokazivanje. Za dodatak proverite održavanje i verzije koje podržava, pa uključite konkretni uređaj u probu.
Kada vredi razmotriti odvojen razvoj?
Odvojene aplikacije razmotrite kada zahtev zavisi od funkcija koje se bitno razlikuju po platformama ili kada svaka grupa korisnika ima drugačiji način rada. Ako za najvažniji uređaj postoje različiti proizvođački alati, proverite koliko bi njihovo povezivanje opteretilo zajedničku bazu.
Postojeći proizvod je još jedan razlog za zasebnu procenu. Pre zamene dve funkcionalne aplikacije pregledajte kvalitet koda, podršku tima i trošak prenosa. Sačuvan serverski deo ili zajednička pravila mogu imati vrednost i bez prepisivanja svih ekrana.
Odvojen razvoj takođe zahteva dogovor o usklađivanju funkcija. Kada se promeni pravilo obračuna, ko proverava obe verzije i kako se sprečava da korisnici dobiju različite rezultate? Taj posao treba navesti u planu održavanja.
Šta treba da pokaže kratka tehnička proba?
Za primer prijema robe, predložili bismo probu tačno izabranog skenera pre izrade ostalih ekrana. Pripremite testne šifre i očekivane rezultate. Proba treba da obuhvati sledeće korake:
- Povezati dogovoreni model i očitati uzorak na stvarnom Android i iOS uređaju.
- Zabeležiti ponašanje kada potrebna dozvola nije data ili veza prekine rad, ako su ti slučajevi relevantni za izabrani način povezivanja.
- Ponoviti radnju posle ponovnog povezivanja i proveriti da rezultat nije izgubljen ili unet dvaput.
- Sačuvati verzije, korake i sve ishode, uključujući neuspešne, pa označiti šta zahteva dodatni rad.
Ovo je predlog probe, a ne izveštaj da smo je izvršili. Apple dokumentacija upozorava da simulator ne ponavlja sve osobine i performanse fizičkog uređaja. Demonstracija u simulatoru zato ne potvrđuje rad izabranog skenera u stvarnim uslovima.
Testovi poslovnih pravila i testovi celog korisničkog toka imaju različit obuhvat, što opisuje i React Native vodič za testiranje. Za prihvatanje funkcije tražite dokaz o završetku zadatka na obe dogovorene platforme.
Kako uporediti ponude i troškove održavanja?
Obe ponude treba da pokriju iste funkcije, uređaje i kriterijume prihvatanja. Odvojite zajednički rad od platformskih integracija, testiranja i pripreme izdanja. Trošak serverskog dela i povezivanja sa poslovnim sistemima navedite posebno, da poređenje ne prikrije različit obim.
Tražite da ponuda imenuje neproverene pretpostavke. Na primer: cena uključuje postojeći dodatak za skener samo ako tehnička proba potvrdi dogovorene funkcije. Ako proba ne uspe, treba da znate kako se odlučuje o drugom uređaju, dodatnom razvoju ili promeni zahteva.
Za održavanje dogovorite ažuriranja zavisnosti, provere novih verzija sistema i odgovornost za objavljivanje izdanja. Zajednička baza može smanjiti ponavljanje dela rada, ali procenu zasnivajte na konkretnim stavkama. Širi budžet i obim prve verzije obrađeni su u vodiču koliko košta mobilna aplikacija za firmu.
Za sledeći korak pročitajte kako se poslovna aplikacija objavljuje i ko vodi naloge prodavnica. Plan objave treba da odvoji pripremu izdanja, pregled i potvrđenu dostupnost na Androidu i iOS-u.
Šta pripremiti za odluku o razvoju?
Za razgovor o izradi mobilnih aplikacija pripremite opis jednog potpunog zadatka, uređaje koje korisnici imaju i funkcije bez kojih ne mogu da rade. Dodajte dokumentaciju servisa ili opreme sa kojima aplikacija treba da se poveže. Ako već postoji kod, navedite ko ga održava i koje pristupe firma ima.
U zahtevu za besplatnu procenu projekta pošaljite taj opis i spisak nepoznanica. Na osnovu njih možemo da predložimo šta prvo proveriti, koji deo može biti zajednički i šta treba posebno obuhvatiti ponudom za Android i iOS.