04 ਦਸੰ 2025·8 ਮਿੰਟ
ਆਫਲਾਈਨ ਚੈਕਲਿਸਟ ਲਈ ਮੋਬਾਈਲ ਐਪ ਕਿਵੇਂ ਬਣਾਈਏ (ਕਦਮ-ਦਰ-ਕਦਮ)
ਇੰਟਰਨੈੱਟ ਬਿਨਾਂ ਕੰਮ ਕਰਨ ਵਾਲੀ ਮੋਬਾਈਲ ਚੈਕਲਿਸਟ ਐਪ ਨੂੰ ਕਿਵੇਂ ਡਿਜ਼ਾਈਨ, ਬਣਾਉ ਅਤੇ ਟੈਸਟ ਕਰਨਾ ਹੈ ਸਿੱਖੋ: ਲੋਕਲ ਸਟੋਰੇਜ, ਸਿੰਕ, ਟਕਰਾਅ, ਸੁਰੱਖਿਆ ਅਤੇ ਰਿਲੀਜ਼ ਟਿੱਪਸ।
ਇੰਟਰਨੈੱਟ ਬਿਨਾਂ ਕੰਮ ਕਰਨ ਵਾਲੀ ਮੋਬਾਈਲ ਚੈਕਲਿਸਟ ਐਪ ਨੂੰ ਕਿਵੇਂ ਡਿਜ਼ਾਈਨ, ਬਣਾਉ ਅਤੇ ਟੈਸਟ ਕਰਨਾ ਹੈ ਸਿੱਖੋ: ਲੋਕਲ ਸਟੋਰੇਜ, ਸਿੰਕ, ਟਕਰਾਅ, ਸੁਰੱਖਿਆ ਅਤੇ ਰਿਲੀਜ਼ ਟਿੱਪਸ।
ਉਹਨਾਂ ਫੈਸਲਿਆਂ ਤੋਂ ਪਹਿਲਾਂ ਜੋ ਬੇਸਿਕ ਤਕਨੀਕੀ ਚੋਣਾਂ ਤੇ ਅਸਰ ਪਾਉਂਦੇ ਹਨ, ਇਹ ਦਰਸਾਓ ਕਿ ਕੌਣ ਆਫਲਾਈਨ ਚੈਕਲਿਸਟ ਤੇ ਨਿਰਭਰ ਕਰੇਗਾ—ਅਤੇ "ਆਫਲਾਈਨ" ਉਹਨਾਂ ਲਈ ਅਸਲ ਵਿੱਚ ਕੀ ਮਤਲਬ ਰੱਖਦਾ ਹੈ। ਘਰ ਦੇ ਆਯੋਜਕ ਵੱਲੋਂ ਵਰਤੀ ਜਾਣ ਵਾਲੀ ਐਪ ਦੀ ਉਮੀਦ ਇਕ ਅਜਿਹੀ ਐਪ ਤੋਂ ਕਾਫੀ ਵੱਖਰੀ ਹੋ ਸਕਦੀ ਹੈ ਜੋ ਬੇਸਮੈਂਟ, ਫੈਕਟਰੀਆਂ ਜਾਂ ਪੇਂਡੂ ਸਾਈਟਾਂ 'ਤੇ ਇੰਸਪੈਕਟਰ ਵਰਤਦੇ ਹਨ।
ਪਹਿਲਾਂ ਪ੍ਰਾਇਮਰੀ ਯੂਜ਼ਰਾਂ ਅਤੇ ਉਹਨਾਂ ਦੇ ਵਾਤਾਵਰਣ ਦਾ ਨਾਮ ਲਿਖੋ:
ਹਰ ਸਮੂਹ ਲਈ ਡਿਵਾਈਸ-ਸੰਬੰਧੀ ਸੀਮਾਵਾਂ (ਸ਼ੇਅਰਡ ਡਿਵਾਈਸ ਜਾਂ ਪर्सਨਲ), ਆਮ ਸੈਸ਼ਨ ਦੀ ਲੰਬਾਈ ਅਤੇ ਉਹ ਕਿੰਨੀ ਵਾਰ ਆਨਲਾਈਨ ਵਾਪਸ ਆਉਂਦੇ ਹਨ, ਨੋਟ ਕਰੋ।
ਕਨੈਕਟਿਵਟੀ ਦੇ ਬਾਰੇ ਸੋਚਣ ਦੇ ਬਗੈਰ ਯੂਜ਼ਰਾਂ ਨੂੰ ਜਿਹੜੀਆਂ ਮੁੱਖ ਕਾਰਵਾਈਆਂ ਬਿਨਾਂ ਸੋਚੇ-ਸਮਝੇ ਪੂਰੀਆਂ ਕਰਨੀ ਚਾਹੀਦੀਆਂ ਹਨ, ਉਹ ਲਿਖੋ:
ਉਹ “ਚੰਗਾ-ਹੋਵੇ” ਵਾਲੀਆਂ ਕਾਰਵਾਈਆਂ ਭੀ ਲਿਖੋ ਜੋ ਬਾਅਦ ਵਿੱਚ ਕੀਤੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ (ਜਿਵੇਂ ਗਲੋਬਲ ਇਤਿਹਾਸ ਲਈ ਖੋਜ, ਰਿਪੋਰਟਸ ਐਕਸਪੋਰਟ ਕਰਨਾ)।
ਸਪੱਸ਼ਟ ਕਰੋ ਕਿ ਕੀ-ਕਹਾਂ ਕੰਮ ਪੂਰੀ ਤਰ੍ਹਾਂ ਆਫਲਾਈਨ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ (ਨਵਾਂ ਚੈਕਲਿਸਟ ਰਨ ਬਣਾਉਣਾ, ਤੁਰੰਤ ਪ੍ਰਗਟਿ ਸੇਵ ਕਰਨਾ, ਫੋਟੋ ਜੁੜਨਾ) ਅਤੇ ਕਿਹੜਾ ਕੰਮ ਮੂਲਤ: ਬਾਅਦ ਵਿੱਚ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ (ਮੀਡੀਆ ਅਪਲੋਡ, ਟੀਮਮੇਟਸ ਨਾਲ ਸਿੰਕ, ਐਡਮਿਨ ਸੰਪਾਦਨ)।
ਜੇ ਤੁਸੀਂ ਕੰਪਲਾਇਅੰਸ ਨਿਯਮਾਂ ਦੇ ਅਧੀਨ ਹੋ, ਤਾਂ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਲੋੜਾਂ ਨਿਰਧਾਰਿਤ ਕਰੋ: ਭਰੋਸੇਯੋਗ ਟਾਈਮਸਟੈਂਪ, ਯੂਜ਼ਰ ਪਛਾਣ, ਇਕ ਅਟੂਟ activity log, ਅਤੇ ਜਮ੍ਹਾਂ-ਕਰਨ ਤੋਂ ਬਾਅਦ ਸੰਪਾਦਨ 'ਤੇ ਨਿਯਮ। ਇਹ ਫੈਸਲੇ ਤੁਹਾਡੇ ਡੇਟਾ ਮਾਡਲ ਅਤੇ ਆਊਟ-ਆਫ-ਬਾਕਸ ਸਿੰਕ ਡਿਜ਼ਾਈਨ 'ਤੇ ਪ੍ਰਭਾਵ ਪਾਉਂਦੇ ਹਨ।
ਆਫਲਾਈਨ ਚੈਕਲਿਸਟ ਐਪ ਇੱਕ ਪ੍ਰਾਰੰਭਿਕ ਫ਼ੈਸਲੇ 'ਤੇ ਨਿਰਭਰ ਕਰਕੇ ਕਾਮਯਾਬ ਜਾਂ ਨਾਕਾਮ ਹੁੰਦਾ ਹੈ: offline-first ਜਾਂ online-first with offline fallback।
Offline-first ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਐਪ ਫੋਨ ਨੂੰ ਪ੍ਰਾਇਮਰੀ ਥਾਂ ਮੰਨਦਾ ਹੈ ਜਿੱਥੇ ਕੰਮ ਹੁੰਦਾ ਹੈ। ਨੈੱਟਵਰਕ ਇਕ "ਓਖਾ-ਨੀਹ" ਨਹੀਂ ਹੈ: ਸਿੰਕ ਬੈਕਗ੍ਰਾਊਂਡ ਟਾਸਕ ਹੈ, ਐਪ ਦੀ ਵਰਤੋਂ ਲਈ ਲਾਜ਼ਮੀ ਨਹੀਂ।
Online-first with offline fallback ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਸਰਵਰ ਆਮ ਤੌਰ 'ਤੇ ਸੱਚਾਈ ਦਾ ਸਰੋਤ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਐਪ ਸਿਰਫ਼ ਆਫਲਾਈਨ ਵਿੱਚ "ਚੱਲਦੀ" ਹੈ (ਅਕਸਰ ਰੀਡ-ਓਨਲੀ ਜਾਂ ਸੀਮਿਤ ਸੰਪਾਦਨ)।
ਜੌਬ ਸਾਈਟਾਂ, ਗੋਦਾਮਾਂ, ਉਡਾਣਾਂ ਅਤੇ ਬੇਸਮੈਂਟਸ ਲਈ ਵਰਤੀਆਂ ਚੈਕਲਿਸਟ ਲਈ, ਆਮ ਤੌਰ 'ਤੇ offline-first ਬਿਹਤਰ ਹੁੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਉਹ ਮੋਮੈਂਟ ਟਾਲਦਾ ਹੈ ਜਿੱਥੇ ਵਰਕਰ ਨੂੰ ਤੁਰੰਤ ਇੱਕ ਬਾਕਸ ਟਿੱਕ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
ਪੜ੍ਹਨ/ਲਿਖਨ ਨਿਯਮਾਂ ਬਾਰੇ ਸਪੱਸ਼ਟ ਹੋਵੋ। ਇੱਕ ਕਾਰਗਰ offline-first ਬੇਸਲਾਈਨ:
ਜਦੋਂ ਤੁਸੀਂ ਕਿਛੇ ਆਫਲਾਈਨ ਨੂੰ ਰੋਕਦੇ ਹੋ (ਉਦਾਹਰਨ ਲਈ ਨਵੇਂ ਟੀਮ ਮੈਂਬਰ ਨੂੰ ਨਿਯੁਕਤ ਕਰਨਾ), UI ਵਿੱਚ ਇਹ ਦੱਸੋ ਅਤੇ ਕਾਰਨ ਸਮਝਾਓ।
offline-first ਵਿੱਚ ਵੀ ਇੱਕ ਵਾਅਦਾ ਲਾਜ਼ਮੀ ਹੈ: ਤੁਹਾਡਾ ਕੰਮ ਜਦੋਂ ਕੁਨੈਕਟਿਵਟੀ ਵਾਪਸ ਆਵੇਗੀ ਤਾਂ ਸਿੰਕ ਹੋ ਜਾਵੇਗਾ। ਨਿਰਧਾਰਿਤ ਅਤੇ ਸੰਚਾਰ ਕਰੋ:
ਸਿੰਗਲ-ਯੂਜ਼ਰ ਚੈਕਲਿਸਟ ਸਧਾਰਨ ਹੁੰਦੇ ਹਨ: ਟਕਰਾਅ ਘੱਟ ਹੁੰਦੇ ਹਨ ਅਤੇ ਆਟੋਮੈਟਿਕ ਰੂਪ ਵਿੱਚ ਸਹੀ ਹੋ ਸਕਦੇ ਹਨ।
ਟੀਮਾਂ ਅਤੇ ਸ਼ੇਅਰ ਕੀਤੇ ਲਿਸਟਾਂ ਲਈ ਸਖ਼ਤ ਨਿਯਮਾਂ ਦੀ ਲੋੜ ਹੋਵੇਗੀ: ਦੋ ਲੋਕ ਇੱਕੋ ਆਈਟਮ ਨੂੰ ਆਫਲਾਈਨ ਸੋਧ ਸਕਦੇ ਹਨ। ਪਹਿਲਾਂ ਹੀ ਫੈਸਲਾ ਕਰੋ ਕਿ ਕੀ ਤੁਸੀਂ ਅਸਲ-ਟਾਈਮ ਕੋਲੈਬਰੇਸ਼ਨ ਨੂੰ ਭਵਿੱਖ ਵਿੱਚ ਸਮਰਥਨ ਦਿਓਗੇ, ਅਤੇ ਹੁਣ ਤੋਂ multi-device sync, ਆਡਿਟ ਇਤਿਹਾਸ ਅਤੇ "last updated by" ਦਿਖਾਓ ਤਾਂ ਕਿ ਹੈਰਾਨੀ ਘੱਟ ਹੋਵੇ।
ਇੱਕ ਚੰਗੀ ਆਫਲਾਈਨ ਚੈਕਲਿਸਟ ਐਪ ਜਿਆਦਾਤਰ ਡੇਟਾ ਦਾ ਮਸਲਾ ਹੈ। ਜੇ ਤੁਹਾਡਾ ਮਾਡਲ ਸਾਫ਼ ਅਤੇ ਅਨੁਮਾਨਯੋਗ ਹੋਵੇ ਤਾਂ ਆਫਲਾਈਨ ਸੋਧ, ਰੀਟ੍ਰਾਈ ਅਤੇ ਸਿੰਕ ਅਸਾਨ ਹੋ ਜਾਂਦੇ ਹਨ।
ਚੈੱਕਲਿਸਟ ਜਿਹੜੀ ਕੋਈ ਭਰਦਾ ਹੈ (runs) ਨੂੰ ਉਸ ਚੈੱਕਲਿਸਟ ਤੋਂ ਵੱਖ ਕਰੋ ਜੋ ਕਿਸੇ ਨੇ ਲਿਖੀ ਹੈ (templates)।
ਇਸ ਨਾਲ ਤੁਸੀਂ ਟੈਮਪਲੇਟ ਅਪਡੇਟ ਕਰ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਇਤਿਹਾਸਕ ਜਮ੍ਹਾਂ-ਕਿਰ્યਾਵਾਂ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਣ ਦੇ।
ਹਰ ਪ੍ਰਸ਼ਨ/ਟਾਸਕ ਨੂੰ ਇੱਕ ਆਈਟਮ ਵਜੋਂ ਸਥਿਰ ID ਨਾਲ ਰੱਖੋ। ਵਰਤੋਂਕਾਰ ਫੀਡਬੈਕ ਨੂੰ answers ਵਿੱਚ ਸੰਭਾਲੋ ਜੋ ਇੱਕ run + item ਨਾਲ ਲਿੰਕ ਹੋਵੇ।
ਵਿਆਵਹਾਰਿਕ ਫੀਲਡ ਜੋ ਸ਼ਾਮਲ ਕਰਨੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ:
id: ਸਥਿਰ UUID (ਕਲਾਇੰਟ-ਸਾਈਡ ਜਨਰੇਟ ਕੀਤਾ ਤਾਂ ਜੋ ਆਫਲਾਈਨ ਵੀ ਮੌਜੂਦ ਹੋਵੇ)template_version: ਇਹ ਪਤਾ ਕਰਨ ਲਈ ਕਿ ਰਨ ਕਿਹੜੇ ਟੈਮਪਲੇਟ ਵਰਜ਼ਨ ਤੋਂ ਸ਼ੁਰੂ ਹੋਇਆ ਸੀupdated_at: ਹਰ ਰਿਕਾਰਡ ਦਾ ਆਖਰੀ ਸੋਧਣ ਵਾਲਾ ਟਾਈਮਸਟੈਂਪversion (ਜਾਂ revision): ਪ੍ਰਤੀ ਲੋਕਲ ਬਦਲਾਅ ਤੁਸੀਂ ਇੱਕ ਇੰਟੀਜਰ ਵਧਾਉਂਦੇ ਹੋਇਹ "ਕਿਸਨੇ ਕੀ ਬਦਲਿਆ, ਕਦੋਂ" ਦਾ ਸੂਤਰ ਤੁਹਾਡੇ ਸਿੰਕ ਲਾਜਿਕ ਲਈ ਬੁਨਿਆਦ ਹੈ।
ਆਫਲਾਈਨ ਕੰਮ ਅਕਸਰ ਰੁਕਦਾ-ਫਿਰਦਾ ਹੈ। status (draft, in_progress, submitted), started_at, ਅਤੇ last_opened_at ਵਰਗੀਆਂ ਫੀਲਡ ਜੋੜੋ। Answers ਲਈ nullable ਕਦਰਾਂ ਅਤੇ ਹਲਕਾ "validation state" ਰੱਖੋ ਤਾਂ ਕਿ ਯੂਜ਼ਰ ਡਰਾਫਟ ਸੇਵ ਕਰ ਸਕਣ ਭਾਵੇਂ required ਆਈਟਮ ਪੂਰੇ ਨਾ ਹੋਣ।
ਫੋਟੋਜ਼ ਅਤੇ ਫਾਈਲਾਂ ਨੂੰ ਆਪਣੇ ਮੁੱਖ ਚੈਕਲਿਸਟ ਟੇਬਲਾਂ ਵਿੱਚ ਬਲਾਬ ਬਣਾਕੇ ਨਾ ਰੱਖੋ—ਉਪਲੋਡ ਰਿਟ੍ਰਾਈਜ਼ ਅਤੇ ਰੀਡ ਨੂੰ ਤੇਜ਼ ਰੱਖਣ ਲਈ ਉਨ੍ਹਾਂ ਨੂੰ ਰੈਫਰੈਂਸ ਕਰੋ।
ਇੱਕ attachments ਟੇਬਲ ਬਣਾਓ ਜਿਸ ਵਿੱਚ:
answer_id (ਜਾਂ run_id) ਲਿੰਕpending, uploading, uploaded, failed)ਇਸ ਨਾਲ ਚੈਕਲਿਸਟ ਰੀਡ ਤੇਜ਼ ਰਹਿੰਦੀ ਹੈ ਅਤੇ ਅਪਲੋਡ ਰੀਟ੍ਰਾਈਜ਼ ਸਪਸ਼ਟ ਹੁੰਦੇ ਹਨ।
ਆਫਲਾਈਨ ਚੈਕਲਿਸਟ ਲੋਕਲ ਸਟੋਰ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ। ਤੁਹਾਨੂੰ ਕੁਝ ਤੇਜ਼, ਖੋਜਯੋਗ ਅਤੇ ਅਪਗਰੇਡਹੋਣਯੋਗ ਚਾਹੀਦਾ ਹੈ—ਕਿਉਂਕਿ ਜਿਵੇਂ-ਜਿਵੇਂ ਅਸਲ ਯੂਜ਼ਰ ਨਕਲ-ਫਿਰਾ ਕੇ ਪੁੱਛਦੇ ਹਨ, ਤੁਹਾਡੀ ਸਕੀਮਾ ਤੁਰੰਤ ਬਦਲੇਗੀ।
ਆਮ "ਲਿਸਟ ਸਕ੍ਰੀਨ" ਲਈ ਡਿਜ਼ਾਈਨ ਕਰੋ। ਉਹ ਫੀਲਡ ਇੰਡੈਕਸ ਕਰੋ ਜਿਨ੍ਹਾਂ 'ਤੇ ਤੁਸੀਂ ਅਕਸਰ ਫਿਲਟਰ ਕਰਦੇ ਹੋ:
ਚੁਣਿੰਦੀਆਂ ਇੰਡੈਕਸਾਂ ਆਮ ਤੌਰ 'ਤੇ ਸਭ ਕੁਝ ਇੰਡੈਕਸ ਕਰਨ ਨਾਲ ਵਧੀਆ ਹਨ (ਕਿਉਂਕਿ ਉਹ ਲਿਖਤੀਆਂ ਨੂੰ ਸੁਸਤ ਕਰਦੇ ਹਨ ਅਤੇ ਸਟੋਰੇਜ ਵਧਾਉਂਦੇ ਹਨ)।
ਪਹਿਲੇ ਰਿਲੀਜ਼ ਤੋਂ ਹੀ ਆਪਣੀ ਸਕੀਮਾ ਵਰਜਨ ਕਰੋ। ਹਰ ਬਦਲਾਅ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਵੇ:
priority ਫੀਲਡ ਟੈਮਪਲੇਟ defaults ਦੇ ਆਧਾਰ ਤੇ ਭਰਨਾ)ਮਾਈਗ੍ਰੇਸ਼ਨਾਂ ਨੂੰ ਅਸਲ-ਜਿਹਾ ਡੇਟਾ ਨਾਲ ਟੈਸਟ ਕਰੋ, ਖਾਲੀ ਡੇਟਾਬੇਸ ਨਾਲ ਨਹੀਂ।
ਆਫਲਾਈਨ ਡੀਬੀ ਚੁਪਚਾਪ ਵਧਦੀ ਹੈ। ਅਗਾਂਹ ਤੋਂ ਯੋਜਨਾ ਬਣਾਓ:
ਇਸ ਨਾਲ ਐਪ ਮਹੀਨਿਆਂ ਤੱਕ ਫੀਲਡ ਵਿੱਚ ਰਹਿਣ 'ਤੇ ਵੀ ਤੇਜ਼ ਰਹੇਗੀ।
ਅਚਛਾ ਆਫਲਾਈਨ ਚੈਕਲਿਸਟ ਐਪ "ਸਿੰਕ ਸਕਰੀਨਾਂ" ਨਹੀਂ ਕਰਦਾ—ਇਹ ਉਪਭੋਗਤਾ ਦੀਆਂ ਕਿਰਿਆਵਾਂ ਸਿੰਕ ਕਰਦਾ ਹੈ। ਸਭ ਤੋਂ ਸਧਾਰਨ ਤਰੀਕਾ ਹੈ outbox (sync) queue: ਹਰ ਯੂਜ਼ਰ ਦਾ ਬਦਲਾਅ ਪਹਿਲਾਂ ਲੋਕਲ ਰਿਕਾਰਡ ਕੀਤਾ ਜਾਵੇ, ਫਿਰ ਬਾਅਦ ਵਿੱਚ ਸਰਵਰ ਨੂੰ ਭੇਜੋ।
ਜਦੋਂ ਯੂਜ਼ਰ ਕਿਸੇ ਆਈਟਮ ਨੂੰ ਚੈੱਕ ਕਰਦਾ, ਨੋਟ ਜੋੜਦਾ ਜਾਂ ਚੈਕਲਿਸਟ ਪੂਰਾ ਕਰਦਾ, ਉਹ ਕਾਰਵਾਈ ਲੋਕਲ ਟੇਬਲ outbox_events ਵਿੱਚ ਲਿਖੋ ਜਿਸ ਵਿੱਚ:
event_id (UUID)type (ਉਦਾਹਰਨ: CHECK_ITEM, ADD_NOTE)payload (ਵੇਰਵੇ)created_atstatus (pending, sending, sent, failed)ਇਸ ਨਾਲ ਆਫਲਾਈਨ ਕੰਮ ਤੁਰੰਤ ਅਤੇ ਭਵਿੱਖਬਾਣੀਯੋਗ ਹੁੰਦਾ ਹੈ: UI ਲੋਕਲ ਡੇਟਾਬੇਸ ਤੋਂ ਅਪਡੇਟ ਹੁੰਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਸਿੰਕ ਸਿਸਟਮ ਪਿੱਛੇ ਕੰਮ ਕਰਦਾ ਹੈ।
ਸਿੰਕ ਹਮੇਸ਼ਾ ਚੱਲਣਾ ਨਹੀਂ ਚਾਹੀਦਾ। ਸਪੱਸ਼ਟ ਟ੍ਰਿੱਗਰ ਚੁਣੋ ਤਾਂ ਜੋ ਯੂਜ਼ਰਾਂ ਨੂੰ ਸਮੇਂ ਤੇ ਅਪਡੇਟ ਮਿਲੇ ਬਿਨਾਂ ਬੈਟਰੀ ਖਤਮ ਕੀਤੇ:
ਨਿਯਮ ਸਧਾਰਨ ਅਤੇ ਦਿੱਖਣਯੋਗ ਰੱਖੋ। ਜੇ ਐਪ ਸਿੰਕ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਇੱਕ ਨਿੱਕਾ ਸਥਿਤੀ ਸੂਚਕ ਦਿਖਾਓ ਅਤੇ ਕੰਮ ਵਰਤਣ ਯੋਗ ਰੱਖੋ।
ਹਰ ਚੈੱਕਬਾਕਸ ਲਈ ਇੱਕ HTTP ਕਾਲ ਭੇਜਣ ਦੀ ਥਾਂ, ਕਈ outbox events ਨੂੰ ਇੱਕ ਬੈਚ ਵਿੱਚ ਭੇਜੋ (ਉਦਾਹਰਨ: 20–100 events)। ਬੈਚਿੰਗ ਰੇਡੀਓ wakeups ਘਟਾਉਂਦਾ, ਢਿੱਲੇ ਨੈੱਟਵਰਕ 'ਤੇ throughput ਸੁਧਾਰਦਾ ਅਤੇ ਸਿੰਕ ਸਮਾਂ ਛੋਟਾ ਰੱਖਦਾ ਹੈ।
ਅਸਲ ਨੈੱਟਵਰਕ ਵਿੰਙੀਂ ਬੇਲੋੜੀ।। ਤੁਹਾਡਾ ਸਿੰਕ ਮੰਨਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਹਰ request ਦੁਹਰਾਇਆ ਜਾ ਸਕਦਾ ਹੈ।
ਹਰ ਇਵੈਂਟ ਨੂੰ idempotent ਬਣਾਉਣ ਲਈ event_id ਸ਼ਾਮਲ ਕਰੋ ਅਤੇ ਸਰਵਰ ਪ੍ਰੋਸੈਸ ਕੀਤੇ IDs ਨੂੰ ਸਟੋਰ ਕਰੇ (ਜਾਂ idempotency key ਵਰਤੇ)। ਜੇ ਉਹੀ ਇਵੈਂਟ ਫਿਰ ਆਏ, ਸਰਵਰ ਸਫਲਤਾ ਵਾਪਿਸ ਕਰੇ ਬਿਨਾਂ ਦੁਹਰਾਉਣ ਦੇ। ਇਸ ਨਾਲ ਤੁਸੀਂ aggressive ਰੀਟ੍ਰਾਈਆਂ ਬੈਕਆਫ ਦੇ ਨਾਲ ਕਰ ਸਕਦੇ ਹੋ ਬਿਨਾਂ duplicate ਆਈਟਮ ਬਣਾਏ।
ਆਫਲਾਈਨ ਚੈਕਲਿਸਟ ਸਧਾਰਨ ਲੱਗਦੇ ਹਨ ਪਰ ਜਦੋਂ ਇੱਕੋ ਚੈਕਲਿਸਟ ਦੋ ਡਿਵਾਈਸਾਂ 'ਤੇ ਸੋਧੀ ਜਾਂਦੀ ਹੈ (ਜਾਂ ਇੱਕ ਆਫਲਾਈਨ ਤੇ ਦੂਜਾ ਆਨਲਾਈਨ), ਤਦ ਇਹ ਔਖਾ ਹੋ ਜਾਂਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਟਕਰਾਅ ਲਈ ਅਗੇ ਤੋਂ ਯੋਜਨਾ ਨਹੀਂ ਬਣਾਉਂਦੇ, ਤਾਂ ਗੁੰਮ ਹੋਏ ਆਈਟਮ, ਨਕਲਾਂ ਜਾਂ ਓਵਰਰਾਈਟ ਨੋਟਸ ਵਰਗੇ ਸਮੱਸਿਆਵਾਂ ਆ ਸਕਦੀਆਂ ਹਨ—ਇਹ ਉਹ ਹੀ ਭਰੋਸੇਯੋਗਤਾ ਦੀ ਰੁਕਾਵਟਾਂ ਹਨ ਜੋ ਚੈਕਲਿਸਟ ਐਪਾਂ ਲਈ ਨੁਕਸਾਨਦੇਹ ਹੋ ਸਕਦੀਆਂ ਹਨ।
ਆਮ ਪੈਟਰਨ:
ਇੱਕ ਰਣਨੀਤੀ ਚੁਣੋ ਅਤੇ ਇਹ ਸਪੱਸ਼ਟ ਕਰੋ ਕਿ ਕਿੱਥੇ ਲਾਗੂ ਹੋਵੇਗੀ:
ਜ਼ਿਆਦातर ਐਪ ਇਨ੍ਹਾਂ ਨੂੰ ਮਿਲਾ ਕੇ ਵਰਤਦੇ ਹਨ: ਡਿਫੌਲਟ ਤੇ per-field merge, ਕੁਝ ਫੀਲਡਾਂ ਲਈ LWW, ਅਤੇ ਜਦ ਲੋੜ ਹੋਵੇ ਤਾਂ ਯੂਜ਼ਰ-ਮਦਦ।
ਟਕਰਾਅ ਦੇ ਸਿਗਨਲ ਤੁਹਾਡੇ ਡੇਟਾ ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ:
ਸਿੰਕ ਦੌਰਾਨ, ਜੇ ਸਰਵਰ ਰਿਵੀਜ਼ਨ ਬਦਲ ਗਿਆ ਹੋਵੇ ਜਦੋਂ ਤੁਸੀਂ ਸੋਧ ਸ਼ੁਰੂ ਕੀਤੀ ਸੀ, ਤਾਂ ਟਕਰਾਅ ਮੌਜੂਦ ਹੈ ਅਤੇ ਹੱਲ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।
ਜਦੋਂ ਯੂਜ਼ਰ ਦੀ ਦਖਲ ਦੀ ਲੋੜ ਹੋਵੇ, ਇਹ ਤੇਜ਼ ਰੱਖੋ:
ਇਹ ਪਹਿਲਾਂ ਤੋਂ ਯੋਜਨਾ ਬਣਾਉਣ ਨਾਲ ਤੁਹਾਡਾ ਸਿੰਕ ਲਾਜਿਕ, ਸਟੋਰੇਜ ਸਕੀਮਾ ਅਤੇ UX ਇਕੱਠੇ ਕੰਮ ਕਰਨਗੇ ਅਤੇ ਲਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਨੁਕਸਾਨੀ ਨਤੀਜਿਆਂ ਤੋਂ ਬਚਾਓ ਹੋਵੇਗਾ।
ਆਫਲਾਈਨ ਸਹਾਇਤਾ ਤਦ ਹੀ "ਅਸਲੀ" ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਇੰਟਰਫੇਸ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਕੀ ਹੋ ਰਿਹਾ ਹੈ। ਗੋਦਾਮਾਂ, ਹਸਪਤਾਲਾਂ ਜਾਂ ਜੌਬ ਸਾਈਟਾਂ 'ਤੇ ਚੈਕਲਿਸਟ ਵਰਤਣ ਵਾਲੇ ਲੋਕ ਇਹ ਨਹੀਂ ਚਾਹੁੰਦੇ ਕਿ ਉਹ ਸੋਚਣ ਕਿ ਉਨ੍ਹਾਂ ਦਾ ਕੰਮ ਸੁਰੱਖਿਅਤ ਹੈ ਜਾਂ ਨਹੀਂ।
ਮੁੱਖ ਸਕ੍ਰੀਨਾਂ ਦੇ ਨੇੜੇ ਇੱਕ ਨਿੱਕਾ, ਲਗਾਤਾਰ ਸਥਿਤੀ ਸੰਕੇਤ ਦਿਖਾਓ:
ਜਦੋਂ ਐਪ ਆਫਲਾਈਨ ਹੋ ਜਾਵੇ, ਉਪਯੋਗਕਾਰ ਦੇ ਕੰਮ ਨੂੰ ਰੋਕਣ ਵਾਲੀਆਂ ਪੋਪ-ਅੱਪਸ ਤੋਂ ਬਚੋ। ਇੱਕ ਹਲਕੀ ਬੈਨਰ ਜੋ dismiss ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਆਮ ਤੌਰ ਰਾਹ ਫੁਟਕਾਰ ਹੁੰਦੀ ਹੈ। ਜਦੋਂ ਨੈੱਟਵਰਕ ਵਾਪਸ ਆਉਂਦਾ ਹੈ, ਥੋੜ੍ਹਾ “Syncing…” ਦਿਖਾਓ, ਫਿਰ ਚੁੱਪਚਾਪ ਹਟਾਓ।
ਹਰ ਸੋਧ ਤੁਰੰਤ ਸੇਵ ਹੋਈ ਮਹਿਸੂਸ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਭਾਵੇਂ ਡਿਸਕਨੈਕਟ ਹੋਵੇ। ਇੱਕ ਚੰਗਾ ਪੈਟਰਨ ਤਿੰਨ-ਸਟੇਜ ਸੇਵ ਸਥਿਤੀ ਹੈ:
ਇਹ ਫੀਡਬੈਕ ਕਾਰਵਾਈ ਦੇ ਨੇੜੇ ਰੱਖੋ: ਚੈਕਲਿਸਟ ਸਿਰਲੇਖ ਦੇ ਕੋਲ, ਆਈਟਮ ਕਤਾਰ ਪੱਧਰ ਤੇ (ਜ਼ਰੂਰੀ ਖੇਤਰਾਂ ਲਈ), ਜਾਂ ਇੱਕ ਛੋਟੀ ਫੁੱਟਰ ਸੰਖੇਪ ਵਿੱਚ (“3 changes pending sync”)। ਜੇ ਕੁਝ ਸਿੰਕ ਕਰਨ ਵਿੱਚ ਫੇਲ੍ਹ ਹੋਵੇ, ਸਪਸ਼ਟ retry ਕਾਰਵਾਈ ਦਿਖਾਓ—ਯੂਜ਼ਰ ਨੂੰ ਉਸਨੂੰ ਖੋਜਣਾ ਨਾ ਪਏ।
ਆਫਲਾਈਨ ਕੰਮ ਗਲਤੀਆਂ ਦਾ ਖ਼ਰਚ ਵਧਾਉਂਦਾ ਹੈ। ਸੁਰੱਖਿਅਤਗਿਰਾਂ ਸ਼ਾਮਲ ਕਰੋ:
ਇਸ ਤੋਂ ਇਲਾਵਾ ਕੁਝ ਸਮੇਂ ਲਈ “Restore recently deleted” ਵੀਚਾਰ ਕਰੋ।
ਚੈਕਲਿਸਟ ਅਕਸਰ ਇੱਕ ਹੱਥ ਨਾਲ ਭਰੇ ਹੋਏ ਹਥਿਆਰ ਜਾਂ ਦਸਤਾਣੇ ਨਾਲ ਪੂਰੇ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਤੇਜ਼ੀ ਨੂੰ ਪ੍ਰਾਥਮਿਕਤਾ ਦਿਓ:
ആਪ ਦੇ ਸੁਖਮਿਜ਼ਾਜ ਰਸਤੇ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰੋ: ਯੂਜ਼ਰ ਨੂੰ ਇੱਕ ਚੈਕਲਿਸਟ ਤੁਰੰਤ ਪੂਰਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਐਪ ਆਫਲਾਈਨ ਵੇਰਵੇ ਪਿੱਛੇ ਸ਼ਾਂਤ ਢੰਗ ਨਾਲ ਹੱਲ ਕਰੇ।
ਆਫਲਾਈਨ ਚੈਕਲਿਸਟ ਟੁੱਟ-ਫੱਟ ਹੋ ਜਾਂਦੇ ਹਨ ਜੇ ਯੂਜ਼ਰ ਨੂੰ ਉਹ ਸੰਦਰਭ (ਟੈਮਪਲੇਟ, ਉਪਕਰਣ ਸੂਚੀਆਂ, ਸਾਈਟ ਜਾਣਕਾਰੀ, ਲੋੜੀਂਦੇ ਫੋਟੋਜ਼, ਸੁਰੱਖਿਆ ਨਿਯਮ) ਨਾਂ ਮਿਲੇ। ਇਨ੍ਹਾਂ ਨੂੰ “reference data” ਮੰਨੋ ਅਤੇ ਚੈਕਲਿਸਟ ਨਾਲ ਲੋਕਲੀ ਸੰਭਾਲੋ।
ਉਹ ਘੱਟੋ-ਘੱਟ ਸੈੱਟ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਬਿਨਾਂ ਅਨੁਮਾਨ ਦੇ ਕੰਮ ਮੁਕੰਮਲ ਕਰਨ ਲਈ ਜ਼ਰੂਰੀ ਹੋ:
ਅੱਛਾ ਨਿਯਮ: ਜੇ UI ਟੈਮਪਲੇਟ ਖੋਲ੍ਹਣ 'ਤੇ ਇੱਕ spinner ਦਿਖਾਉਂਦਾ ਹੈ ਜਦੋਂ ਆਨਲਾਈਨ ਹੋਵੇ, ਉਸ dependency ਨੂੰ cache ਕਰੋ।
ਹਰ ਡੇਟਾ ਕਿਸਮ ਨੂੰ ਇੱਕ TTL ਦਿੱਤਾ ਜਾਵੇ:
ਇਵੈਂਟ-ਆਧਾਰਿਤ ਰਿਫ੍ਰੈਸ਼ ਟ੍ਰਿੱਗਰ ਵੀ ਜੋੜੋ: ਯੂਜ਼ਰ ਸਾਈਟ/ਪ੍ਰੋਜੈਕਟ ਬਦਲਦਾ ਹੈ, ਨਵੀਂ ਨਿਯੁਕਤੀ ਆਉਂਦੀ ਹੈ, ਜਾਂ ਟੈਮਪਲੇਟ ਨੂੰ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਨਹੀਂਖੋਲਿਆ ਗਿਆ।
ਜੇਕਰ ਟੈਮਪਲੇਟ ਅਪਡੇਟ ਹੋ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਕੋਈ ਯੂਜ਼ਰ ਮੱਧ-ਭਰਾਈ ਵਿੱਚ ਹੋਵੇ, ਫਾਰਮ ਨੂੰ ਚੁਪਚਾਪ ਬਦਲਣਾ ਟਾਲੋ। ਇੱਕ ਸਪਸ਼ਟ "template updated" ਬੈਨਰ ਦਿਖਾਓ ਅਤੇ ਵਿਕਲਪ ਦਿਓ:
ਜੇ ਨਵੇਂ required fields ਆ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਚੈਕਲਿਸਟ ਨੂੰ "submit ਤੋਂ ਪਹਿਲਾਂ update ਦੀ ਲੋੜ" ਦੇ ਰੂਪ ਵਿੱਚ ਦਰਜ ਕਰੋ, ਨਾ ਕਿ ਆਫਲਾਈਨ ਪੂਰਨਤਾ ਨੂੰ ਰੋਕੋ।
ਵਰਜ਼ਨਿੰਗ ਅਤੇ ਡੈਲਟਾ ਵਰਤੋ: ਸਿਰਫ਼ ਬਦਲੀਆਂ ਟੈਮਪਲੇਟ/ਲੁਕਅੱਪ ਰੋਜ਼ sync ਕਰੋ ( updatedAt ਜਾਂ ਸਰਵਰ ਚੇਨਜ ਟੋਕਨ ਨਾਲ)। ਪਰ-ਡਾਟਾ ਸਿੰਕ cursors ਰੱਖੋ ਤਾਂ ਐਪ ਤੇਜ਼ੀ ਨਾਲ resume ਕਰ ਸਕੇ ਅਤੇ ਬੈਂਡਵਿਡਥ ਘਟੇ—ਜੋ ਕਿ ਸੈੱਲੂਲਰ ਕਨੈਕਸ਼ਨਾਂ ਲਈ ਜ਼ਰੂਰੀ ਹੈ।
ਆਫਲਾਈਨ ਚੈਕਲਿਸਟ ਇਸ ਲਈ ਲਾਭਦਾਇਕ ਹਨ ਕਿਉਂਕਿ ਡੇਟਾ ਡਿਵਾਈਸ 'ਤੇ ਰਿਹਾ ਹੁੰਦਾ ਹੈ—ਭਾਵੇਂ ਨੈਟਵਰਕ ਨਾ ਹੋਵੇ। ਇਸਦਾ ਅਰਥ ਇਹ ਵੀ ਹੈ ਕਿ ਜੇ ਫੋਨ ਖੋ ਜਾਵੇ, ਸਾਂਝਾ ਕੀਤਾ ਜਾਵੇ ਜਾਂ ਸਮਰਥਨ ਤੋੜ-ਫੋੜ ਹੋਵੇ ਤਾਂ ਤੁਸੀਂ ਉਸ ਦੀ ਸੁਰੱਖਿਆ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੋ।
ਤੈਅ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕਿਸ ਤੋਂ ਬਚਾਅ ਕਰ ਰਹੇ ਹੋ:
ਇਸ ਨਾਲ ਤੁਸੀਂ ਢੁਕਵਾਂ ਸੁਰੱਖਿਆ ਪੱਧਰ ਚੁਣ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਐਪ ਨੂੰ ਬੇਕਾਰ ਰੂਪ ਨਾਲ ਸਲੋ ਕੀਤੇ।
ਐਕਸੈਸ ਟੋਕਨ ਸਧਾਰਾ ਲੋਕਲ ਸਟੋਰੇਜ ਵਿੱਚ ਕਦੇ ਵੀ ਰੱਖੋ ਨਾ। OS-ਪ੍ਰਦਤ ਸੇਕਿਊਰ ਸਟੋਰੇਜ ਵਰਤੋ:
ਲੋਕਲ ਡੇਟਾਬੇਸ ਨੂੰ ਲੰਬੇ ਸਮੇਂ ਵਾਲੇ ਸਿੱਕਰੇਟਾਂ ਤੋਂ ਮੁਕਤ ਰੱਖੋ। ਜੇ ਤੁਹਾਨੂੰ ਡੇਟਾਬੇਸ ਲਈ ਇੰਕ੍ਰਿਪਸ਼ਨ ਦੀ ਕੁੰਜੀ ਚਾਹੀਦੀ ਹੈ, ਉਸ ਕੁੰਜੀ ਨੂੰ Keychain/Keystore ਵਿੱਚ ਰੱਖੋ।
ਡੇਟਾਬੇਸ ਇੰਕ੍ਰਿਪਸ਼ਨ ਡਰਸ਼ਕ-ਡੇਟਾ, ਪਤੇ, ਫੋਟੋਜ਼ ਜਾਂ compliance ਨੋਟਸ ਵਰਗੇ ਨਿੱਜੀ ਡੇਟਾ ਲਈ ਚੰਗੀ ਸੋਚ ਹੋ ਸਕਦੀ ਹੈ। ਟਰੇਡ-ਆਫ ਕ੍ਰਮਵਾਰ ਹਨ:
ਜੇ ਮੁੱਖ ਖਤਰਾ "ਕੋਈ ਐਪ ਫਾਇਲ ਬਰਾਊਜ਼ ਕਰਦਾ ਹੈ" ਹੈ, ਤਾਂ ਇੰਕ੍ਰਿਪਸ਼ਨ ਕੀਮਤੀ ਹੈ। ਜੇ ਡੇਟਾ ਘੱਟ-ਸੰਵੇਦਨਸ਼ੀਲ ਹੈ ਅਤੇ ਡਿਵਾਈਸਾਂ OS-ਪੱਧਰੀ ਫੁੱਲ-ਡਿਸਕ ਇੰਕ੍ਰਿਪਸ਼ਨ ਵਰਤ ਰਹੇ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਇਸਨੂੰ ਛੱਡ ਵੀ ਸਕਦੇ ਹੋ।
ਯੋਜਨਾ ਬਣਾਓ ਕਿ ਜੇ ਸੈਸ਼ਨ ਆਫ਼ਲਾਈਨ ਦੌਰਾਨ ਸਮਾਪਤ ਹੋ ਜਾਵੇ ਤਾਂ ਕੀ ਹੋਵੇ:
ਫੋਟੋਜ਼/ਫਾਈਲਾਂ ਨੂੰ app-private ਸਟੋਰੇਜ ਪਾਥ 'ਚ ਰੱਖੋ, ਸਾਂਝੇ ਗੈਲਰੀਆਂ ਵਿੱਚ ਨਹੀਂ। ਹਰ ਅਟੈਚਮੈਂਟ ਨੂੰ ਸਾਈਨ-ਇਨ ਯੂਜ਼ਰ ਨਾਲ ਜੋੜੋ, ਐਕਸੇਸ ਚੈੱਕ ਇੰ-ਐਪ ਲਾਗੂ ਕਰੋ, ਅਤੇ ਲੌਗਆਊਟ 'ਤੇ cached files wiped ਕਰੋ (ਅਤੇ ਵਿਕਲਪਿਕ ਤੌਰ 'ਤੇ settings ਵਿੱਚ “Remove offline data” ਕਾਰਵਾਈ ਦਿਓ)।
ਸਿੰਕ ਜੋ ਤੁਹਾਡੇ ਦਫਤਰ ਦੇ Wi‑Fi 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ ਓਹ elevators, ਪੇਂਡੂ ਖੇਤਰ ਜਾਂ OS ਦੇ background throttling 'ਚ ਫੇਲ ਹੋ ਸਕਦਾ ਹੈ। "ਨੈੱਟਵਰਕ" ਨੂੰ ਮੂਲਰੂਪ ਵਿੱਚ ਅਣਵਿਸ਼ਵਾਸਯੋਗ ਸਮਝੋ ਅਤੇ ਸਿੰਕ ਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਫੇਲ ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ recover ਕਰਨ ਲਾਇਕ ਡਿਜ਼ਾਈਨ ਕਰੋ।
ਹਰ ਨੈੱਟਵਰਕ ਕਾਲ ਲਈ ਸਮਾਂ ਸੀਮਾ ਰੱਖੋ। ਇੱਕ ਬੇਅੰਤ ਹੰਗ ਰਿਹਾ request 2 ਮਿੰਟ ਲਈ ਐਪ ਨੂੰ ਫ੍ਰੀਜ਼ਡ ਮਹਿਸੂਸ ਕਰਾਵੇਗਾ ਅਤੇ ਹੋਰ ਕਾਰਵਾਈਆਂ ਬਲੌਕ ਹੋ ਸਕਦੀਆਂ ਹਨ।
ਟ੍ਰਾਂਜ਼ੀਐਂਟ ਫੇਲ੍ਹ (timeouts, 502/503, DNS ਮਸਲੇ) ਲਈ retries ਵਰਤੋ, ਪਰ ਸਰਵਰ 'ਤੇ ਹਮਲਾ ਨਾ ਕਰੋ। exponential backoff (ਜਿਵੇਂ 1s, 2s, 4s, 8s…) ਅਤੇ ਛੋਟਾ ਸ random jitter ਲਗਾਓ ਤਾਂ ਜੋ ਹਜ਼ਾਰਾਂ ਡਿਵਾਈਸ ਇਕੱਠੇ retries ਨਾ ਕਰਨ।
ਜਦੋਂ ਪਲੇਟਫਾਰਮ ਆਗਿਆ ਦਿੰਦਾ ਹੈ, ਬੈਕਗ੍ਰਾਊਂਡ ਵਿੱਚ ਸਿੰਕ ਚਲਾਓ ਤਾਂ ਕਿ ਚੈਕਲਿਸਟ ਜਦੋਂ ਕੁਨੈਕਟਿਵਟੀ ਵਾਪਸ ਆਵੇ ਤੁਰੰਤ ਅਪਲੋਡ ਹੋ ਜਾਣ। ਫਿਰ ਵੀ ਇੱਕ ਵਿਜ਼ੀਬਲ ਮੈਨੂਅਲ ਕਾਰਵਾਈ "Sync now" ਦਿਓ ਯੂਜ਼ਰ ਭਰੋਸੇ ਲਈ ਅਤੇ ਜਦੋਂ ਬੈਕਗ੍ਰਾਊਂਡ ਸਿੰਕ ਦੇਰ ਕਰੇ।
ਇਸ ਨੂੰ ਸਪਸ਼ਟ ਸਥਿਤੀ ਨਾਲ ਜੋੜੋ: “Last synced 12 min ago”, “3 items pending”, ਅਤੇ ਇੱਕ ਗੈਰ-ਅਲਾਰਮਿੰਗ ਬੈਨਰ ਜਦੋਂ ਆਫਲਾਈਨ ਹੋਵੇ।
ਆਫਲਾਈਨ ਐਪ ਅਕਸਰ ਇੱਕੋ ਕਾਰਵਾਈ ਨੂੰ ਕਈ ਵਾਰੀ retry ਕਰਦੇ ਹਨ। ਹਰ queued change ਨੂੰ ਇੱਕ ਯੂਨੀਕ request ID (ਤੁਹਾਡਾ event_id) ਦਿਓ ਅਤੇ ਇਸਨੂੰ ਰਿਕਵੈਸਟ ਨਾਲ ਭੇਜੋ। ਸਰਵਰ ਪ੍ਰੋਸੈਸ ਕੀਤੇ IDs ਸਟੋਰ ਕਰਕੇ duplicates ਨੂੰ ignore ਕਰੇ। ਇਸ ਨਾਲ ਯੂਜ਼ਰ ਦੋਚੱਕੀ ਇੰਸਪੈਕਸ਼ਨ, ਦੋ ਸਿਗਨੇਚਰ ਜਾਂ ਡਬਲ-ਚੈੱਕ ਕਰਨ ਤੋਂ ਬਚ ਸਕਦੇ ਹਨ।
ਸਿੰਕ errors ਨੂੰ ਸੰਦਰਭ ਸਮੇਤ ਸਟੋਰ ਕਰੋ: ਕਿਹੜੀ ਚੈਕਲਿਸਟ, ਕਿਹੜਾ ਸਟੇਪ, ਅਤੇ ਯੂਜ਼ਰ ਅਗਲਾ ਕੀ ਕਰ ਸਕਦਾ ਹੈ। “Couldn’t upload 2 photos—connection too slow. Keep the app open and tap Sync now.” ਵਰਗੀ ਸੁਝਾਅ-ਭਰੀਆਂ ਸੁਨੇਹੇ ਪREFER ਕਰੋ ਨਾਂ ਕਿ "Sync failed." ਦੀ ਨਿਰਸ ਸੁਨੇਹਾ। support ਲਈ "Copy details" ਦਾ ਇੱਕ ਛੋਟਾ ਵਿਕਲਪ ਦਿਓ।
ਆਫਲਾਈਨ ਫੀਚਰ ਆਮ ਤੌਰ 'ਤੇ ਕਿਨਾਰੇ 'ਤੇ ਫੇਲ ਹੁੰਦੇ ਹਨ: ਇੱਕ ਟੰਨਲ, ਕਮਜ਼ੋਰ ਸਿਗਨਲ, ਅਧ-ਸੰਭਾਲੀ ਸੇਵ ਜਾਂ ਇੱਕ ਵੱਡਾ ਚੈਕਲਿਸਟ ਜੋ ਥੋੜ੍ਹਾ ਸਮਾਂ ਲੈਂਦਾ ਹੈ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਰੁਕ ਜਾਂਦਾ ਹੈ। ਇੱਕ ਫੋਕਸਡ ਟੈਸਟ ਪਲੈਨ ਇਨ੍ਹਾਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਰਿਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਪਕੜਦਾ ਹੈ।
ਫਿਜ਼ੀਕਲ ਡਿਵਾਈਸਾਂ 'ਤੇ airplane mode ਦੇ ਨਾਲ end-to-end ਟੈਸਟ ਕਰੋ, ਸਿਰਫ਼ ਸਿਮੂਲੇਟਰ ਨਹੀਂ। ਫਿਰ ਅੱਗੇ ਵੱਧੋ: ਕੁਨੈਕਟਿਵਟੀ ਨੂੰ ਕ੍ਰਿਆ ਦੌਰਾਨ ਬਦਲੋ।
ਸਨੇਰੀਓ ਆਜ਼ਮਾਓ:
ਤੁਸੀਂ ਜਾਂਚ ਕਰ ਰਹੇ ਹੋ ਕਿ ਲਿਖਤੀਆਂ ਲੋਕਲ ਤੌਰ ਤੇ ਟਿਕਾਉ ਹਨ, UI ਸਥਿਤੀਆਂ ਸੰਗਤ ਹਨ, ਅਤੇ ਐਪ pending changes ਨੂੰ "ਭੁੱਲ" ਨਹੀਂ ਜਾਂਦੀ।
ਤੁਹਾਡਾ sync queue ਇੱਕ ਕਾਰੋਬਾਰੀ ਲਾਜਿਕ ਹਿੱਸਾ ਹੈ, ਇਸ ਲਈ ਇਸਨੂੰ ਟੈਸਟ ਕਰਨ ਵਾਲੀ ਕੋਡ ਰੱਖੋ। ਆਟੋਮੇਟਿਕ ਟੈਸਟ ਸ਼ਾਮਲ ਕਰੋ ਜੋ ਕਵਰ ਕਰਨ:
ਇੱਥੇ ਦੀ ਇੱਕ ਛੋਟੀ deterministic ਟੈਸਟ ਸੈਟ ਸਭ ਤੋਂ ਮਹਿੰਗੀ ਕਿਸਮ ਦੀਆਂ ਬੱਗਾਂ (ਚੁਪਚਾਪ ਡੇਟਾ ਕਰਪਸ਼ਨ) ਨੂੰ ਰੋਕਦੀ ਹੈ।
ਵੱਡੇ, ਹਕੀਕਤ-ਨੁਮਾ ਡੇਟਾਸੈਟ ਬਣਾਓ: ਲੰਬੇ ਚੈਕਲਿਸਟ, ਬਹੁਤ ਸਾਰੇ ਪੂਰੇ ਕੀਤੇ ਆਈਟਮ, ਅਤੇ ਅਟੈਚਮੈਂਟ। ਮਾਪੋ:
ਹੋਰ-ਹੋਰ, ਨੀਵਾਂ-ਅੰਤ ਵਾਲੇ ਡਿਵਾਈਸਾਂ (ਲੋ-ਐਂਡ Android, ਪੁਰਾਣੇ iPhones) 'ਤੇ ਵੀ ਟੈਸਟ ਕਰੋ ਜਿੱਥੇ ਸਲੋ I/O ਬੋਤਲ-ਗਰਤੀਆਂ ਖੋਲ੍ਹ ਸਕਦੀ ਹੈ।
ਸਿੰਕ ਸਫਲਤਾ ਦਰ ਅਤੇ time-to-sync (ਲੋਕਲ ਬਦਲਾਅ ਤੋਂ ਸਰਵਰ ਪੁਸ਼ਟੀ ਤੱਕ) ਟਰੈਕ ਕਰਨ ਲਈ analytics ਜੋੜੋ। ਰਿਲੀਜ਼ਾਂ ਤੋਂ ਬਾਅਦ spike ਲਈ ਨਿਗਰਾਨੀ ਕਰੋ ਅਤੇ ਨੈੱਟਵਰਕ ਟਾਈਪ ਦੇ ਅਧਾਰ ਤੇ ਵੱਖ-ਵੱਖ ਹਿੱਸਿਆਂ ਨੂੰ ਵੇਖੋ। ਇਸ ਨਾਲ "sync flaky ਲੱਗਦਾ ਹੈ" ਨੂੰ ਸਪੱਸ਼ਟ, ਕਾਰਵਾਈਯੋਗ ਅੰਕੜਿਆਂ ਵਿੱਚ ਬਦਲਿਆ ਜਾ ਸਕਦਾ ਹੈ।
ਆਫਲਾਈਨ ਚੈਕਲਿਸਟ ਐਪ ਸ਼ਿਪ ਕਰਨਾ ਇੱਕ ਇਕ-ਵਾਰ ਕੰਮ ਨਹੀਂ—ਇਹ ਫੀਡਬੈਕ ਲੂਪ ਦੀ ਸ਼ੁਰੂਆਤ ਹੈ। ਲਕੜੀ ਦੇ ਰੂਪ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਰਿਲੀਜ਼ ਕਰੋ, ਅਸਲ ਵਰਤੋਂ ਦੇ ਆਧਾਰ 'ਤੇ ਸੁਧਾਰ ਕਰੋ ਅਤੇ ਯੂਜ਼ਰਾਂ ਨੂੰ ਹੈਰਾਨ ਨਾ ਕਰੋ।
ਰੋਲਆਉਟ ਤੋਂ ਪਹਿਲਾਂ, ਉਹ endpoints ਲਾਕ ਕਰੋ ਜਿਨ੍ਹਾਂ 'ਤੇ ਕਲਾਇੰਟ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ client ਅਤੇ server predictable ਤਰੀਕੇ ਨਾਲ ਵਿਕਸਤ ਹੋ ਸਕਣ:
ਜਵਾਬਾਂ consistent ਅਤੇ explicit ਰੱਖੋ (ਕੀ accepted ਹੋਇਆ, rejected, retried) ਤਾਂ ਜੋ ਐਪ gracefully recover ਕਰ ਸਕੇ।
ਆਫਲਾਈਨ ਮੁੱਦੇ ਅਕਸਰ ਅਦ੍ਰਿਸ਼ ਹਨ ਜੇ ਤਕ ਤੁਸੀਂ ਮਾਪਿਆ ਨਾ ਹੋਵੇ। ਟਰੈਕ ਕਰੋ:
ਸਪਾਇਕਾਂ 'ਤੇ alert ਰੱਖੋ, ਇੱਕੱਲੇ errors 'ਤੇ ਨਹੀਂ, ਅਤੇ correlation IDs ਲਓ ਤਾਂ support ਇੱਕ ਯੂਜ਼ਰ ਦੀ sync ਕਹਾਣੀ ਨੂੰ ਟਰੇਸ ਕਰ ਸਕੇ।
ਫੀਚਰ ਫਲੈਗਸ ਨਾਲ sync changes ਨੂੰ ਧੀਰੇ-ਧੀਰੇ ਰੋਲਆਉਟ ਕਰੋ ਅਤੇ ਖਰਾਬ ਰਾਹ ਨੂੰ ਜਲਦੀ ਬੰਦ ਕਰਨ ਲਈ ਸੇਫਗਾਰਡ ਰੱਖੋ। ਸਕੀਮਾ ਮਾਈਗ੍ਰੇਸ਼ਨ ਸਥਿਤੀ ਲਈ:
ਹਲਕੀ onboarding ਦਿਓ: offline ਸਥਿਤੀ ਨੂੰ ਕਿਵੇਂ ਪਛਾਣਣਾ, "Queued" ਦਾ ਅਰਥ, ਅਤੇ ਡੇਟਾ ਕਦੋਂ ਸਿੰਕ ਹੋਵੇਗਾ। ਇੱਕ ਹੈਲਪ ਆਰਟਿਕਲ ਜਾਰੀ ਕਰੋ ਅਤੇ ਐਪ ਤੋਂ ਇਸਨੂੰ ਲਿੰਕ ਕਰੋ (ਦੇਖੋ ਵਿਚਾਰ /blog/)।
ਜੇ ਤੁਸੀਂ ਇਨ੍ਹਾਂ offline ਪੈਟਰਨਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਸੱਚਮੁੱਚ ਵੈਰੀਫਾਈ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ (local store, outbox queue, ਅਤੇ ਬੇਸਿਕ Go/PostgreSQL ਬੈਕਐਂਡ), ਤਾਂ Koder.ai ਵਰਗਾ platform ਤੁਹਾਨੂੰ chat-driven spec ਤੋਂ ਇਕ ਵਰਕਿੰਗ ਪ੍ਰੋਟੋਟਾਈਪ ਖੜਾ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ। ਤੁਸੀਂ ਚੈਕਲਿਸਟ UX ਅਤੇ ਸਿੰਕ ਨਿਯਮਾਂ 'ਤੇ ਇਟਰੇਟ ਕਰ ਸਕਦੇ ਹੋ, ਜਦੋਂ ਤਿਆਰ ਹੋਵੋ ਤਾਂ ਸੋਰਸ ਕੋਡ Export ਕਰ ਲਓ, ਅਤੇ ਅਸਲ ਫੀਲਡ ਫੀਡਬੈਕ ਦੇ ਆਧਾਰ 'ਤੇ ਭਰੋਸੇਯੋਗਤਾ ਤਿੱਖੀ ਕਰੋ।
“ਆਫਲਾਈਨ” ਦਾ ਮਤਲਬ ਛੋਟੇ-ਛੋਟੇ ਨੈਟਵਰਕ ਡ੍ਰੌਪਆਉਟ ਤੋਂ ਲੈ ਕੇ ਦਿਨਾਂ ਤੱਕ ਕੰਨੈਕਟਿਵਟੀ ਨਾ ਹੋਣ ਤੱਕ ਹੋ ਸਕਦਾ ਹੈ। ਪਰਿਭਾਸ਼ਾ ਕਰੋ:
ਜੇ ਯੂਜ਼ਰਾਂ ਨੂੰ ਘੱਟ/ਕੋਈ ਰਿਸੈਪਸ਼ਨ ਹੋਣ 'ਤੇ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਚੈਕਲਿਸਟ ਪੂਰੇ ਕਰਨੇ ਲੋੜੀਂਦੇ ਹਨ ਤਾਂ offline-first ਚੁਣੋ: ਡਿਵਾਈਸ ਮੁੱਖ ਕੰਮ ਕਰਨ ਦੀ ਥਾਂ ਹੋਵੇ ਅਤੇ ਸਿੰਕ ਪਿੱਛੇ ਪਲੱਗ-ਇਨ ਵਰਗੀ ਹੋਵੇ।
Online-first with fallback صرف اوہدے لئے مناسب جے جتھے زیادہ کم آن لائن ہوندا اے تے آف لائن صرف محدود پڑھائی یا معمولی ترمیم لئی ہوندا اے۔
ਇਕ ਵਰਤੋਂਯੋਗ ਬੇਸਲਾਈਨ:
ਜੇ ਕੁਝ ਸੀਮਿਤ ਹੈ (ਜਿਵੇਂ ਟੀਮ ਮੈਂਬਰਾਂ ਨੂ invite ਕਰਨਾ), ਤਾਂ UI ਵਿੱਚ ਵਜਾ ਦੱਸੋ।
ਆਪਣੇ ਡੇਟਾ ਨੂੰ ਦੋ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡੋ:
ਇਸ ਨਾਲ ਤੁਸੀਂ ਟੈਮਪਲੇਟ ਅਪਡੇਟ ਕਰ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਇਤਿਹਾਸਕ ਸੁਬਮਿਸ਼ਨਾਂ ਨੂੰ ਟੁੱਟੇ।
ਆਫਲਾਈਨ ਸੋਚਦੇ ਹੋਏ ਜ਼ਰੂਰੀ ਖੇਤਰ:
id) ਤਾਂ ਜੋ ਰਿਕਾਰਡ ਆਫਲਾਈਨ ਵੀ ਹੋਣ।updated_at ਟਾਈਮਸਟੈਂਪ।version/ ਕਾਊਂਟਰ।ਇੱਕ ਸਧਾਰਨ ਅਤੇ ਭਰੋਸੇਯੋਗ ਤਰੀਕਾ ਹੋਵੇਗਾ: ਲੋਕਲ outbox queue ਜੋ ਕਾਰਵਾਈਆਂ (actions) ਨੂੰ ਰਿਕਾਰਡ ਕਰੇ—ਸਕਰੀਨ ਨੂੰ ਸਿੰਕ ਕਰਨ ਦੀ ਥਾਂ। ਹਰ ਇਵੈਂਟ ਵਿੱਚ ਹੋਵੇ:
ਰੀਟ੍ਰਾਈ ਹੋਣ 'ਤੇ ਡੁਪਲਿਕੇਟ ਰੋਕਣ ਲਈ ਹਰ ਬਦਲਾਅ ਨੂੰ event_id ਜਾਂ idempotency key ਨਾਲ ਭੇਜੋ। ਸਰਵਰ ਪ੍ਰੋਸੈਸ ਕੀਤੇ IDs ਸਟੋਰ ਕਰਕੇ ਦੁਹਰਾਏ ਗਏ ਇਵੈਂਟਾਂ ਨੂੰ ਅਣਡਿੱਠਾ ਕਰ ਦੇਵੇ।
ਇਸ ਨਾਲ ਦੋ ਵਾਰੀ ਰਿਕਾਰਡ ਬਣਨ ਜਾਂ ਚੈਕਬਾਕਸ ਦੁਹਰਾਉਣ ਤੋਂ ਬੱਚਾ ਜਾ ਸਕਦਾ ਹੈ।
ਜ਼ਿਆਦਤਰ ਐਪ ਦੋ-ਤੀਨ ਰਣਨੀਤੀਆਂ ਮਿਲਾ ਕੇ ਵਰਤਦੇ ਹਨ:
ਟਕਰਾਅ ਪਛਾਣ ਕਰਨ ਲਈ ਸਰਵਰ ਰਿਵੀਜ਼ਨ/ETag ਅਤੇ ਕਲਾਇੰਟ ਦਾ ਬੇਸ ਰਿਵੀਜ਼ਨ ਰਿਕਾਰਡ ਕਰੋ।
ਜ਼ੋਰਦਾਰ ਲੋਕਲ ਸਟੋਰ ਦੀ ਲੋੜ ਹੈ—ਤੇ ਉਸ ਦੇ ਨਾਲ ਮਾਈਗ੍ਰੇਸ਼ਨ।
ਹਰ ਚੇਨ ਤੋਂ ਪਹਿਲਾਂ ਸਕੀਮਾ ਵਰਜਨਿੰਗ ਅਤੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਸਕ੍ਰਿਪਟ ਰੱਖੋ।
ਆਪਣੇ ਖਤਰੇ ਨੂੰ ਸਮਝੋ:
ਟੋਕਨ ਲੋਕਲ ਸਟੋਰੇਜ ਵਿੱਚ ਸਾਧਾ ਨਹੀਂ ਰੱਖੋ—OS ਦੀ ਸੁਰੱਖਿਅਤ ਸਟੋਰੇਜ ਵਰਤੋ (iOS: Keychain; Android: Keystore/EncryptedSharedPreferences)।
ਸENSIਟਿਵ ਡੇਟਾ ਲਈ ਡੇਟਾਬੇਸ ਇੰਕ੍ਰਿਪਸ਼ਨ ਵਿਚਾਰ ਕਰੋ; ਪਰ ਕੀ-ਮੈਨੇਜਮੈਂਟ ਅਤੇ ਰਿਕਵਰੀ ਦੇ ਟਰੇਡ-ਆਫ ਹਨ।
ਅਸਲੀ ਜਾਲ-ਨੈੱਟਵਰਕਾਂ 'ਤੇ sync ਅਕਸਰ ਰੁਕਾਵਟਾਂ ਦਾ ਸ਼ਿਕਾਰ ਹੁੰਦਾ ਹੈ—ਇਸ ਲਈ ਨੈੱਟਵਰਕ ਨੂੰ ਅਣਰਿਲਾਇਅਬਲ ਸਮਝੋ।
event_id ਭੇਜੋ ਤਾਂ ਸਰਵਰ ਡੁਪਲਿਕੇਟ ਨੂੰ ਨਾਕਾਰ ਕਰ ਸਕੇ।ਸਮੱਗਰੀ-ਭਰੇ ਟੈਸਟ's ਅਤੇ ਹਾਰਡਵੇਅਰ ਰਿਆਲ ਵਰਤੋਂ ਨਾਲ ਟੇਸਟ ਕਰੋ:
ਆਪਣੇ sync queue ਅਤੇ conflict logic ਲਈ ਆਟੋਮੇਟਿਕ ਟੈਸਟ ਲਿਖੋ (ਆਰਡਰਿੰਗ, retries, idempotency, conflicts)।
ਲੋਕਲ DB 'ਤੇ ਲੋਡ ਟੈਸਟ ਚਲਾਓ: ਵੱਡੇ ਚੈਕਲਿਸਟ, ਬਹੁਤ ਸਾਰੇ ਆਈਟਮ ਅਤੇ ਅਟੈਚਮੈਂਟਸ—ਖੋਲ੍ਹਣ ਦਾ ਸਮਾਂ, ਬਹੁਤ ਤੇਜ਼ ਮਾਰਕ ਕਰਨ ਦੀ ਪ੍ਰਦਰਸ਼ਨ, ਸਟੋਰੇਜ ਵਿਕਾਸ।
ਰਿਲੀਜ਼ ਇੱਕ ਸ਼ੁਰੂਆਤ ਹੈ—ਬਤੇਰੇ ਫੀਡਬੈਕ ਲੂਪ ਸ਼ੁਰੂ ਕਰੋ:
ਪ੍ਰੋਟੋਟਾਈਪ ਲਈ ਤੇਜ਼ ਰਾਹ: Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ 'ਤੇ ਲੋਕਲ ਸਟੋਰ, outbox queue, ਅਤੇ ਬੇਸਿਕ Go/PostgreSQL ਬੈਕਏਂਡ ਨਾਲ MVP ਬਣਾਉ। ਜਦੋਂ ਤਿਆਰ ਹੋਵੋ ਤਾਂ ਸੋਰਸ ਕੋਡ ਐਕਸਪੋਰਟ ਕਰੋ ਅਤੇ ਫੀਲਡ ਫੀਡਬੈਕ ਦੇ ਆਧਾਰ 'ਤੇ ਭਰੋਸੇਯੋਗਤਾ ਵਧਾਓ।
revisiontemplate_version ਰਨ ਉੱਤੇ।ਇਹ ਫੀਲਡਜ਼ ਸਿੰਕ, ਰੀਟ੍ਰਾਈ ਅਤੇ ਟਕਰਾਅ ਦਾ ਪਤਾ ਲਗਾਉਣ ਲਈ ਮਦਦਗਾਰ ਹਨ।
event_id (UUID)type (ਉਦਾਹਰਨ: CHECK_ITEM, ADD_NOTE)payloadcreated_atstatus (pending, sending, sent, failed)UI ਤੁਰੰਤ ਲੋਕਲ ਡੀਬੀ ਤੋਂ ਅਪਡੇਟ ਹੁੰਦੀ ਹੈ; outbox ਬੈਕਗ੍ਰਾਉਂਡ ਵਿੱਚ ਸਿੰਕ ਕਰਦਾ ਹੈ।