Mobiilirakendused
Mobiilirakenduste arendus
Üks OpenAPI leping ja iga klient ehitatud selle vastu — iOS, Android ja veeb. Sest mobiilitoote raske osa ei olnud kunagi ekraanid.
Mida tähendab API-esimene mobiilirakenduste arendus?
API-esimene tähendab, et rakenduse ja serveri vaheline leping kirjutatakse valmis enne, kui kumbagi ehitama hakatakse. Onpolar defineerib ühe OpenAPI spetsifikatsiooni, genereerib sellest tüübitud kliendid ja ehitab nii mobiilirakenduse kui backendi selle ühe dokumendi vastu — nii ei saa iOS, Android, veeb ega ükski AI-tarbija toote muutudes teineteisest lahku minna.
- Lähenemine
- API-esimene, üks OpenAPI leping
- Tavaline ajakava
- 8–14 nädalat poodi esitamiseni
- Backend
- Go · PostgreSQL · OpenAPI
- Kliendid ühest spetsist
- iOS · Android · veeb · AI
Probleem
Rakendus ise on lihtsam pool
Ekraanid on lahendatav osa. Mobiilitooted upuvad selle taha, mis on nende taga: API, mis muutis kuju rakendusele teatamata, võrguühenduseta olek, mis valetab, push-token, mida keegi ei värskendanud, ja kolm klienti, kes kõik rakendasid sama ärireeglit veidi erinevalt.
Teisel platvormil see kuhjub. Iga käsitsi ühendatud otspunkt on otspunkt, mis võib lahku triivida, ja viga, mis kordub Androidis aga mitte iOS-is, on tavaliselt viga lepingus, mitte kummaski rakenduses.
Seega kirjutame lepingu esimesena ja genereerime kliendid sellest. Rakendus, veebi frontend ja iga AI-tarbija loevad ühte dokumenti ning murdev muudatus jääb kompilaatori, mitte ülevaataja taha kinni.
Mida saate
Mis mobiilitootega kaasa tuleb
Üks OpenAPI leping
Spetsifikatsioon on tõe allikas. Tüübitud kliendid genereeritakse sellest, nii et serveri muudatus, mis rakenduse katki teeb, kukutab ehituse, mitte väljalaske.
Backend selle all
Go ja PostgreSQL koos autentimise, rollide ja andmemudeliga, millest rakendus sõltub — mitte mobiilikest API peal, mille ehitamist te alles loodate.
iOS ja Android ühest koodibaasist
Platvormiülene seal, kus toode on ekraanid andmete peal, ja natiivsed moodulid sisse pandud seal, kus platvormi võimekus neid päriselt vajab.
Push-teavitused, mis püsivad
Tokeni elutsükkel hallatud, kohaletoimetamine jälgitav ja loaküsimus, mis saabub hetkel, mil kasutaja saab aru, miks.
Autentimine ja turvaline hoidla
Biomeetriline avamine, tokenid platvormi võtmehoidlas ja värskendusvoog, mis ei logi inimesi rongis välja iga kehvema leviga.
Võrguühenduseta töö ja sünkroon
Kohalik vahemälu selge konfliktipoliitikaga, nii et rakendus on aus selle suhtes, mis tal käes on ja mida ta pole veel ära saatnud.
Poodi esitamine ja väljalasked
Ehitustorud, allkirjastamine, etapiviisiline väljalase ja ülevaatusringid, mida ajab inimene, kes on neid varem näinud.
Vearaportid ja analüütika
Sümboliseeritud krahhid, väljalasete võrdlus ja piisavalt tooteanalüütikat, et teada, millised ekraanid oma koha ära teenivad.
Kuidas see käib
Lepingust poe kirjeni
- 011.–2. nädal
Kirjuta leping
Otspunktid, andmekujud, veakujud ja autentimine kokku lepitud OpenAPI dokumendina. Iga klient genereeritakse sellest, mis teeb siit kõige odavama koha meelt muuta.
- 023.–5. nädal
Backend ja genereeritud kliendid
Go-teenus, andmemudel ja spetsist ehitatud tüübitud kliendid. Rakendusel on midagi päris, millega rääkida, juba enne esimest ekraani.
- 036.–11. nädal
Ehita rakendus
Ekraanid, navigatsioon, võrguühenduseta käitumine, push ja autentimine — lepingu vastu, mis on juba liikumise lõpetanud.
- 0412.–14. nädal
Esita ja itereeri
Allkirjastamine, etapiviisiline väljalase, vearaportid ühendatud ja esimene ülevaatuse tagasilükkamine vastu võetud ilma, et sellest kriisi saaks.
Pole kindel, kas rakendus on õige ehitus?
Tooge kasutusjuht. Me ütleme, kas see vajab poe kirjet, veebirakendust või lihtsalt API-t — sealhulgas siis, kui see vastus maksab meile projekti.
Lähenemise sobivus
Natiivne, platvormiülene või veebirakendus?
See otsus tehakse tavaliselt eelistuse pealt ja kaitstakse tagantjärele. Teha tuleks see selle põhjal, mida toode päriselt tegema peab.
| Lähenemine | Vali see, kui | Hind, millega nõustud |
|---|---|---|
| Platvormiülene | Toode on ekraanid andmete peal ja mõlemad platvormid peaksid käituma ühtemoodi | Platvormispetsiifiline viimistlus nõuab rohkem tööd; mõni natiivne API vajab silda |
| Täisnatiivne | Kaamera, andurid, taustatöötlus või kaadrisagedus ongi toode | Kaks koodibaasi, kaks väljalasketsüklit, umbes kaks kõike |
| Progressiivne veebirakendus | Poe kaudu levitamist pole vaja ja ulatus loeb rohkem kui seadme integratsioon | Nõrgem push ja taustatugi iOS-is; poes kohalolu üldse mitte |
| Veebirakendus kestas | Olemasolev veebitoode vajab poe kirjet rohkem kui natiivset käitumist | Ülevaatustiimid lükkavad õhukesed kestad tagasi ja see tundub nagu veebileht — sest ongi |
Lepingupõhine backend on kõigil neljal juhul identne, mis ongi mõte: kliendi valik lakkab olemast pöördumatu.
KKK
Küsimused, mida meilt küsitakse
Kas te olete varem mobiilirakendusi tarninud?
Meie avaldatud kliendilood on veebiplatvormid ja SaaS, nii et aus vastus on, et meie mobiilitõendus on API-kiht, mitte poe kirje, millele saaksime näpuga näidata. ERPFlow ehitati API-esimesena ühe OpenAPI lepingu peale just selleks, et veebi-, mobiili- ja AI-kliente saaks sellest teenindada. Kui teie lävi selle töö jaoks on allalaaditav rakendus meie portfellis, öelge seda varakult ja me ütleme ausalt, kas oleme õige pood.
Natiivne või platvormiülene?
Platvormiülene, kui toode ei ole päriselt andurite, kaamera, taustatöötluse või kaadrisageduse asi. Enamik ärirakendusi on ekraanid andmete peal ja kahe koodibaasi ülalpidamine selle jaoks on kulu ilma tuluta. Ülaltoodud tabel on see, mida me päriselt kasutame.
Kas saate rakenduse ehitada, kui backend on juba olemas?
Jah, ja esimene asi, mida me teeme, on kirjutada leping selle kohta, mis olemas on. Kui spetsifikatsiooni ei ole, koostame selle töötavast API-st ja kinnitame päris vastuste vastu — sest oletuse pealt genereeritud klient on klient, mis läheb vaikselt katki.
Kas me üldse vajame rakendust?
Sageli mitte. Kui pushi pole, võrguühenduseta kasutust pole ja ükski seadme võimekus mängus pole, jõuab kiire veebirakendus rohkemate inimesteni väiksema raha eest ja ilma ülevaatusjärjekorrata. Me pigem räägime teid rakendusest välja kui ehitame selle, mida keegi ei paigalda.
Kellele kuuluvad arendajakontod?
Teile, teie nimel, algusest peale. App Store'i ja Play kirjed, allkirjastamise sertifikaadid ja repositoorium on teie omad. Agentuuri konto sees pantvangis rakendused on hästi dokumenteeritud viis kaotada kontroll oma toote üle.
Kui kaua poe ülevaatus võtab?
Tavaliselt päevi, pluss see, mis esimene tagasilükkamine maksab. Esmaesitused lükatakse tagasi metaandmete, privaatsusdeklaratsioonide ja konto kustutamise nõuete pärast palju sagedamini kui koodi pärast, nii et me valmistame need ette enne esitamist, mitte pärast.
Kuidas te seda hinnastate?
Fikseeritud mahuga etapid spetsi vastu, nagu meie teistegi ehituste puhul. Lepingu etapp on hinnastatud eraldi ja meelega — seda tasub teha isegi siis, kui te sinna pidama jääte, sest spetsifikatsioon on teie oma ja seda saab mujale kaasa võtta.
Aga need AI-funktsioonid, mida kõik nüüd rakendusse tahavad?
Need kuuluvad sama lepingu taha nagu kõik muu, piiratud sellega, mida sisse loginud kasutaja näha tohib, ja mudelite marsruutimine läbi lüüsi. Assistent mobiilirakenduses, mis õigusi eirab, on andmelekke funktsioon ilusa animatsiooniga.
Alusta mobiiliprojekti
Kirjutage, mida rakendus tegema peab ja mis on juba olemas. Vastame ühe tööpäeva jooksul.