ફીલ્ડ ઍપ કેમ નિષ્ફળ જાય છે: ઑફલાઇન-ફર્સ્ટ મોબાઇલ સૉફ્ટવેર બનાવવું

આ પૅટર્ન એટલી સરખી છે કે તેની આગાહી કરી શકાય. એક ફીલ્ડ ઍપ બનાવડાવાય છે, કુશળતાથી બને છે, સફળતાપૂર્વક બતાવાય છે અને લાગુ કરાય છે. બે મહિનાની અંદર ફીલ્ડ ટીમ ફરી કાગળ પર છે, અને અપાતું કારણ એ કે 'એ ડેટા ગુમાવતી રહેતી હતી'. સામાન્ય રીતે તેણે ડેટા ગુમાવ્યો નહોતો — તે તેને મેળવી જ શકી નહોતી, પછી કશું બોલી નહીં, અને ગેટ પર ઊભેલી વ્યક્તિ માટે આ ભેદ અદૃશ્ય છે.

એક વાર ફીલ્ડ સ્ટાફનો ઍપ પરથી ભરોસો ઊઠી જાય, તો તેઓ તેનો ઉપયોગ બંધ કરી દે છે, અને ગમે તેટલી સુવિધાઓ તેમને પાછા લાવતી નથી. ભરોસો જ ખરું ઉત્પાદન છે, અને તે એનાથી નક્કી થાય છે કે ખરાબ કનેક્શન પર ઍપ શું કરે છે.

કનેક્ટિવિટી વિશેની ધારણાઓ કેમ તૂટે છે

ઑફિસ વાઇ-ફાઇ સાઇટ કનેક્શનનું નબળું સંસ્કરણ નથી — એ અલગ વસ્તુ છે. સાઇટ પર કવરેજ ધીમું નહીં, તૂટક તૂટક હોય છે: ઑફિસ પાસે પૂરું સિગ્નલ, માળખાની પાછળ કશું નહીં, અને ગ્રાહકની ઇમારતમાં એક કૅપ્ટિવ પોર્ટલ જે દરેક વિનંતી પર બૉડીમાં લૉગિન પેજ સાથે HTTP 200 પાછું આપે છે.

એ છેલ્લી સ્થિતિ પર રોકાવું સાર્થક છે, કારણ કે તે ભોળી કનેક્ટિવિટી ચકાસણીને હરાવી દે છે. ડિવાઇસ નેટવર્ક બતાવે છે. વિનંતી સફળ થાય છે. પ્રતિસાદ એ નથી જે માગ્યો હતો. જે ઍપ 'કનેક્શન છે કે' ચકાસે છે એને બદલે કે 'સર્વરે ખરેખર જવાબ આપ્યો કે', તે ખુશીથી માની લેશે કે તેણે કંઈક સેવ કરી લીધું છે જે થયું નથી.

બીજી ધારણા જે તૂટે છે તે અવધિની છે. જે ઍપ મિનિટોમાં સિંકની અપેક્ષા રાખે છે તે એનાથી અલગ વર્તે છે જેને ત્રણ દિવસ ઑફલાઇન રહેલા ડિવાઇસને સંભાળવાનું છે, જે દરમિયાન સર્વરનો ડેટા આગળ વધી ગયો છે. ફીલ્ડ કામમાં બીજો જ સામાન્ય કિસ્સો છે અને તે ડિઝાઇન બદલી નાખે છે.

ઑફલાઇન-ફર્સ્ટ એટલે સ્થાનિક સ્ટોર જ સત્ય છે

ભેદ 'અમે કેટલીક વસ્તુઓ કૅશ કરીએ છીએ' એવો નથી. ઑફલાઇન-ફર્સ્ટ ડિઝાઇનમાં સ્થાનિક ડેટાબેઝ જ એ જગ્યા છે જ્યાં વપરાશકર્તાનું કામ રહે છે, લખાણ સ્થાનિક રીતે પૂરું થઈને તરત પાછું આવે છે, અને સિંક્રનાઇઝેશન એક બૅકગ્રાઉન્ડ પ્રક્રિયા છે જે પછીથી સર્વર સાથે મેળ બેસાડે છે. નેટવર્ક એક વધારો છે, પૂર્વશરત નહીં.

