સેવા
મોબાઇલ એપ ડેવલપમેન્ટ
એવી એપ જે નેટવર્ક ન હોય ત્યારે પણ ચાલતી રહે.
એ ટીમો માટે જેમના વપરાશકર્તા ડેસ્ક પર બેસતા નથી — ફિલ્ડ સ્ટાફ, સાઇટ સુપરવાઇઝર, ડિલિવરી ટીમો, રસ્તા પર સેલ્સ — અને એ ગ્રાહક-મુખી એપ માટે જ્યાં પહેલી મિનિટ નક્કી કરે છે કે એપ રખાશે કે નહીં. અહીં જે એન્જિનિયરિંગ મહત્ત્વની છે તે ઓફલાઇન વર્તન અને સિંક છે, સ્ક્રીન નહીં.
નિર્ણય
આ ક્યારે સાચો નિર્ણય છે.
મોટા ભાગની મોબાઇલ એપ ઓફિસ વાઇ-ફાઇ પર બતાવાય છે અને સાઇટના ગેટ પર નબળા 4G કનેક્શન પર વપરાય છે. એ જ તફાવત એ જગ્યા છે જ્યાં તે નિષ્ફળ જાય છે. જે એપ કનેક્ટિવિટી માની લે છે, તેના પર એ ડેટા ગુમાવવાનો આરોપ આવશે જે તેને ક્યારેય મળ્યો જ નહોતો — અને એક વાર ફિલ્ડ સ્ટાફનો ભરોસો તૂટે, તો તેઓ કાગળ પર પાછા જાય છે, જે બરાબર એ જ પરિણામ છે જેને રોકવા પ્રોજેક્ટને પૈસા મળ્યા હતા.
સિંક જ મુશ્કેલ ભાગ છે, અને સામાન્ય રીતે એ જ ભાગ છે જેને એક વાક્યમાં પતાવી દેવાયો હતો. શું થાય જ્યારે બે જણ ઓફલાઇન રહીને એક જ રેકોર્ડ બદલે, જ્યારે ફોન ત્રણ દિવસ પછી ઓનલાઇન પાછો આવે, જ્યારે સર્વર ત્યાં સુધી નિયમો બદલી ચૂક્યું હોય. આ ડિઝાઇન નિર્ણયો છે, અને જો કોઈ આ ન લે, તો એપ પોતે જ ડિફોલ્ટ રૂપે ખોટા નિર્ણયો લઈ લે છે.
અમે બનાવતાં પહેલાં ટકરાવનું મોડલ નક્કી કરીએ છીએ, ઓફલાઇનને અપવાદ નહીં પણ સામાન્ય સ્થિતિ ગણીએ છીએ, અને વાઇ-ફાઇને બદલે ધીમા કનેક્શન પર ચકાસીએ છીએ. સ્ક્રીન તો સહેલો અડધો ભાગ છે.
તમને શું મળે છે
કામમાં શું સમાયેલું છે.
ઓફલાઇન-ફર્સ્ટ ડેટા
સેશન માટે સ્થાનિક સ્ટોરેજ જ સત્યનો સ્રોત, સાથે એવી કતાર જે એપ બંધ કરી દેવાય તોય બચી રહે, અને વિચારીને પસંદ કરેલો ટકરાવનો નિયમ.
એવું સિંક જેને તમે તપાસી શકો
સિંકની સ્થિતિ વપરાશકર્તા અને સહાય ટીમ બંનેને દેખાય છે, જેથી 'સેવ ન થયું' એવો પ્રશ્ન બને જેનો જવાબ હોય.
નેટિવ કે ક્રોસ-પ્લેટફોર્મ
Kotlin અને Swift ત્યાં જ્યાં હાર્ડવેર, બેકગ્રાઉન્ડ કામ કે પરફોર્મન્સ માગ કરે; અને વહેંચાયેલો કોડબેઝ ત્યાં જ્યાં એપ મોટે ભાગે સ્ક્રીન હોય અને બચત ખરેખર થતી હોય.
બેકગ્રાઉન્ડ કામ જે ચાલુ રહે
નિર્ધારિત સિંક અને અપલોડ જે Android ની બેટરી મર્યાદાઓ છતાં ચાલતું રહે, અને એ વેન્ડર સ્કિન પર ચકાસાયેલું હોય જે તેને તોડે છે.
એવું ઓથેન્ટિકેશન જે સલામત રીતે નિષ્ફળ જાય
ટોકન એક્સપાયરી બરાબર સંભાળાય છે — સમાપ્ત સેશન વપરાશકર્તાને સાઇન આઉટ કરી દે છે, મરેલી વિનંતી કાયમ ફરી મોકલતું રહેતું નથી.
રિલીઝ એન્જિનિયરિંગ
સાઇન કરેલા બિલ્ડ, તબક્કાવાર રોલઆઉટ, ક્રેશ રિપોર્ટિંગ અને એપની અંદર અપડેટ સંકેત, જેથી ખરાબ રિલીઝ રોકી શકાય.
સ્ટૅક
અમે તે શાનાથી બનાવીએ છીએ.
દરેક પ્રોજેક્ટ પ્રમાણે પસંદ કરેલા. અહીં કશું પણ ડિફોલ્ટ રૂપે લગાવાતું નથી, અને જે ટીમ આગળ તેને સંભાળશે તે સમસ્યા જેટલી જ મહત્ત્વની છે.
Android
Kotlin સાથે Jetpack Compose, સ્થાનિક સ્ટોરેજ માટે Room, બેકગ્રાઉન્ડ સિંક માટે WorkManager.
iOS
Swift સાથે SwiftUI, અને કોઈ બ્રિજ સ્તરને બદલે પ્લેટફોર્મનું પોતાનું પર્સિસ્ટન્સ.
ક્રોસ-પ્લેટફોર્મ
React Native કે Flutter, જ્યાં એપ સ્ક્રીન-પ્રધાન હોય અને એક કોડબેઝ ખરેખર અડધું કામ બચાવે.
બેકએન્ડ
એ જ API જે તમારું વેબ પ્લેટફોર્મ વાપરે છે, અને તે વર્ઝનવાળું હોય જેથી ફિલ્ડમાં પડેલી જૂની એપ ચાલતી રહે.
વિતરણ
Play Store અને App Store, કે જ્યાં એપ આંતરિક હોય ત્યાં સંચાલિત એન્ટરપ્રાઇઝ વિતરણ.
સરખામણી
ક્રોસ-પ્લેટફોર્મ સામે નેટિવ.
મોબાઇલ પ્રોજેક્ટનો પહેલો ખરો નિર્ણય. અમે બંને બનાવીએ છીએ, તેથી આ કોષ્ટક કોઈ એકની તરફેણની પિચ નહીં, ખરી દલીલ છે.
| પાસું | ક્રોસ-પ્લેટફોર્મ | નેટિવ |
|---|---|---|
| કોના માટે સૌથી યોગ્ય | ફોર્મ, યાદીઓ, સિંક — એવી એપ જે મોટે ભાગે API ઉપરની સ્ક્રીન છે | કેમેરા, બેકગ્રાઉન્ડ લોકેશન, બ્લૂટૂથ કે સતત ટકતી પરફોર્મન્સ |
| બે પ્લેટફોર્મનો ખર્ચ | આશરે એક બિલ્ડ, સાથે પ્લેટફોર્મ-વિશેષ ફિનિશિંગ | લગભગ બે બિલ્ડ, અને પછી બે કોડબેઝ સંભાળવા પડે |
| ઓફલાઇન અને સિંક | સંપૂર્ણપણે શક્ય છે; ફ્રેમવર્ક કરતાં સિંકની ડિઝાઇન ઘણી વધુ મહત્ત્વની છે | એ જ — આ ડેટા-મોડલનો નિર્ણય છે, પ્લેટફોર્મનો નહીં |
| હાર્ડવેર અને OS ની સુવિધાઓ | સામાન્ય બાબતો માટે ઠીક છે; કશું અસામાન્ય હોય તો તોય નેટિવ મોડ્યુલ જોઈએ | સીધી પહોંચ, અને વેન્ડર વર્તન બદલે ત્યારે ડીબગ કરવા કોઈ બ્રિજ નહીં |
| Android ની બેટરી મર્યાદાઓ હેઠળ બેકગ્રાઉન્ડ કામ | ચાલે છે, પણ વેન્ડરની આક્રમક સ્કિન બંને સંજોગોમાં ચકાસવી પડે છે | નિયંત્રણ કરવું સહેલું, અને ડિવાઇસ પ્રોસેસ બંધ કરે તો નિદાન કરવું પણ સહેલું |
| લાંબા ગાળાની જાળવણી | એક કોડબેઝ, સાથે એક ફ્રેમવર્ક જેનું પોતાનું અપગ્રેડ ચક્ર છે | બે કોડબેઝ, પણ દરેક પોતાના પ્લેટફોર્મના સારી રીતે દસ્તાવેજીકૃત માર્ગ પર |
આ કેવી રીતે ચાલે છે
પહેલી વાતચીતથી લાઇવ થવા સુધી.
આ પ્રકારના કામ માટે અંદાજિત. પાયલટ વૈકલ્પિક નથી — જ્યાં સુધી વાપરનારા એમ ન કહે કે આ ટકે છે, ત્યાં સુધી કશું સ્વિચ કરાતું નથી.
- 1 અઠવાડિયું
ડિસ્કવરી
અમે કશું પણ ડિઝાઇન કરતાં પહેલાં નક્કી કરીએ છીએ કે ટકરાવ કેવી રીતે ઉકેલાશે અને ઓફલાઇનમાં શું થશે. આમાંનું કોઈ પણ પછીથી ઉમેરવું લગભગ ફરી લખવા બરાબર છે.
- 4-8 અઠવાડિયાં
મુખ્ય નિર્માણ
પહેલાં સ્થાનિક સ્ટોરેજ, સિંક કતાર અને મુખ્ય કાર્ય-માર્ગ, અને તેમની ચકાસણી ઓફિસ વાઇ-ફાઇ પર નહીં, ધીમા કનેક્શન પર.
- 2-3 અઠવાડિયાં
ફિલ્ડ પાયલટ
ખરા વપરાશકર્તા પોતાના જ ફોન પર — સસ્તા ફોન સહિત — જ્યારે કાગળવાળી પ્રક્રિયા ચાલુ રહે છે. ઓફલાઇન વિશે બાંધેલી ધારણાઓ અહીં જ સુધરે છે.
- 1-2 અઠવાડિયાં
રિલીઝ
સ્ટોર સબમિશન કે સંચાલિત વિતરણ, તબક્કાવાર રોલઆઉટ, ક્રેશ રિપોર્ટિંગ, અને એપની અંદર અપડેટ સંકેત જેથી ખરાબ બિલ્ડ રોકી શકાય.
લોન્ચ પછી
શું બદલાય છે.
- ફિલ્ડ સ્ટાફ બીજા મહિના પછી પણ તેને વાપરતો રહે છે — ફિલ્ડ એપની ખરી કસોટી એ જ છે.
- 'સેવ ન થયું' એવો પ્રશ્ન બની જાય છે જેનો જવાબ છે, કારણ કે સિંકની સ્થિતિ વપરાશકર્તા અને સહાય ટીમ બંનેને દેખાય છે.
- ત્રણ દિવસથી ઓફલાઇન પડેલો ફોન કોઈનું કામ ગુમાવ્યા વગર મેળ કરી લે છે.
- ફિલ્ડમાં પડેલું જૂનું વર્ઝન પણ ચાલતું રહે છે, કારણ કે API વર્ઝનવાળું છે, હાલનું માની લેવાયેલું નહીં.
જાણી જોઈને ગુણાત્મક રૂપે જણાવેલું. અમે એવા ટકાવારી સુધારા પ્રકાશિત કરતા નથી જેમને અમે કોઈ નામી ક્લાયન્ટ સાથે, તેમની સંમતિથી, જોડી ન શકીએ.
પ્રશ્નો
સામાન્ય પ્રશ્નો.
નેટિવ કે ક્રોસ-પ્લેટફોર્મ — અમારે શું પસંદ કરવું?
જો એપ મોટે ભાગે ફોર્મ, યાદીઓ અને સિંક હોય, તો સામાન્ય રીતે ક્રોસ-પ્લેટફોર્મનું ગણિત બેસે છે. જો તે કેમેરા, બેકગ્રાઉન્ડ લોકેશન, બ્લૂટૂથ હાર્ડવેર કે સતત ટકતી પરફોર્મન્સ પર આધાર રાખે, તો નેટિવ પોતાનો વધારાનો ખર્ચ વસૂલ કરી લે છે. અમે ભલામણ અમારી પસંદથી નહીં, એનાથી કરીએ છીએ કે એપ ખરેખર કરે છે શું.
શું તે ઇન્ટરનેટ વગર ચાલશે?
જ્યાં ઉપયોગની માગ હોય, ત્યાં તે શરૂઆતથી જ ડિઝાઇનમાં રખાય છે. રેકોર્ડ સ્થાનિક રીતે લખાય છે, કતારમાં મુકાય છે, અને કનેક્શન પાછું આવતાં સિંક થાય છે — અને એ કતાર એપ બંધ થાય કે ફોન રીસ્ટાર્ટ થાય તોય બચી રહે છે.
શું તમે અમારા માટે સ્ટોર પર એપ પ્રકાશિત કરો છો?
હા, સ્ટોર લિસ્ટિંગ, સ્ક્રીનશોટ અને સમીક્ષાના જવાબો સહિત. એકાઉન્ટ તમારા જ નામે રહે છે — અમે ક્યારેય કોઈ ક્લાયન્ટનું સ્ટોર એકાઉન્ટ અમારી પાસે રાખતા નથી.
શું તે અમારી હાલની સિસ્ટમ સાથે ચાલી શકે?
હા. અમે જે મોટા ભાગની મોબાઇલ એપ બનાવીએ છીએ, તે પહેલેથી હાજર કોઈ સિસ્ટમ પર ફિલ્ડ તરફ ખૂલતું સ્તર હોય છે, પોતાના અલગ ડેટાવાળું અલગ ઉત્પાદન નહીં.
શું તમે બીજા કોઈની બનાવેલી એપ આગળ સંભાળી શકો?
સામાન્ય રીતે હા. અમે કોડબેઝ, રિલીઝ સેટઅપ અને સ્ટોર એકાઉન્ટની ટૂંકી સમીક્ષાથી શરૂ કરીએ છીએ અને જણાવીએ છીએ કે તેમાં શું લાગશે. જો સત્ય એ હોય કે ફરી બનાવવું સંભાળવા કરતાં સસ્તું છે, તો અમે એ જ કહીશું અને તેનો તર્ક પણ બતાવીશું.
શું અમને એપની જરૂર પણ છે, કે મોબાઇલ સાઇટથી ચાલી જશે?
એક રિસ્પોન્સિવ સાઇટ ઘણું સંભાળી લે છે અને ઘણી સસ્તી પડે છે. એપ ત્યારે જ પોતાનો ખર્ચ વસૂલ કરે છે જ્યારે તમને ઓફલાઇન ક્ષમતા, હાર્ડવેર પહોંચ, બેકગ્રાઉન્ડ કામ કે પુશ નોટિફિકેશન જોઈએ. આમાંનું કશું લાગુ ન પડે, તો અમે તમને સસ્તો જવાબ જ બતાવીશું.