આ સામાન્ય ભૂલ સંભાળવાને ઊલટાવી નાખે છે. ઑનલાઇન-ફર્સ્ટ ઍપમાં નેટવર્ક ન હોવું એ ભૂલ છે જેની સાથે વપરાશકર્તાએ પનારો પાડવાનો છે. ઑફલાઇન-ફર્સ્ટ ઍપમાં નેટવર્ક ન હોવું સામાન્ય સ્થિતિ છે અને ઇન્ટરફેસ એ જ બતાવે છે — રેકોર્ડ સેવ છે, કતારમાં છે, જ્યારે જઈ શકશે ત્યારે જશે, અને વપરાશકર્તા જોઈ શકે છે કે એ સાચું છે.

કૉન્ફ્લિક્ટ મૉડેલ વિચારીને પસંદ કરો

બે લોકો એક જ રેકોર્ડ સંપાદિત કરે છે અને બંને ઑફલાઇન છે. પછી જે થાય તે જ તમારું કૉન્ફ્લિક્ટ મૉડેલ છે, અને જો કોઈએ પસંદ ન કર્યું હોય તો કોડે અકસ્માતે પસંદ કરી લીધું — સામાન્ય રીતે લાસ્ટ-રાઇટ-વિન્સ, ચૂપચાપ, અને એક વ્યક્તિનું કામ ગાયબ.

કામ લાગે એવા વિકલ્પો થોડા જ છે, અને સાચો વિકલ્પ ડેટા પર આધાર રાખે છે.

• લાસ્ટ-રાઇટ-વિન્સ એવાં ફીલ્ડ માટે સ્વીકાર્ય છે જે ખરેખર સ્વતંત્ર હોય અને એવા ડેટા માટે જ્યાં થોડું જૂનું હોવું નુકસાનકારક નથી. કોઈપણ નાણાકીય બાબત માટે, કે જેના પર વિવાદ જોડાઈ શકે, તે ખોટી પસંદગી છે.
• અપેન્ડ-ઓન્લી ઇવેન્ટ લૉગ ક્યારેય જગ્યાએ સંપાદન ન કરીને કૉન્ફ્લિક્ટ સંપૂર્ણપણે ટાળે છે. હાજરીની નોંધ, સામગ્રી નિર્ગમ, સ્ટૉક હલનચલન અને નિરીક્ષણ રેકોર્ડ બધાં આમાં કુદરતી રીતે બંધબેસે છે — હાજરી પૂરતા બે સુપરવાઇઝર હકીકતો ઉમેરી રહ્યા છે, એકબીજા પર લખવાની હોડમાં નહીં.
• ફીલ્ડ-સ્તરનું મર્જ ત્યારે કામ કરે છે જ્યારે એક રેકોર્ડના ભાગો અલગ અલગ ભૂમિકાઓ હેઠળ હોય, જેથી બે સંપાદન સામાન્ય રીતે એક જ ફીલ્ડને ન અડે.
• સ્પષ્ટ ઉકેલ — બંને સંસ્કરણ બતાવીને પૂછવું — ત્યાં યોગ્ય છે જ્યાં ડેટા એટલો મહત્ત્વનો હોય કે કોઈનું ધ્યાન માગે, અને અસહ્ય છે જો એવું વારંવાર થાય. જો તમારા મૉડેલને એ વારંવાર જોઈતું હોય, તો મૉડેલ ખોટું છે.

ફીલ્ડ કામગીરીમાં અપેન્ડ-ઓન્લી ટીમોની ધારણા કરતાં ઘણા વધુ કિસ્સાઓમાં બંધબેસે છે, અને તે સૌથી કઠિન શ્રેણીના બગને રચનાથી જ દૂર કરે છે. ત્યાં પહોંચવા ડેટાનું પુનર્ગઠન કરવું સાર્થક છે.

કતાર જ એ ભાગ છે જે સંપૂર્ણપણે અભેદ્ય હોવો જોઈએ

વપરાશકર્તા ઑફલાઇન જે કંઈ કરે તે કતારમાં જાય છે, અને દરેક ગંભીર નિષ્ફળતા ત્યાં જ વસે છે. કતારે ઓપરેટિંગ સિસ્ટમ દ્વારા ઍપ બંધ કરાવું, ફોન રીસ્ટાર્ટ થવું, અને ઍપનું એવા સંસ્કરણમાં અપડેટ થવું જેનું ડેટા સ્વરૂપ બદલાયું છે — એ બધાંમાં ટકવું જોઈએ.

ત્રણ નિયમો આને ભરોસાપાત્ર બનાવે છે. કતારના દરેક ઑપરેશન સાથે ક્લાયન્ટે બનાવેલો ઓળખકર્તા જાય જેથી સર્વર ડુપ્લિકેટ ઓળખી શકે — ફરી પ્રયાસ નિશ્ચિત છે, અને આઇડેમ્પોટન્સી વગર તે ડુપ્લિકેટ રેકોર્ડ બનાવે છે. જ્યાં ક્રમ મહત્ત્વનો છે ત્યાં ઑપરેશન ક્રમમાં લાગુ થાય, કારણ કે પોતાના જ અપડેટ પછી પહોંચેલું create ડેટા-હાનિનો બગ છે. અને કાયમી રીતે નિષ્ફળ થતી આઇટમને હંમેશાં ફરી અજમાવવાને બદલે અલગ કરીને સામે લાવવી જોઈએ, નહીંતર એક ખરાબ રેકોર્ડ તેની પાછળના દરેક સારા રેકોર્ડને રોકી દે છે.

એ છેલ્લી સ્થિતિ ઉત્પાદનમાં સૌથી સામાન્ય નિષ્ફળતા છે. જે રેકોર્ડને સર્વર કોઈ વૅલિડેશન કારણે નકારે છે તે કતારની આગળ બેસીને ફરી ફરી પ્રયાસ કરતો રહે છે, અને તેની પાછળ બધું રાહ જુએ છે. ફોન 'સિંક થઈ રહ્યું છે' બતાવે છે. બે દિવસથી કશું સિંક થયું નથી.

સિંકની સ્થિતિ દેખાય તેવી રાખો

વપરાશકર્તાઓ એ ઍપને માફ કરી દે છે જે સર્વર સુધી પહોંચી શકતી નથી. તેઓ એ ઍપને માફ કરતા નથી જે તેમને કહી શકતી નથી કે પહોંચી કે નહીં. દરેક રેકોર્ડ બતાવે કે તે સ્થાનિક રીતે સેવ છે, કતારમાં છે, સિંક થઈ ગયો છે કે નિષ્ફળ ગયો, અને એવી એક સ્ક્રીન હોય જે કહે કે છેલ્લું સફળ સિંક ક્યારે થયું અને કેટલી આઇટમ રાહ જુએ છે.

આ સપોર્ટને પણ બદલી નાખે છે. 'સેવ નથી થયું' નો કોઈ જવાબ નથી. 'ત્રણ આઇટમ કતારમાં, છેલ્લું સિંક 2 દિવસ પહેલાં, એક વૅલિડેશન ભૂલ પર નિષ્ફળ' એવો પ્રશ્ન છે જેનો જવાબ છે, અને એ જવાબ ફોન પર આપી શકાય છે.

બૅકગ્રાઉન્ડ કામ જે ખરેખર ચાલે છે

Android નું બૅટરી ઑપ્ટિમાઇઝેશન ભોળા બૅકગ્રાઉન્ડ સિંકને રોકી દેશે, અને ઉત્પાદકોની સ્કિન સ્ટૉક Android કરતાં વધુ આક્રમક છે — કેટલીક તો ઘણી વધુ. જે ઍપ Pixel પર ભરોસાપૂર્વક સિંક કરે છે તે એવા ફોન પર બિલકુલ સિંક ન કરે જેનો ઉત્પાદક બૅકગ્રાઉન્ડ કામ આક્રમક રીતે બંધ કરે છે, અને એવા ફોન બરાબર એ જ કિંમત શ્રેણીમાં સામાન્ય છે જે ફીલ્ડ સ્ટાફ પાસે હોય છે.

ટાઇમરને બદલે પ્લેટફોર્મનું પોતાનું શેડ્યુલર વાપરો, ઍપ આગળ આવે ત્યારે તક મળતાં સિંક કરો, અને જે વસ્તુનું થવું વપરાશકર્તા માટે જરૂરી છે તેના માટે માત્ર બૅકગ્રાઉન્ડ કામ પર ક્યારેય આધાર ન રાખો. ડેવલપરના ડિવાઇસ પર નહીં, એ સસ્તા ફોન પર પરીક્ષણ કરો જે તમારા વપરાશકર્તાઓ રાખે છે.

તેમની પાસે જે નેટવર્ક છે તેના પર પરીક્ષણ કરો

• આખા કામકાજના દિવસ માટે એરોપ્લેન મોડ, પછી ફરી જોડીને ચકાસો કે બધું બરાબર એક જ વાર પહોંચે છે.
• માત્ર ધીમું નહીં, પણ મર્યાદિત અને ડેટા ગુમાવતું કનેક્શન — નિષ્ફળતાના પ્રકારો અલગ છે, અને વસ્તુઓ ડેટા ગુમાવવાથી જ તૂટે છે.
• એક કૅપ્ટિવ પોર્ટલ જે લૉગિન પેજ સાથે 200 પાછું આપે છે, એ ખાતરી કરવા કે ઍપ કનેક્શન નહીં પણ પ્રતિસાદ તપાસે છે.
• સિંક વચ્ચે ઍપ બંધ કરો, સિંક વચ્ચે ફોન રીસ્ટાર્ટ કરો, અને ખાતરી કરો કે કતાર બંનેમાં ટકી રહે છે.
• બે ડિવાઇસ ઑફલાઇન રહીને એક જ રેકોર્ડ સંપાદિત કરતાં, એ ખાતરી કરવા કે કૉન્ફ્લિક્ટ મૉડેલ એ જ કરે છે જે તમે નક્કી કર્યું, નહીં કે જે ફ્રેમવર્ક આપમેળે કરે છે.
• જૂનું ઍપ સંસ્કરણ વર્તમાન સર્વર સાથે સિંક કરતું, કારણ કે ફીલ્ડ ડિપ્લોયમેન્ટમાં કોઈક હંમેશાં ત્રણ સંસ્કરણ પાછળ હોય છે.

સારાંશ

ઑફલાઇન અંતે ઉમેરવાની સુવિધા નથી. તે ડેટા મૉડેલ, કૉન્ફ્લિક્ટના નિયમો, કતારની ડિઝાઇન અને ઇન્ટરફેસ નક્કી કરે છે, અને તેને પાછળથી ઉમેરવું લગભગ ફરી લખવા જેવું છે. તેને પહેલાં નક્કી કરો, સ્થાનિક સ્ટોરને પ્રામાણિક બનાવો, કૉન્ફ્લિક્ટ મૉડેલ સ્પષ્ટપણે પસંદ કરો, સિંકની સ્થિતિ દેખાય તેવી રાખો, અને સારા નહીં પણ ખરાબ કનેક્શન પર પરીક્ષણ કરો.