18 ਸਤੰ 2025·8 ਮਿੰਟ
ਫੀਲਡ ਡੇਟਾ ਕਲੇਕਸ਼ਨ ਲਈ ਆਫਲਾਈਨ ਮੋਬਾਈਲ ਐਪ ਕਿਵੇਂ ਬਣਾਈਏ
ਫੀਲਡ ਡੇਟਾ ਕਲੇਕਸ਼ਨ ਲਈ ਆਫਲਾਈਨ-ਪਹਿਲਾ ਮੋਬਾਈਲ ਐਪ ਦੀ ਯੋਜਨਾ, ਡਿਜ਼ਾਇਨ ਅਤੇ ਨਿਰਮਾਣ ਕਰਨ ਦੇ ਬਾਰੇ ਸਿੱਖੋ—ਸਟੋਰੇਜ, ਸਿੰਕ, ਕਾਂਫਲਿਕਟ, ਸੁਰੱਖਿਆ ਅਤੇ ਟੈਸਟਿੰਗ ਸਮੇਤ।
ਫੀਲਡ ਡੇਟਾ ਕਲੇਕਸ਼ਨ ਲਈ ਆਫਲਾਈਨ-ਪਹਿਲਾ ਮੋਬਾਈਲ ਐਪ ਦੀ ਯੋਜਨਾ, ਡਿਜ਼ਾਇਨ ਅਤੇ ਨਿਰਮਾਣ ਕਰਨ ਦੇ ਬਾਰੇ ਸਿੱਖੋ—ਸਟੋਰੇਜ, ਸਿੰਕ, ਕਾਂਫਲਿਕਟ, ਸੁਰੱਖਿਆ ਅਤੇ ਟੈਸਟਿੰਗ ਸਮੇਤ।
ਟੂਲ ਚੁਣਨ ਜਾਂ ਸਕ੍ਰੀਨ ਡિઝਾਈਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਬਿਲਕੁਲ ਸਪੱਸ਼ਟ ਕਰੋ ਕਿ ਫੀਲਡ ਵਿੱਚ ਕੰਮ ਕਿਵੇਂ ਹੁੰਦਾ ਹੈ—ਅਤੇ ਤੁਹਾਡੀ ਟੀਮ ਲਈ “ਆਫਲਾਈਨ” ਦਾ ਕੀ ਮਤਲਬ ਹੈ। ਇਹ ਭਾਗ ਅਸਲ ਰੁਟੀਨਾਂ ਨੂੰ ਉਹਨਾਂ ਲੋੜਾਂ ਵਿੱਚ ਬਦਲਣ ਬਾਰੇ ਹੈ ਜੋ ਤੁਸੀਂ ਬਣਾਉ, ਟੈਸਟ ਅਤੇ ਸਹਾਇਤਾ ਕਰ ਸਕਦੇ ਹੋ।
ਰੋਲਾਂ ਨੂੰ ਨਾਂ ਨਾਲ ਲਿਖੋ: ਇੰਸਪੈਕਟਰ, ਸਰਵੇਅਰ, ਟੈਕਨੀਸ਼ਨ, ਆਡੀਟਰ, ਕਮਿਊਨਿਟੀ ਵਰਕਰ ਜਾਂ ਠੇਕੇਦਾਰ। ਹਰ ਰੋਲ ਦੇ ਵੱਖਰੇ ਸੀਮਾਵਾਂ ਹੋ ਸਕਦੀਆਂ ਹਨ (ਸੁਰੱਖਿਆ ਗੀਅਰ, ਇਕ-ਹੱਥ ਵਰਤੋਂ, ਲੰਮੇ ਦਿਨ ਦੀ ਯਾਤਰਾ, ਸਾਂਝੇ ਡਿਵਾਈਸ)।
ਜਿੱਥੇ ਉਹ ਕੰਮ ਕਰਦੇ ਹਨ ਉਹ ਦਸਤਾਵੇਜ਼ ਕਰੋ: ਅੰਦਰੂਨੀ ਸੁਵਿਧਾਵਾਂ, ਬੇਸਮੈਂਟ, ਦੂਰਦਰਾਜ਼ ਸੜਕਾਂ, ਖੇਤ, ਨਿਰਮਾਣ ਸਾਈਟਾਂ, ਜਾਂ ਸਰਹੱਦਾਂ ਪਾਰ। ਗੈਰ-ਸੁਧਾਰਤ ਹਕੀਕਤਾਂ ਜਿਵੇਂ ਅੰਤਰਾਲੀ ਸਿਗਨਲ, ਚਾਰਜ ਕਰਨ ਦੇ ਮੌਕੇ, ਅਤੇ ਕਿ ਉਪਭੋਗਤਾ "ਸਿੰਕ ਦਾ ਇੰਤਜ਼ਾਰ" ਕਰ ਸਕਦੇ ਹਨ ਜਾਂ ਨਹੀਂ (ਜ਼ਿਆਦਾਤਰ ਨਹੀਂ) ਨੂੰ ਨੋਟ ਕਰੋ।
ਉਹ ਰਿਕਾਰਡ ਲਿਸਟ ਕਰੋ ਜੋ ਤੁਹਾਡੇ ਐਪ ਨੂੰ ਇਕੱਠਾ ਕਰਨਾ ਹੈ ਅਤੇ ਕਿਸ ਕੰਮ, ਐਸੇਟ, ਸਥਾਨ ਜਾਂ ਗਾਹਕ ਨਾਲ ਜੋੜਿਆ ਜਾਣਾ ਹੈ। ਹਰ ਫੀਲਡ ਅਤੇ ਫਾਇਲ ਟਾਈਪ ਲਈ ਵਿਸਥਾਰ ਨਾਲ ਲਿਖੋ, ਉਦਾਹਰਨ ਲਈ:
ਇਹ ਵੀ ਪਰਿਭਾਸ਼ਾ ਕਰੋ ਕਿ “ਮੇਰਾ ਕੰਮ ਪੂਰਾ” ਦਾ ਕੀ ਅਰਥ ਹੈ: ਕੀ ਰਿਕਾਰਡ ਨੂੰ ਡਰਾਫਟ ਵਜੋਂ ਸੇਵ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਰਚਨਾ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ, ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਮਨਜ਼ੂਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ?
ਆਪਰੇਸ਼ਨਲ ਟਾਰਗਟਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਜਿਵੇਂ ਸੈਕੜਿਆਂ ਦਿਨਾਂ ਤੱਕ ਆਫਲਾਈਨ ਰਹਿਣ ਦੀ ਮਿਆਦ, ਡਿਵਾਈਸ ਪ੍ਰਤੀ ਉਮੀਦ ਕੀਤੀ ਗਈ ਰਿਕਾਰਡ ਗਿਣਤੀ, ਅਤੇ ਅਟੈਚਮੈਂਟ ਦੀ ਵੱਧੋ-ਵੱਧ ਸਾਈਜ਼। ਇਹ ਨੰਬਰ ਲੋਕਲ ਸਟੋਰੇਜ ਲੋੜਾਂ, ਪਰਫਾਰਮੈਂਸ ਪ੍ਰਭਾਵ ਅਤੇ ਸਿੰਕ ਵਿਹੇਵਿਯਰ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ।
ਐਜ ਉਪਦਾਨ ਵੀ ਸ਼ਾਮਲ ਕਰੋ: ਸਾਂਝੇ ਡਿਵਾਈਸ, ਪ੍ਰਤੀ ਦਿਨ ਕਈ ਨੌਕਰੀਆਂ, ਅਤੇ ਕਿ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਆਫਲਾਈਨ ਦੌਰਾਨ ਪੁਰਾਣੇ ਰਿਕਾਰਡ ਖੋਜਣ ਦੀ ਲੋੜ ਹੈ ਜਾਂ ਨਹੀਂ।
ਕੋਈ ਵੀ ਨਿੱਜੀ ਪਛਾਣ ਸੰਬੰਧੀ ਜਾਣਕਾਰੀ (PII), ਸਹਿਮਤੀ ਦੀ ਲੋੜ, ਰੱਖਿਆ ਨਿਯਮ, ਅਤੇ ਆਡਿਟ ਟਰੇਲ ਦਰਜ ਕਰੋ। ਜੇ ਮਨਜ਼ੂਰੀਆਂ ਦੀ ਲੋੜ ਹੈ (ਸੂਪਰਵਾਈਜ਼ਰ ਸਮੀਖਿਆ, QA ਚੈੱਕਸ), ਉਸੇ ਤਰ੍ਹਾਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਕਿ ਕਿਹੜੀਆਂ ਕਾਰਵਾਈਆਂ ਆਫਲਾਈਨ ਰੋਕੀਆਂ ਜਾਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ ਅਤੇ ਕਿਹੜੀਆਂ ਬਾਅਦ ਵਿੱਚ ਕਤਾਰਬੱਧ ਕੀਤੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ।
ਆਫਲਾਈਨ-ਪਹਿਲਾ ਡਿਜ਼ਾਇਨ ਇੱਕ ਸਾਫ਼ ਸਕੋਪ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ। ਹਰ ਫੀਚਰ ਜੋ ਤੁਸੀਂ ਆਫਲਾਈਨ ਦੀ ਆਗਿਆ ਦਿੰਦੇ ਹੋ, ਲੋਕਲ ਸਟੋਰੇਜ, ਸਿੰਕ ਜਟਿਲਤਾ ਅਤੇ ਕਾਂਫਲਿਕਟ ਰਿਸਕ ਵਧਾਉਂਦਾ ਹੈ—ਇਸ ਲਈ ਉਹ ਚੀਜ਼ਾਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਜੋ ਨੈੱਟਵਰਕ ਡ੍ਰਾਪ ਹੋਣ 'ਤੇ "ਲਾਜ਼ਮੀ" ਕੰਮ ਕਰਨੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ।
ਅਧਿਕাংশ ਫੀਲਡ ਟੀਮਾਂ ਲਈ, ਆਫਲਾਈਨ ਡੇਟਾ ਕਲੇਕਸ਼ਨ ਐਪ ਨੂੰ ਬੁਨਿਆਦੀ ਕਾਰਵਾਈਆਂ ਨੈੱਟਵਰਕ ਦੇ ਬਿਨਾਂ ਸਹਾਇਤ ਕਰਨੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ:
ਸਪਸ਼ਟ ਹੋਵੋ ਕਿ ਕਿਹੜੀਆਂ ਚੀਜ਼ਾਂ "ਰੇਡ-ਓਨਲੀ" ਹੋ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਕਿਹੜੀਆਂ সম্পੂਰਨ ਤੌਰ 'ਤੇ ਸੋਧਯੋਗ। ਆਫਲਾਈਨ ਸੋਧ ਆਮ ਤੌਰ 'ਤੇ ਮੋਬਾਈਲ ਆਫਲਾਈਨ ਸਿੰਕ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਕਾਂਫਲਿਕਟ ਰੈਜ਼ੋਲਿਊਸ਼ਨ ਦੀ ਲੋੜ ਕਰਦੀ ਹੈ।
ਆਫਲਾਈਨ ਜਟਿਲਤਾ ਘਟਾਉਣ ਲਈ ਵਿਆਵਹਾਰਿਕ ਤਰੀਕਾ ਹੈ ਛੋਟੀ-ਤੋਂ-ਛੋਟੀ ਆਫਲਾਈਨ ਲੂਪ ਪਹਿਲਾਂ ਰਿਲੀਜ਼ ਕਰਨਾ:
ਜੇ ਕੋਈ "ਨਿਸ਼ਚਿਤ" ਫੀਚਰ ਭਾਰੀ ਰੇਫਰੈਂਸ ਡੇਟਾ ਕੇਸ਼ਿੰਗ ਜਾਂ ਮੁਸ਼ਕਲ ਮੇਰਜ ਮੰਗਦਾ ਹੈ, ਤਾਂ ਉਸਨੂੰ ਦੇਰ ਕਰੋ ਜਦ ਤੱਕ ਕੋਰ ਵਰਕਫਲੋ ਭਰੋਸੇਯੋਗ ਨਾ ਹੋਵੇ।
ਕੁਝ ਕਾਰਵਾਈਆਂ ਆਫਲਾਈਨ ਰੋਕਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ (ਜਾਂ ਜਦੋਂ ਰੈਫਰੈਂਸ ਡੇਟਾ ਪੁਰਾਣਾ ਹੋ):
ਸਪੱਸ਼ਟ ਨਿਯਮ ਵਰਤੋ, ਜਿਵੇਂ “ਡਰਾਫਟ ਆਫਲਾਈਨ ਅਨੁਮਤ, ਸਬਮਿਸ਼ਨ ਲਈ ਸਿੰਕ ਲਾਜ਼ਮੀ।”
ਕਨੈਕਟਿਵਿਟੀ ਨੂੰ ਛੁਪਾਓ ਨਹੀਂ—ਇਸਨੂੰ ਵਿਆਖਿਆਤ ਕਰੋ:
ਇਹ ਸਕੋਪ ਹਰ ਬਾਅਦ ਆਉਣ ਵਾਲੇ फैसਲੇ ਲਈ ਤੁਹਾਡਾ ਠੇਕਾ ਹੈ: ਡੇਟਾ ਮਾਡਲ, ਬੈਕਗ੍ਰਾਊਂਡ ਸਿੰਕ, ਅਤੇ ਡਿਵਾਈਸ ਸੁਰੱਖਿਆ ਆਫਲਾਈਨ।
ਤੁਹਾਡੇ ਆਫਲਾਈਨ ਐਪ ਦੀ ਆਰਕੀਟੈਕਚਰ "ਕੋਈ ਕਨੈਕਸ਼ਨ ਨਹੀਂ" ਨੂੰ ਸਧਾਰਨ ਹਾਲਤ ਬਣਾਉਣੀ ਚਾਹੀਦੀ ਹੈ, ਬਲਕੇ ਇਸਨੂੰ ਅਪਵਾਦ ਨਹੀਂ। ਲਕੜੀ ਦਾ ਨਿਸ਼ਾਨ ਇਹ ਹੈ ਕਿ ਡੇਟਾ ਐਂਟਰੀ ਤੇਜ਼ ਅਤੇ ਸੁਰੱਖਿਅਤ ਹੋਵੇ ਡਿਵਾਈਸ 'ਤੇ, ਅਤੇ ਜਦੋਂ ਕਨੈਕਟਿਵਿਟੀ ਵਾਪਿਸ ਆਵੇ ਤਾਂ ਸਿੰਕ ਪੇਸ਼ਗੋਈਯੋਗ ਹੋਵੇ।
ਫੈਸਲਾ ਕਰੋ ਕਿ ਤੁਸੀਂ iOS, Android, ਜਾਂ ਦੋਹਾਂ ਲਈ ਬਣਾਉਂਦੇ ਹੋ।
ਜੇ ਤੁਹਾਡੇ ਉਪਭੋਗਤਾ ਮੁੱਖ ਤੌਰ 'ਤੇ ਇੱਕ ਪਲੇਟਫਾਰਮ 'ਤੇ ਹਨ (ਜੋ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਰੋਲਆਉਟਾਂ ਵਿੱਚ ਆਮ ਹੈ), ਤਾਂ ਨੇਟਿਵ ਬਣਾਉਣਾ ਪ੍ਰਦਰਸ਼ਨ ਟਿਊਨਿੰਗ, ਬੈਕਗ੍ਰਾਊਂਡ ਵਿਹੇਵਿਯਰ, ਅਤੇ OS-ਨਿਰਧਾਰਤ ਸਟੋਰੇਜ/ਸੁਰੱਖਿਆ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਸੌਖਾ ਕਰ ਸਕਦਾ ਹੈ। ਜੇ ਤੁਹਾਨੂੰ day-one ਤੋਂ iOS ਅਤੇ Android ਦੀ ਲੋੜ ਹੈ, ਤਾਂ React Native ਜਾਂ Flutter ਵਰਗੇ ਕ੍ਰਾਸ-ਪਲੇਟਫਾਰਮ ਫਰੇਮਵਰਕ UI ਕੰਮ ਘਟਾ ਸਕਦੇ ਹਨ—ਪਰ ਤੁਹਾਨੂੰ ਫਿਰ ਵੀ ਬੈਕਗ੍ਰਾਊਂਡ ਸਿੰਕ, ਪਰਮਿਸ਼ਨ (GPS/ਕੈਮਰਾ), ਅਤੇ ਫਾਇਲ ਸਟੋਰੇਜ ਲਈ ਪਲੇਟਫਾਰਮ-ਅਵેગੇਅਰ ਹੈਂਡਲਿੰਗ ਦੀ ਲੋੜ ਹੋਵੇਗੀ।
ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧਣਾ ਚਾਹੁੰਦੇ ਹੋ ਅਤੇ ਇੱਕ ਸਪੱਸ਼ਟ ਰਸਤਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਵੈੱਬ, ਬੈਕਐਂਡ ਅਤੇ ਮੋਬਾਈਲ 'ਚ ਛੋਟੇ ਸੈੱਟ ਦੀਆਂ ਤਕਨੀਕਾਂ 'ਤੇ ਸਟੈਂਡਰਡਾਈਜ਼ ਕਰਨ ਨਾਲ ਮਦਦ ਮਿਲ ਸਕਦੀ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਪਲੇਟਫਾਰਮ ਜਿਵੇਂ Koder.ai ਚੈਟ-ਚਲਿਤ ਵਰਕਫਲੋ ਲਈ ਡਿਜ਼ਾਇਨ ਕੀਤੇ ਗਏ ਹਨ (ਆਮ ਤੌਰ 'ਤੇ React ਵੈੱਬ 'ਤੇ, Go + PostgreSQL ਬੈਕਐਂਡ 'ਤੇ, ਅਤੇ Flutter ਮੋਬਾਈਲ ਲਈ)। ਭਾਵੇਂ ਤੁਸੀਂ ਪਲੇਟਫਾਰਮ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਹੀਂ ਅਪਣਾਉਂਦੇ, ਇਸ ਤਰ੍ਹਾਂ ਦਾ স্টੈਂਡਰਡਾਈਜ਼ੇਸ਼ਨ ਮਨੋਵਿਗਿਆਨ ਆਫਲਾਈਨ-ਪਹਿਲਾ ਵਿਕਾਸ ਨੂੰ ਸਕੇਲ ਅਤੇ ਮੇਨਟੇਨ ਕਰਨ ਵਿੱਚ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ।
ਆਫਲਾਈਨ-ਪਹਿਲਾ ਐਪ ਆਪਣੀ ਡਿਵਾਈਸ-ਉਪਲਬਧ ਡੈਟਾਬੇਸ 'ਤੇ ਜਿੰਦੇ ਹਨ ਜਾਂ ਮਰ ਜਾਂਦੇ ਹਨ। ਆਮ ਵਿਕਲਪ:
ਜੋ ਵੀ ਚੁਣੋ, ਮਾਈਗ੍ਰੇਸ਼ਨਾਂ ਤੇ ਧਿਆਨ ਦਿਓ ਜੋ ਤੁਸੀਂ ਭਰੋਸੇਯੋਗ ਕਰ ਸਕੋ, ਪੁਰਾਣੇ ਡਿਵਾਈਸਾਂ 'ਤੇ ਕੁਐਰੀ ਪਰਫਾਰਮੈਂਸ, ਅਤੇ ਇਨਕ੍ਰਿੱਪਸ਼ਨ ਸਹਾਇਤਾ।
REST ਅਤੇ GraphQL ਦੋਹਾਂ ਆਫਲਾਈਨ ਸਿੰਕ ਲਈ ਕੰਮ ਕਰ ਸਕਦੇ ਹਨ, ਪਰ ਇੱਕ ਚੁਣੋ ਅਤੇ ਸਮੇਂ ਦੇ ਨਾਲ ਬਦਲਾਅ ਲਈ ਉਸਨੂੰ ਡਿਜ਼ਾਇਨ ਕਰੋ।
ਇੱਕ ਵਾਜਿਬ ਵਰਜਨਿੰਗ ਰਣਨੀਤੀ ਸ਼ਾਮਲ ਕਰੋ (ਉਦਾਹਰਨ: /v1 ਐਂਡਪਾਇੰਟਸ ਜਾਂ ਸਕੀਮਾ ਵਰਜ਼ਨ) ਤਾਂ ਜੋ ਪੁਰਾਣੀਆਂ ਐਪ ਬਿਲਡਾਂ ਦੌਰਾਨ ਵੀ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਸਿੰਕ ਕਰ ਸਕਣ।
ਫੋਟੋਆਂ, ਦਸਤਖਤ, ਆਡੀਓ, ਅਤੇ ਦਸਤਾਵੇਜ਼ਾਂ ਲਈ ਅਲੱਗ ਯੋਜਨਾ:
UI → ਲੋਕਲ ਡੈਟਾਬੇਸ → ਸਿੰਕ ਵਰਕਰ → API, ਇਹ ਸਾਫ਼ ਵੱਖ-ਵੱਖਤਾ ਆਫਲਾਈਨ ਕੈਪਚਰ ਨੂੰ ਭਰੋਸੇਯੋਗ ਰੱਖਦੀ ਹੈ।
ਤੁਹਾਡਾ ਆਫਲਾਈਨ ਐਪ ਆਪਣੀ ਲੋਕਲ ਡੇਟਾ ਮਾਡਲ 'ਤੇ ਟਿਕਿਆ ਹੁੰਦਾ ਹੈ। ਲਕੜੀ ਦਾ ਨਿਸ਼ਾਨ ਸਧਾਰਨ ਹੈ: ਫੀਲਡ ਸਟਾਫ਼ ਰਿਕਾਰਡ ਬਣਾ ਸਕਣ, ਡਰਾਫਟ ਸੇਵ ਕਰ ਸਕਣ, ਬਾਅਦ ਵਿੱਚ ਸੋਧ ਸਕਣ, ਅਤੇ ਹਟਾ ਵੀ ਸਕਣ—ਬਿਨਾਂ ਨੈੱਟਵਰਕ ਦੀ ਉਡੀਕ ਕੀਤੇ। ਇਸਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਤੁਹਾਡੀ ਲੋਕਲ ਡੈਟਾਬੇਸ ਨੂੰ “ਕੰਮ ਚੱਲ ਰਹੀ” ਅਵਸਥਾ ਦਰਸਾਉਣੀ ਚਾਹੀਦੀ ਹੈ, ਸਿਰਫ਼ ਫਾਈਨਲ ਡੇਟਾ ਨਹੀਂ।
ਇੱਕ ਕਾਰਗਰ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਹਰ ਰਿਕਾਰਡ ਨੂੰ ਇੱਕ sync state ਦੇ ਨਾਲ ਸਟੋਰ ਕਰੋ (ਉਦਾਹਰਨ: draft, pending_upload, synced, pending_delete)। ਇਹ ਐਸੇ ਕੰਨ ਜਾਂ ਸਥਿਤੀਆਂ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ ਜਿਵੇਂ "ਲੋਕਲ ਤੌਰ 'ਤੇ ਮਿਟਾਇਆ ਗਿਆ ਪਰ ਰੀਸਟਾਰਟ ਬਾਅਦ ਫਿਰ ਵੀ ਦਿਖਾਇਆ ਜਾ ਰਿਹਾ"।
ਸੋਧਾਂ ਲਈ, ਸੋਚੋ ਕਿ ਜਾਂ (a) ਆਖਰੀ ਲੋਕਲ ਵਰਜ਼ਨ + pending changes ਦੀ ਲਿਸਟ ਰੱਖੋ, ਜਾਂ (b) ਪੂਰਾ ਲੋਕਲ ਰਿਕਾਰਡ ਰੱਖੋ ਜੋ ਸਿੰਕ ਦਰਮਿਆਨ ਸਰਵਰ ਫੀਲਡਾਂ ਨੂੰ ਓਵਰਰਾਈਟ ਕਰੇਗਾ। ਵਿਕਲਪ (a) ਵਧੇਰੇ ਜਟਿਲ ਹੈ ਪਰ ਕਾਂਫਲਿਕਟ ਹینڈਲਿੰਗ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।
ਗੈਰ-ਟੈਕਨੀਕਲ ਟੀਮਾਂ ਲਈ ਵੀ ਕੁੱਝ ਸਥਿਰ ਫੀਲਡ ਹਰ ਚੀਜ਼ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ:
ਜੇ ਤੁਸੀਂ ਆਫਲਾਈਨ IDs ਬਣਾਂਦੇ ਹੋ, ਟੱਕਰ ਤੋਂ ਬਚਣ ਲਈ UUIDs ਵਰਤੋ।
ਫੀਲਡ ਐਪ ਆਮ ਤੌਰ 'ਤੇ ਕੈਟਾਲੌਗਾਂ 'ਤੇ ਨਿਰਭਰ ਹੁੰਦੇ ਹਨ: ਐਸੇਟ ਲਿਸਟ, ਸਾਈਟ ਹਾਇਰਾਰਕੀ, ਪਿਕਲਿਸਟ, ਹੈਜ਼ਰਡ ਕੋਡ ਆਦਿ। ਇਨ੍ਹਾਂ ਨੂੰ ਵੀ ਲੋਕਲ ਰੱਖੋ ਅਤੇ ਇੱਕ ਰੈਫਰੈਂਸ ਡੇਟਸੈੱਟ ਵਰਜ਼ਨ (ਜਾਂ “last_updated_at”) ਟਰੈਕ ਕਰੋ। ਹਿੱਸੇਵਾਰ ਅਪਡੇਟ ਲਈ ਡਿਜ਼ਾਇਨ ਕਰੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਸਿਰਫ਼ ਬਦਲੀਆਂ ਚੀਜ਼ਾਂ ਰੀਫ੍ਰੈਸ਼ ਕਰੋ, ਪੂਰਾ ਡਾਊਨਲੋਡ ਨਾ ਕਰਨਾ ਪਏ।
ਆਫਲਾਈਨ ਉਪਭੋਗਤਾ ਤੁਰੰਤ ਨਤੀਜੇ ਦੀ ਉਮੀਦ ਕਰਦੇ ਹਨ। ਆਮ ਕੁਐਰੀਆਂ ਲਈ ਇੰਡੈਕਸ ਜੋੜੋ ਜਿਵੇਂ “ਸਾਈਟ ਅਨੁਸਾਰ”, “ਸਟੈਟਸ ਮੁਤਾਬਕ”, “ਹਾਲ ਹੀ ਅਪਡੇਟ ਹੋਏ”, ਅਤੇ ਕੋਈ ਵੀ searchable identifiers (ਐਸੇਟ ਟੈਗ, ਵਰਕ ਆਰਡਰ ਨੰਬਰ)। ਇਸ ਨਾਲ UI ਸਪੀਡੀ ਰਹਿੰਦਾ ਹੈ ਭਾਵੇਂ ਲੋਕਲ ਡੇਟਾਬੇਸ ਹਫਤਿਆਂ ਵਿੱਚ ਵੱਡਾ ਹੋ ਜਾਵੇ।
ਫੀਲਡ ਟੀਮਾਂ ਕਿਸੇ ਦਫਤਰੀ ਵਰਤੋਂਕਾਰ ਵਾਂਗ "ਫਾਰਮ ਭਰਦੀਆਂ" ਨਹੀਂ। ਉਹ ਭੱਜ ਰਹੇ ਹੁੰਦੇ ਹਨ, ਬਰਸਾਤ ਵਿੱਚ ਖੜੇ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਰੁਕਾਵਟਾਂ ਆ ਜਾਂਦੀਆਂ ਹਨ। ਤੁਹਾਡਾ ਕੰਮ ਇਹ ਬਣਾਉਣਾ ਹੈ ਕਿ ਡੇਟਾ ਕੈਪਚਰ ਬੇੜੀ-ਟੁੱਟ ਨ ਹੋਵੇ—ਭਾਵੇਂ ਕਨੈਕਟਿਵਿਟੀ ਨਾ ਹੋਵੇ।
ਇੱਕ ਫਾਰਮ ਇੰਜਣ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਹਰ ਕੀਸਟ੍ਰੋਕ ਨੂੰ ਕੀਮਤੀ ਮੰਨਦਾ ਹੋਵੇ। ਡਰਾਫਟਸ ਆਟੋ-ਸੇਵ ਕਰੋ (ਸਿਰਫ਼ ਸਬਮਿਟ 'ਤੇ ਨਹੀਂ), ਅਤੇ ਸੇਵਿੰਗ ਨੂੰ ਗੁਪਤ ਰੱਖੋ: ਕੋਈ ਸਪਿਨਰ, ਕੋਈ ਬਲਾਕ ਕਰਨ ਵਾਲੀ "ਕ੍ਰਿਪਾ ਕਰਕੇ ਇੰਤਜ਼ਾਰ ਕਰੋ" ਡਾਇਲਾਗ ਨਹੀਂ।
ਲੋਕਲ ਤੌਰ 'ਤੇ ਵੈਧਤਾ (validation) ਕਰੋ ਤਾਂ ਕਿ ਉਪਭੋਗਤਾ ਬਿਨਾਂ ਨੈੱਟਵਰਕ ਦੇ ਟਾਸਕ ਮੁਕੰਮਲ ਕਰ ਸਕੇ। ਨਿਯਮ ਸਧਾਰਨ ਅਤੇ ਤੇਜ਼ ਰੱਖੋ (ਲਾਜ਼ਮੀ ਫੀਲਡ, ਰੇਂਜ, ਮੁਢਲੀ ਫਾਰਮੈਟ)। ਜੇ ਕੁਝ ਚੈਕ ਸਰਵਰ-ਸਾਈਡ ਵੈਰੀਫਿਕੇਸ਼ਨ ਮੰਗਦੇ ਹਨ ( ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ID ਦੀ ਪੁਸ਼ਟੀ), ਤਾਂ ਉਹਨਾਂ ਨੂੰ “ਸਿੰਕ ਦੌਰਾਨ ਜਾਂਚਿਆ ਜਾਵੇਗਾ” ਵਜੋਂ ਲੇਬਲ ਕਰੋ ਅਤੇ ਉਪਭੋਗਤਾ ਨੂੰ ਅਗੇ ਵਧਣ ਦੀ ਆਗਿਆ ਦਿਓ।
ਭਾਰੀ ਸਕ੍ਰੀਨਾਂ ਤੋਂ ਬਚੋ। ਲੰਮੇ ਵਰਕਫਲੋਜ਼ ਨੂੰ ਛੋਟੇ ਕਦਮਾਂ ਵਿੱਚ ਵੰਡੋ (ਉਦਾਹਰਨ: “1 ਵਿੱਚੋਂ 4”)। ਇਹ ਕਰਕੇ ਕਰੈਸ਼ ਘਟਦੇ ਹਨ, ਰੀਜ਼ਿਊਮ ਅਸਾਨ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਪੁਰਾਣੇ ਡਿਵਾਈਸਾਂ 'ਤੇ ਪਰਫਾਰਮੈਂਸ ਸੁਧਾਰਦੀ ਹੈ।
ਅਸਲ ਇੰਸਪੈਕਸ਼ਨ ਆਮ ਤੌਰ 'ਤੇ “ਹੋਰ ਆਈਟਮ ਜੋੜੋ” ਪੈਟਰਨ ਸ਼ਾਮਲ ਕਰਦੇ ਹਨ: ਕਈ ਐਸੇਟ, ਪੜ੍ਹਾਈਆਂ, ਜਾਂ ਖ਼ਰਾਬੀਆਂ। ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਸੈਕਸ਼ਨਾਂ ਲਈ ਸਮਰਥਨ ਕਰੋ:
ਸ਼ਰਤੀ ਸਵਾਲ ਆਫਲਾਈਨ ਦੂਰਬੀਨ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਅਧਾਰਤ ਸ਼ਰਤਾਂ ਸਿਰਫ਼ ਉਹਨਾਂ ਮੂਲੀਆਂ ਤੇ ਹੋਣ ਜੋ ਪਹਿਲਾਂ ਹੀ ਡਿਵਾਈਸ 'ਤੇ ਮੌਜੂਦ ਹਨ (ਪਿਛਲੇ ਜਵਾਬ, ਉਪਭੋਗਤਾ ਰੋਲ, ਚੁਣੀ ਹੋਈ ਸਾਈਟ ਕਿਸਮ), ਨਾ ਕਿ ਸਰਵਰ ਲੁੱਕਅੱਪ 'ਤੇ।
ਜਦੋਂ ਯੋਗ ਹੋਵੇ, ਐਪ ਪ੍ਰਸੰਗ ਆਟੋਮੈਟਿਕਲੀ ਇਕੱਤਰ ਕਰੇ:
ਇਹ ਸਿਗਨਲ ਉਪਭੋਗਤਾ-ਭਰਕੇ ਮੁੱਲਾਂ ਨਾਲ ਸਾਥ-ਸਾਥ ਸਟੋਰ ਕਰੋ ਤਾਂ ਕਿ ਬਾਅਦ ਵਿੱਚ ਰਿਕਾਰਡ ਦੀ ਜਾਂਚ ਅਤੇ ਭਰੋਸਾ ਕੀਤਾ ਜਾ ਸਕੇ।
ਹਰ ਅਟੈਚਮੈਂਟ ਨੂੰ ਆਪਣਾ ਛੋਟਾ-ਜੋਬ ਸਮਝੋ। ਅਪਲੋਡ ਕਤਾਰ ਨੂੰ ਫਾਰਮ ਸਿੰਕ ਤੋਂ ਵੱਖਰਾ ਕਰੋ, ਰੀਟਰੀ/ਰੀਜ਼ਿਊਮ ਦਾ ਸਮਰਥਨ ਕਰੋ, ਅਤੇ ਪ੍ਰਤੀ-ਫਾਇਲ ਸਥਿਤੀ ਦਿਖਾਓ: pending, uploading, failed, uploaded। ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਬੈਕਗ੍ਰਾਊਂਡ ਵਿੱਚ ਕੰਮ ਜਾਰੀ ਰੱਖਣ ਦਿਓ ਅਤੇ ਅਪਲੋਡ ਨਾ ਹੋਣ 'ਤੇ ਫਾਰਮ ਸਬਮਿਸ਼ਨ ਨੂੰ ਕਿਸੇ ਵੀ ਹਾਲਤ ਵਿੱਚ ਰੋਕੋ ਨਾ।
ਫੀਲਡ ਟੀਮਾਂ ਅਕਸਰ “ਸਿਰਫ ਫਾਰਮ” ਨਾਲ ਕੰਮ ਨਹੀਂ ਕਰਦੀਆਂ। ਉਹਨਾਂ ਨੂੰ ਰੈਫਰੈਂਸ ਜਾਣਕਾਰੀ—ਐਸੇਟ ਲਿਸਟ, ਕਸਟਮਰ ਸਾਈਟ, ਉਪਕਰਨ ਕੈਟਾਲੌਗ, ਪਿਕਲਿਸਟ, ਸੁਰੱਖਿਆ ਚੈੱਕਲਿਸਟ—ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਅਤੇ ਉਹ ਅਕਸਰ ਨਕਸ਼ਾ ਚਾਹੁੰਦੇ ਹਨ ਜੋ ਸਿਗਨਲ ਡ੍ਰਾਪ ਹੋਣ 'ਤੇ ਵੀ ਕੰਮ ਕਰੇ। ਇਨ੍ਹਾਂ ਨੂੰ ਪਹਿਲੀ-ਸ਼੍ਰੇਣੀ ਫੀਚਰ ਵਜੋਂ ਵਰਤੋ, ਨਿਸ਼ਚਿਤ ਨਹੀਂ।
ਉਹ ਸਭ ਤੋਂ ਛੋਟਾ ਸੈੱਟ ਪਛਾਣੋ ਜੋ ਵਰਕਫਲੋ ਪ੍ਰਯੋਗਯੋਗ ਬਣਾਉਂਦਾ ਹੈ (ਉਦਾਹਰਨ: ਨਿਰਧਾਰਿਤ ਵਰਕ ਆਰਡਰ, ਐਸੇਟ IDs, ਸਥਾਨ, ਆਗਿਆਤ ਮੁੱਲ)। ਫਿਰ ਹਿੱਸੇਵਾਰ ਡਾਊਨਲੋਡਾਂ ਨੂੰ ਸਮਰਥਨ ਕਰੋ—ਅੰਤਰਗ੍ਰਹਿ, ਪ੍ਰਾਜੈਕਟ, ਟੀਮ, ਜਾਂ ਮਿਤੀ ਰੇਂਜ ਅਨੁਸਾਰ—ਤਾਂ ਕਿ ਡਿਵਾਈਸ ਨੂੰ ਸਭ ਕੁਝ ਸਟੋਰ ਕਰਨ ਦੀ ਲੋੜ ਨਾ ਪਏ।
ਵਰਤੋਂਯੋਗ ਪਹੁੰਚ ਹੈ "ਆਫਲਾਈਨ ਵਰਤੋਂ ਲਈ ਡਾਊਨਲੋਡ" ਸਕਰੀਨ:
ਜੇ ਟੈਕਨੀਸ਼ਨ ਨੂੰ ਨੈਵੀਗੇਸ਼ਨ ਅਤੇ ਪ੍ਰਸੰਗ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਚੁਣੇ ਹੋਏ ਖੇਤਰਾਂ ਲਈ ਟਾਈਲਾਂ ਪ੍ਰੀਫੈਚ ਕਰਕੇ ਆਫਲਾਈਨ ਨਕਸ਼ੇ ਲਾਗੂ ਕਰੋ (ਉਦਾਹਰਨ: ਨੌਕਰੀ ਸਾਈਟ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਬਾਉਂਡਿੰਗ ਬਾਕਸ ਜਾਂ ਰੂਟ ਕੋਰਿਡੋਰ)। ਕੇਸ਼ ਸੀਮਾਵਾਂ ਲਾਗੂ ਕਰੋ—ਕੁੱਲ ਆਕਾਰ ਅਤੇ ਪ੍ਰਤੀ-ਏਰੀਆ—ਤਾਂ ਕਿ ਖਾਮੋਸ਼ ਸਟੋਰੇਜ ਅਸਫਲਤਾਵਾਂ ਤੋਂ ਬਚਿਆ ਜਾ ਸਕੇ।
ਤੁਹਾਡੇ ਕੰਟਰੋਲ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰੋ:
ਤੇਜ਼ ਲੁਕਅੱਪ ਬਿਨਾਂ ਆਫਲਾਈਨ ਪਹੁੰਚ ਖੁਫੀਆ ਹੁੰਦੀ ਹੈ। ਮੁੱਖ ਫੀਲਡਾਂ (IDs, ਨਾਮ, ਟੈਗ, ਪਤੇ) ਲਈ ਲੋਕਲ ਇੰਡੈਕਸ ਬਣਾਓ ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਦੇ ਫਿਲਟਰ ਦੇ ਨਾਲ ਸਹਾਇਤਾ ਕਰੋ ਜੋ ਅਸਲ ਕਾਰਜਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹਨ (ਪ੍ਰਾਜੈਕਟ, ਸਥਿਤੀ, ਮੈਨੂੰ ਨਿਰਧਾਰਿਤ)। ਸੇਵ ਕੀਤੀਆਂ ਕੁਐਰੀਆਂ ("ਮੇਰੀਆਂ ਸਾਈਟਾਂ ਇਸ ਹਫਤੇ") ਟੈਪਿੰਗ ਘਟਾਉਂਦੀਆਂ ਹਨ ਅਤੇ ਆਫਲਾਈਨ ਨੂੰ ਇਰਾਦੇਵੰਦ ਬਣਾਉਂਦੀਆਂ ਹਨ।
ਹਮੇਸ਼ਾਂ ਰੈਫਰੈਂਸ ਡੇਟਾ ਅਤੇ ਨਕਸ਼ਾ ਖੇਤਰਾਂ ਲਈ “ਤਾਜ਼ਗੀ” ਦਿਖਾਓ: ਆਖਰੀ ਸਿੰਕ ਸਮਾਂ, ਡੇਟਾਸੈੱਟ ਵਰਜ਼ਨ, ਅਤੇ ਕਿ ਅਪਡੇਟਜ਼ ਪੈਂਡਿੰਗ ਹਨ ਜਾਂ ਨਹੀਂ। ਜੇ ਕੁਝ ਪੁਰਾਣਾ ਹੈ, ਤਾਂ ਇੱਕ ਸਪੱਸ਼ਟ ਬੈਨਰ ਦਿਖਾਓ ਅਤੇ ਉਪਭੋਗਤਾ ਨੂੰ ਜਾਣਕਾਰੀ ਦਿਓ ਕਿ ਉਹ ਕਿਸ ਸੀਮਿਤਤਾ ਨਾਲ ਅੱਗੇ ਵੱਧ ਸਕਦਾ ਹੈ—ਜਦੋਂ ਅਗਲੀ ਕਨੈਕਸ਼ਨ ਹੋਵੇ ਤਾਂ ਰੀਫ੍ਰੈਸ਼ ਕਤਾਰਬੱਧ ਕਰੋ।
ਸਿੰਕ ਫੀਲਡ ਵਿੱਚ ਕੀ ਹੁੰਦਾ ਹੈ ਅਤੇ ਦਫਤਰ ਕਿਵੇਂ ਵੇਖਦਾ ਹੈ, ਇਸ ਦੋਹਾਂ ਦਾ ਪੁਲ ਹੈ। ਇੱਕ ਭਰੋਸੇਯੋਗ ਰਣਨੀਤੀ ਅਣਪੁੱਰਨ ਕਨੈਕਟਿਵਿਟੀ, ਸੀਮਤ ਬੈਟਰੀ, ਅਤੇ ਐਪ ਬੰਦ ਹੋਣ ਦੇ ਮੌਕੇ ਨੂੰ ਮਨ ਵਿੱਚ ਰੱਖਦੀ ਹੈ।
ਵੱਖ-ਵੱਖ ਟੀਮਾਂ ਵੱਖ-ਵੱਖ ਸਮੇਂ ਦੀ ਲੋੜ ਰੱਖਦੀਆਂ ਹਨ। ਆਮ ਟ੍ਰਿਗਰਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:
ਅਧਿਕাংশ ਐਪ ਇਹਨਾਂ ਨੂੰ ਮਿਲਾ ਕੇ ਵਰਤਦੇ ਹਨ: ਮੂਲ ਤੌਰ 'ਤੇ ਬੈਕਗ੍ਰਾਊਂਡ ਸਿੰਕ, ਅਤੇ ਮਨ-ਸ਼ਾਂਤੀ ਲਈ ਮੈਨੁਅਲ ਵਿਕਲਪ।
ਹਰ ਬਣਾਉ/ਅੱਪਡੇਟ/ਡਿਲੀਟ ਨੂੰ ਇੱਕ ਲੋਕਲ "ਇਵੈਂਟ" ਵਜੋਂ outbox queue ਵਿੱਚ ਲਿਖੋ। ਸਿੰਕ ਇੰਜਣ ਆਊਟਬਾਕ ਨੂੰ ਪੜ੍ਹਦਾ ਹੈ, ਸਰਵਰ ਨੂੰ ਬਦਲਾਵ ਭੇਜਦਾ ਹੈ, ਅਤੇ ਹਰ ਇਵੈਂਟ ਨੂੰ ਪੁਸ਼ਟੀ ਦਿੰਦਾ ਹੈ।
ਇਸ ਨਾਲ ਸਿੰਕ ਲਚਕੀਲਾ ਬਣਦਾ ਹੈ: ਉਪਭੋਗਤਾ ਕੰਮ ਜਾਰੀ ਰੱਖ ਸਕਦੇ ਹਨ, ਅਤੇ ਤੁਹਾਨੂੰ ਹਮੇਸ਼ਾਂ ਪਤਾ ਹੁੰਦਾ ਹੈ ਕਿ ਕੀ ਅਜੇ ਅਪਲੋਡ ਹੋਣਾ ਬਾਕੀ ਹੈ।
ਮੋਬਾਈਲ ਨੈੱਟਵਰਕ ਪੈਕੇਟ ਡ੍ਰਾਪ ਕਰਦੇ ਹਨ, ਅਤੇ ਉਪਭੋਗਤਾ ਕਈ ਵਾਰੀ “Sync” ਦਬਾ ਸਕਦੇ ਹਨ। ਬੇਨਤੀ ਅਜਿਹੀ ਬਣਾਓ ਕਿ ਜੇ ਉਹ ਦੁਹਰਾਈ ਜਾਵੇ ਤਾਂ ਰਿਕਾਰਡ ਡੁਪਲਿਕੇਟ ਨਾ ਬਣਨ।
ਵਾਸਤਵਿਕ ਤਰੀਕੇ:
ਇੱਕ ਦਿਨ ਆਫਲਾਈਨ ਰਹਿਣ ਦੇ ਬਾਅਦ, ਅਪਲੋਡ ਵੱਡੇ ਹੋ ਸਕਦੇ ਹਨ। ਟਾਇਮਆਊਟ ਅਤੇ ਥਰੋਟਲਿੰਗ ਤੋਂ ਬਚਣ ਲਈ:
ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਦਿੱਖੀ ਪ੍ਰਗਤੀ ਦਿਖਾਓ (“23 ਵਿੱਚੋਂ 120 ਆਈਟਮ ਅਪਲੋਡ ਹੋਏ”) ਤਾਂ ਕਿ ਫੀਲਡ ਸਟਾਫ਼ ਐਪ 'ਤੇ ਭਰੋਸਾ ਕਰੇ।
ਆਫਲਾਈਨ ਕੰਮ ਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਇੱਕੋ ਰਿਕਾਰਡ ਦੀਆਂ ਦੋ ਵਰਜ਼ਨ ਇਕੱਠੇ ਹੋ ਸਕਦੀਆਂ ਹਨ: ਡਿਵਾਈਸ 'ਤੇ ਤਬਦੀਲ ਕੀਤਾ ਸੰਸਕਰਨ ਅਤੇ ਸਰਵਰ 'ਤੇ ਹੋਇਆ ਤਬਦੀਲ। ਜੇ ਤੁਸੀਂ ਇਸ ਲਈ ਯੋਜਨਾ ਨਹੀਂ ਬਣਾਉਂਦੇ, ਤਾਂ ਤੁਹਾਨੂੰ "ਅਚਾਨਕ" ਓਵਰਰਾਈਟ, ਗੁੰਮ ਹੋਏ ਮੁੱਲ, ਅਤੇ ਸਮਰਥਨ ਟਿਕਟ ਮਿਲਣਗੇ ਜੋ ਦੁਹਰਾਏ ਨਹੀਂ ਜਾ ਸਕਦੇ।
ਸ਼ੁਰੂਆਤ ਇਸ ਤੋਂ ਕਰੋ ਕਿ ਇੱਕੋ ਰਿਕਾਰਡ ਦੋ ਥਾਂ ਸੋਧਿਆ ਗਿਆ ਹੋਵੇ ਤਾਂ ਐਪ ਕੀ ਕਰੇਗੀ:
ਇਹ ਨਿਯਮ ਲਿਖੋ ਅਤੇ ਐਪ ਵਿੱਚ ਲਗਾਤਾਰ ਦੁਹਰਾਓ। “ਆਸ-ਪਰ ਨਿਰਭਰ” ਠੀਕ ਹੈ, ਜੇਕਰ ਇਹ ਰਿਕਾਰਡ ਕਿਸਮ ਦੇ ਅਨੁਸਾਰ ਪੇਸ਼ੇਵਰ ਤੌਰ 'ਤੇ ਪੇਸ਼ ਕੀਤਾ ਜਾਵੇ।
ਉੱਚ-ਮੁੱਲ ਵਾਲੇ ਡੇਟਾ (ਇੰਸਪੈਕਸ਼ਨ, ਕੰਪਲਾਇੰਸ, ਦਸਤਖਤ) ਲਈ, ਬੇ-ਦਿਮਾਗੀ ਮਰਜ ਨਾ ਕਰੋ। ਇੱਕ ਕਾਂਫਲਿਕਟ UI ਦਿਖਾਓ ਜੋ ਦੋ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦਾ:
ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਚੋਣ ਦੀ ਆਗਿਆ ਦਿਓ: ਮੇਰਾ ਰੱਖੋ, ਸਰਵਰ ਰੱਖੋ, ਜਾਂ (ਜੇ ਤੁਸੀਂ ਸਹਾਇਤਾ ਕਰਦੇ ਹੋ) ਫੀਲਡ-ਦਰ-ਫੀਲਡ ਸੁੰਮਤੀ ਕਰੋ। ਭਾਸ਼ਾ ਸਧਾਰਨ ਰੱਖੋ—ਤਕਨੀਕੀ ਟਾਈਮਸਟੈਂਪ ਸਿਰਫ਼ ਉਦਾਹਰਨ ਲਈ ਦਿਖਾਓ ਜੇ ਉਹ ਵਿਰੋਧ ਨਿਰਣਯ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ।
ਸਭ ਤੋਂ ਵਧੀਆ ਕਾਂਫਲਿਕਟ ਉਹ ਹੈ ਜੋ ਤੁਸੀਂ ਕਦੇ ਪੈਦਾ ਨਹੀਂ ਹੁੰਦਾ। ਆਮ ਰੋਕਥਾਮ ਤਕਨੀਕਾਂ ਵਿੱਚ ਹਲਕੀ ਰਿਕਾਰਡ ਲਾਕਿੰਗ, ਵਰਕ ਨਿਰਧਾਰਣ (ਕੇਵਲ ਇੱਕ ਵਿਅਕਤੀ ਨੌਕਰੀ ਚਲਾਉਂਦਾ ਹੈ), ਜਾਂ ਸੋਧ ਖਿੜਕੀਆਂ (ਸਬਮਿਟ ਤੋਂ ਬਾਅਦ ਰਿਕਾਰਡ read-only ਹੋ ਜਾਂਦੇ ਹਨ) ਸ਼ਾਮਲ ਹਨ।
ਲੋਕਲ ਤੌਰ 'ਤੇ ਸਰਵਰ ਦੇ ਸਮਾਨ ਨਿਯਮਾਂ ਨਾਲ ਡੇਟਾ ਵੈਧ ਕਰੋ (ਲਾਜ਼ਮੀ ਫੀਲਡ, ਰੇਂਜ)। ਇਸ ਨਾਲ "ਆफਲਾਈਨ ਦ੍ਵਾਰਾ ਮਨਜ਼ੂਰ, ਬਾਅਦ ਵਿੱਚ ਰਿਜੈਕਟ" ਵਾਲੀਆਂ ਆਸ਼ਚਰਜਾਂ ਘੱਟ ਹੁੰਦੀਆਂ ਹਨ।
ਸਿੰਕ ਨੂੰ ਇੱਕ ਕਾਰੋਬਾਰੀ ਪ੍ਰਕਿਰਿਆ ਵਾਂਗ ਟਰੀਟ ਕਰੋ: ਪ੍ਰਤੀ ਰਿਕਾਰਡ ਇੱਕ ਲੋਕਲ ਸਿੰਕ ਲੌਗ ਰੱਖੋ ਜਿਸ ਵਿੱਚ ਟਾਈਮਸਟੈਂਪ, ਏਰਰ ਕੋਡ, ਅਤੇ ਰੀਟਰੀ ਕਾਉਂਟ ਸ਼ਾਮਲ ਹੋਂ। ਜਦੋਂ ਇੱਕ ਉਪਭੋਗਤਾ ਆਖੇ "ਮੇਰਾ ਅੱਪਡੇਟ ਲਾਪਤਾ ਹੋ ਗਿਆ", ਤੁਸੀਂ ਟ੍ਰੇਸ ਕਰ ਸਕੋਗੇ ਕਿ ਕੀ ਇਹ ਅਪਲੋਡ ਕਰਨ ਵਿੱਚ ਨਾਕਾਮ ਰਹਿ ਗਿਆ, ਟੱਕਰ ਹੋਈ, ਜਾਂ ਸਰਵਰ ਵੈਲਿਡੇਸ਼ਨ ਵੱਲੋਂ ਰੱਦ ਕੀਤਾ ਗਿਆ।
ਫੀਲਡ ਡੇਟਾ ਕਲੇਕਸ਼ਨ ਵਿੱਚ ਅਕਸਰ ਗਾਹਕ ਵੇਰਵੇ, ਸਥਾਨ, ਫੋਟੋਆਂ, ਅਤੇ ਇੰਸਪੈਕਸ਼ਨ ਨੋਟ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ। ਜਦੋਂ ਉਹ ਡੇਟਾ ਆਫਲਾਈਨ ਵਰਤੋਂ ਲਈ ਲੋਕਲ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਫੋਨ ਤੁਹਾਡੇ ਸੁਰੱਖਿਆ ਪਰਿਸ਼ਰ ਦਾ ਹਿੱਸਾ ਬਣ ਜਾਂਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਸੰਵੇਦਨਸ਼ੀਲ ਜਾਂ ਨਿਯਮਤ ਕੀਤੀਆਂ ਜਾਣਕਾਰੀਆਂ ਇਕੱਠੀਆਂ ਕਰਦੇ ਹੋ, ਤਾਂ ਲੋਕਲ ਡੇਟਾਬੇਸ ਅਤੇ ਅਟੈਚਮੈਂਟ ਲਈ ਡਾਟਾ-ਐਟ-ਰੈਸਟ ਇਨਕ੍ਰਿਪਸ਼ਨ ਲਾਜ਼ਮੀ ਕਰੋ। iOS ਅਤੇ Android 'ਤੇ, ਇਨਕ੍ਰਿਪਸ਼ਨ ਕੀਜ਼ ਨੂੰ ਪਲੇਟਫਾਰਮ-ਬੈਕਡ ਕੀਸਟੋਰ (Keychain / Keystore) 'ਚ ਰੱਖੋ—ਸੀਕ੍ਰੇਟ ਹਾਰਡਕੋਡ ਨਾ ਕਰੋ, ਅਤੇ ਕੀਜ਼ ਨੂੰ ਸਪੇਅਰ_PREFS/ਪਲੇਨ ਟੈਕਸਟ 'ਚ ਨਾ ਰੱਖੋ।
ਇੱਕ ਕਾਰਗਰ ਪਹੁੰਚ ਇਹ ਹੈ: ਲੋਕਲ ਡੈਟਾਬੇਸ ਇਨਕ੍ਰਿਪਟ ਕਰੋ, ਵੱਡੇ ਅਟੈਚਮੈਂਟ ਅਲੱਗ ਇਨਕ੍ਰਿਪਟ ਕਰੋ, ਅਤੇ ਯੂਜ਼ਰ ਆਉਟ ਜਾਂ ਨੀਤੀ-ਨਿਰਧਾਰਨ ਅਨੁਸਾਰ ਕੀਜ਼ ਰੋਟੇਟ ਕਰੋ।
ਮਜ਼ਬੂਤ ਪ੍ਰਮਾਣਿਕਤਾ ਅਤੇ ਛੋਟੇ-ਅਵਧੀ ਵਾਲੇ ਐਕਸੈਸ ਟੋਕਨ ਵਰਤੋਂ। ਯੋਜਨਾ ਬਣਾਓ ਕਿ ਲਾਗਿਨ ਬਾਅਦ "ਆਫਲਾਈਨ" ਦਾ ਕੀ ਮਤਲਬ ਹੈ:
ਇਸ ਨਾਲ ਖੋਏ ਹੋਏ ਡਿਵਾਈਸ ਦੀ ਸਥਿਤੀ ਘਟਦੀ ਹੈ ਅਤੇ ਕੰਚਿਤ ਡੇਟਾ ਤੇ ਬੇਅੰਤ ਪਹੁੰਚ ਰੋਕੀ ਜਾਂਦੀ ਹੈ।
ਆਫਲਾਈਨ ਐਪ ਪਬਲਿਕ ਸਥਾਨਾਂ ਵਿੱਚ ਵਰਤੇ ਜਾਂ ਸਕਦੇ ਹਨ—ਗੋਦਾਮ, ਨੌਕਰੀ ਸਾਈਟ, ਲੌਬੀ—ਇਸ ਲਈ ਸਕ੍ਰੀਨ-ਸਤਰ ਰੱਖਿਆ ਮਹੱਤਵਪੂਰਨ ਹੈ।
ਆਫਲਾਈਨ ਡੇਟਾ ਸਿੰਕ ਤੋਂ ਪਹਿਲਾਂ ਸੋਧਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਚੋਰੀ-ਚੁਪੜੇ ਬਦਲਾਅ ਦੇ ਖਤਰੇ ਨੂੰ ਘਟਾਉਣ ਲਈ ਜਾਂਚ-ਯੋਗ ਬਣਾਓ:
ਇਹ ਕਦਮ ਸਾਰੇ ਖਤਰੇ ਖਤਮ ਨਹੀਂ ਕਰਨਗੇ, ਪਰ ਉਹ ਆਫਲਾਈਨ ਸਟੋਰੇਜ ਨੂੰ ਬਿਨਾਂ ਐਪ ਨੂੰ ਦਰਦਨਾਕ ਬਣਾਏਜ਼ ਲਾਗੂ ਕਰਨਯੋਗ ਬਨਾਉਂਦੇ ਹਨ।
ਫੀਲਡ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ "ਟੈਕ" ਘੱਟ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਉਹ ਇਸ ਗੱਲ ਉੱਤੇ ਜ਼ਿਆਦਾ ਧਿਆਨ ਦਿੰਦੇ ਹਨ ਕਿ ਐਪ ਉਹਨਾਂ ਨੂੰ ਕੀ ਦੱਸਦੀ ਹੈ ਅਤੇ ਉਹ ਕੰਮ ਜਾਰੀ ਰੱਖ ਸਕਦੇ ਹਨ ਜਾਂ ਨਹੀਂ। ਆਫਲਾਈਨ-ਪਹਿਲਾ ਡਿਜ਼ਾਇਨ ਇੰਜੀਨੀਅਰਿੰਗ ਵਰਗਾ ਹੀ UX ਦਾ ਭੀ ਮੁੱਦਾ ਹੈ: ਜੇ ਲੋਕ ਸਥਿਤੀ 'ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕਰਨਗੇ, ਤਾਂ ਉਹ ਆਪਣੇ ਖੁਦ ਦੇ ਕੰਮ ਕਰਨ ਦੇ ਤਰੀਕੇ ਬਣਾ ਲੈਂਦੇ ਹਨ (ਕਾਗਜ਼ ਨੋਟ, ਡੁਪਲਿਕੇਟ ਸਬਮਿਸ਼ਨ, ਸਕਰੀਨਸ਼ਾਟ)।
ਕਨੈਕਟਿਵਿਟੀ ਅਤੇ ਸਿੰਕ ਸਥਿਤੀ ਨੂੰ ਉਨ੍ਹਾਂ ਥਾਵਾਂ 'ਤੇ ਦਿਖਾਓ ਜਿੱਥੇ ਉਪਭੋਗਤਾ ਤਬ ਸਧਾਰਨ ਤੌਰ 'ਤੇ ਵੇਖਦੇ ਹਨ—ਬਿਨਾਂ ਜ਼ਿਆਦਾ ਸ਼ੋਰ-ਸ਼ਰਾਬੇ ਦੇ।
ਇੱਕ ਸਾਦਾ ਸਥਿਤੀ ਸੂਚਕ ਵਰਤੋ (ਉਦਾਹਰਨ: Offline / Syncing / Up to date) ਅਤੇ ਹਮੇਸ਼ਾ "Last synced" ਟਾਈਮਸਟੈਂਪ ਦਿਖਾਓ। ਜਦੋਂ ਕੋਈ ਗਲਤ ਹੋਵੇ, ਇੱਕ ਏਰਰ ਬੈਨਰ ਦਿਖਾਓ ਜੋ ਉਪਭੋਗਤਾ ਮੁਆਫੀ ਨਾ ਕਰਨ ਤੱਕ ਜਾਂ ਮੁੱਦਾ ਹੱਲ ਹੋਣ ਤੱਕ ਰਹੇ।
ਚੰਗੇ ਆਫਲਾਈਨ ਇਨਡਿਕੇਟਰ ਉਪਭੋਗਤਾਵਾਂ ਦੀ ਸਹਾਇਤਾ ਕਰਦੇ ਹਨ ਇਹ ਜਾਣਨ ਵਿੱਚ:
ਸਭ ਤੋਂ ਵਧੀਆ ਮੋਬਾਈਲ ਆਫਲਾਈਨ ਸਿੰਕ ਕਦੇ-ਕਦੇ ਫਸ ਜਾ ਸਕਦਾ ਹੈ ਨੈੱਟਵਰਕ, OS ਬੈਕਗ੍ਰਾਊਂਡ ਸੀਮਾਵਾਂ, ਜਾਂ ਸਰਵਰ ਸਮੱਸਿਆਵਾਂ ਕਾਰਨ। ਉਹ ਕੰਟਰੋਲ ਦਿਓ ਜੋ ਅਸਲ ਫੀਲਡ ਵਰਕਫਲੋਜ਼ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹਨ:
ਜੇ ਤੁਹਾਡਾ ਆਫਲਾਈਨ ਡੇਟਾ ਕਲੇਕਸ਼ਨ ਐਪ ਬੈਕਗ੍ਰਾਊਂਡ ਸਿੰਕ ਨੂੰ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਪਾਰਦਰਸ਼ੀ ਬਣਾਓ: ਕਤਾਰ ਗਿਣਤੀ ਦਿਖਾਓ (ਉਦਾਹਰਨ: “3 ਆਈਟਮ ਉਡੀਕ ਕਰ ਰਹੇ ਹਨ”) ਤਾਂ ਕਿ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਅਨੁਮਾਨ ਨਹੀਂ ਲਗਣਾ ਚਾਹੀਦਾ।
"Sync failed" ਵਰਗੇ ਅਸਪਸ਼ਟ ਏਰਰਾਂ ਤੋਂ ਬਚੋ। ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਰਤੋਂ ਜੋ ਦੱਸੇ ਕੀ ਹੋਇਆ ਅਤੇ ਕੀ ਕਰਨਾ ਹੈ।
ਉਦਾਹਰਨ:
ਸੁਨੇਹਿਆਂ ਨੂੰ ਅੱਗੇ ਦੇ ਇੱਕ ਕਾਰਵਾਈ ਬਟਨ ਨਾਲ ਜੋੜੋ (“Try again,” “Open settings,” “Contact support”) ਤਾਂ ਕਿ ਉਪਭੋਗਤਾ ਤੇਜ਼ੀ ਨਾਲ ਮੁੜ ਪ੍ਰਾਪਤੀ ਕਰ ਸਕੇ।
ਫੀਲਡ ਡੇਟਾ ਕਲੇਕਸ਼ਨ ਅਕਸਰ ਪੁਰਾਣੇ ਫੋਨ ਤੇ ਹੁੰਦੀ ਹੈ ਜਿਨ੍ਹਾਂ ਕੋਲ ਸੀਮਤ ਸਟੋਰੇਜ ਅਤੇ ਅਣਨਿਯਤ ਚਾਰਜਿੰਗ ਹੁੰਦੀ ਹੈ। ਭਰੋਸੇਯੋਗਤਾ ਲਈ ਅਨੁਕੂਲਤਾ:
ਜਦੋਂ ਐਪ ਘੱਟ ਕਨੈਕਟਿਵਿਟੀ ਹਾਲਤਾਂ ਹੇਠ ਭਰੋਸੇਯੋਗ ਹੋਵੇ, ਉਪਭੋਗਤਾ ਤੇਜ਼ੀ ਨਾਲ ਇਸ 'ਤੇ ਭਰੋਸਾ ਕਰ ਲੈਣਗੇ—ਅਤੇ ਅਪਣਾਉਣ ਆਸਾਨ ਹੋ ਜਾਵੇਗਾ।
ਆਫਲਾਈਨ ਫੀਲਡ ਐਪ ਲੈਬ ਵਿੱਚ ਨਹੀਂ, ਸਥਿਰ ਸੜਕ ਤੇ ਨਾਕਾਮ ਹੁੰਦੇ ਹਨ—ਉਹ ਘੁੱਟੇ ਹੋਏ ਸਿਗਨਲ ਅਤੇ 2% ਬੈਟਰੀ ਵਾਲੇ ਹਵਾਈ ਮਾਰਗ 'ਤੇ ਨਾਕਾਮ ਹੁੰਦੇ ਹਨ। ਟੈਸਟਿੰਗ ਨੂੰ ਉਸ ਹਕੀਕਤ ਦਾ ਅਨੁਕਰਣ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਖਾਸ ਕਰਕੇ ਮੋਬਾਈਲ ਆਫਲਾਈਨ ਸਿੰਕ, ਅਟੈਚਮੈਂਟ, ਅਤੇ GPS ਡੇਟਾ ਕੈਪਚਰ ਦੇ ਆਲੇ-ਦੁਆਲੇ।
“ਨੋ ਇੰਟਰਨੈਟ” ਤੋਂ ਇਲਾਵਾ ਹੋਰ ਹਾਲਤਾਂ ਨੂੰ ਕਵਰ ਕਰੋ। ਇੱਕ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਟੈਸਟ ਚੈੱਕਲਿਸਟ ਬਣਾਓ ਜਿਸ ਵਿੱਚ ਸ਼ਾਮਲ ਹੈ:
ਸੰਭਾਲੋ ਕਿ ਉਪਭੋਗਤਾ ਕੰਮ ਜਾਰੀ ਰੱਖ ਸਕਦਾ ਹੈ, ਲੋਕਲ ਡੈਟਾਬੇਸ ਸਥਿਰ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ UI ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਕੀ ਲੋਕਲ ਸੇਵ ਹੈ ਅਤੇ ਕੀ ਸਿੰਕ ਹੋਇਆ ਹੈ।
ਸਿੰਕ ਬੱਗ ਅਕਸਰ ਕੇਵਲ ਪੁਰਾਣੀਆਂ ਰੀਟਰੀਜ਼ ਦੇ ਬਾਅਦ ਨਜ਼ਰ ਆਉਂਦੇ ਹਨ। ਆਟੋਮੇਟੇਡ ਟੈਸਟ (ਯੂਨਿਟ + ਇੰਟੀਗ੍ਰੇਸ਼ਨ) ਸ਼ਾਮਲ ਕਰੋ ਜੋ ਵੈਰੀਫਾਈ ਕਰਦੇ ਹਨ:
ਜੇ ਸੰਭਵ ਹੋਵੇ, ਇਹ ਟੈਸਟ ਇੱਕ ਸਟੇਜਿੰਗ ਸਰਵਰ 'ਤੇ ਚਲਾਓ ਜੋ ਫਾਲਟ (ਟਾਈਮਆਊਟ, 500s, ਅਤੇ ਧੀਮੇ ਰਿਸਪਾਂਸ) ਦਾ ਇੰਜੈਕਸ਼ਨ ਕਰਦਾ ਹੋਵੇ।
“ਕਈ ਦਿਨਾਂ ਆਫਲਾਈਨ” ਅਤੇ “ਸਭ ਕੁਝ ਇੱਕ ਵਾਰੀ sync ਹੁੰਦਾ” ਦੇ ਲਈ ਯੋਜਨਾ ਬਣਾਓ। ਹਜ਼ਾਰਾਂ ਰਿਕਾਰਡ, ਬਹੁਤ ਸਾਰੇ ਅਟੈਚਮੈਂਟ, ਅਤੇ ਪੁਰਾਣੀਆਂ ਆਈਟਮਾਂ 'ਤੇ ਸੋਧਾਂ ਨਾਲ ਸਟ੍ਰੈੱਸ ਟੈਸਟ ਕਰੋ। ਨੀਵਾਂ-ਅੰਤ ਫੋਨ 'ਤੇ ਬੈਟਰੀ ਡਰੇਨ, ਡਿਵਾਈਸ ਸਟੋਰੇਜ ਵਾਧਾ, ਅਤੇ ਸਿੰਕ ਸਮਾਂ ਮਾਪੋ।
ਛੋਟੇ ਫੀਲਡ ਪਾਇਲਟ ਕਰੋ ਅਤੇ ਤੁਰੰਤ ਫੀਡਬੈਕ ਲਓ: ਕਿਹੜੇ ਮੋਬਾਈਲ ਫਾਰਮ ਗੁੰਝਲਦਾਰ ਹਨ, ਕਿੱਥੇ ਵੈਧਤਾ ਕੰਮ ਰੋਕਦੀ ਹੈ, ਅਤੇ ਕਿਹੜੀਆਂ ਚੀਜ਼ਾਂ ਸਿੰਕ ਨੂੰ ਧੀਮਾ ਮਹਿਸੂਸ ਕਰਾਉਂਦੀਆਂ ਹਨ। ਬ੍ਰਾਡ ਰੋਲਆਉਟ ਤੋਂ ਪਹਿਲਾਂ ਫਾਰਮ ਫਲੋ ਅਤੇ ਕਾਂਫਲਿਕਟ ਰੈਜ਼ੋਲਿਊਸ਼ਨ ਨਿਯਮਾਂ 'ਤੇ ਦੁਹਰਾਈ ਕਰੋ।
ਆਫਲਾਈਨ ਫੀਲਡ ਐਪ ਲਾਂਚ ਇੱਕ ਐਂਡਪੌਇੰਟ ਨਹੀਂ—ਇਹ ਉਹ ਸਮਾਂ ਹੈ ਜਦੋਂ ਅਸਲ कਨੈਕਟਿਵਿਟੀ, ਡਿਵਾਈਸ, ਅਤੇ ਉਪਭੋਗਤਾ-વ્યવહાર ਨਮੂਨੇ ਸਾਹਮਣੇ ਆਉਂਦੇ ਹਨ। ਪਹਿਲੀਆਂ ਰਿਲੀਜ਼ਾਂ ਨੂੰ ਇੱਕ ਸਿੱਖਣੀ ਪਰਿਯੋਜਨਾ ਸਮਝੋ, ਸਾਫ਼ ਮੈਟ੍ਰਿਕਸ ਅਤੇ ਤੇਜ਼ ਫੀਡਬੈਕ ਲੂਪ ਨਾਲ।
ਹੁਨਰਮੰਦ ਟੈਲੀਮੇਟਰੀ ਸ਼ਾਮਲ ਕਰੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਜਲਦੀ ਮੁੱਢਲੇ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦੇ ਸਕੋ:
ਜਿਵੇ ਸੰਭਵ ਹੋਵੇ, ਸਿੰਕ ਕਿਉਂ ਫੇਲ ਹੋਇਆ (auth expired, payload too large, server validation, network timeout) ਨੂੰ ਸੈਂਸੇਟਿਵ ਫੀਲਡ ਡੇਟਾ ਲਾਗ ਨਾ ਕਰਦੇ ਹੋਏ ਰਿਕਾਰਡ ਕਰੋ।
ਆਫਲਾਈਨ ਐਪ ਪੂਰਵ-ਨਿਰਧਾਰਤ ਤਰੀਕੇ ਨਾਲ ਨਾਕਾਮ ਹੁੰਦੇ ਹਨ। ਇੱਕ ਸਧਾਰਨ ਅੰਦਰੂਨੀ ਰਨਬੁੱਕ ਲਿਖੋ ਜੋ ਨਿਰਧਾਰਿਤ ਤਰੀਕਿਆਂ ਨਾਲ ਨਿਰਧਾਰਨ ਕਰੇ:
ਇਹ ਪਲੇਬੁੱਕ ਗੈਰ-ਇੰਜੀਨੀਅਰ (ਸਪੋਰਟ ਅਤੇ ਆਪਸ) ਲਈ ਵਰਤਣਯੋਗ ਬਣਾਓ, ਅਤੇ ਉਪਭੋਗਤਾ ਨੂੰ ਕੀ ਕਰਨ ਲਈ ਕਹਿਣਾ ਹੈ (ਉਦਾਹਰਨ: ਐਪ ਨੂੰ Wi‑Fi 'ਤੇ ਖੋਲ੍ਹੋ, 2 ਮਿੰਟ ਲਈ ਫੋਰਗਰਾਉਂਡ ਵਿੱਚ ਰੱਖੋ, ਇੱਕ ਡਾਇਗਨੋਸਟਿਕ ਲੌਗ ID ਕੈਪਚਰ ਕਰੋ)।
ਆਫਲਾਈਨ-ਪਹਿਲਾ ਐਪਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਅੱਪਗਰੇਡਸ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਆਪਣੀ ਲੋਕਲ ਡੈਟਾਬੇਸ ਸਕੀਮਾ ਨੂੰ ਵਰਜ਼ਨ ਕਰੋ ਅਤੇ ਟੈਸਟ ਕੀਤੀਆਂ ਮਾਈਗ੍ਰੇਸ਼ਨਾਂ ਸ਼ਾਮਲ ਕਰੋ (ਕਾਲਮ ਜੋੜੋ, ਡਿਫੌਲਟ ਭਰੋ, ਰੀ-ਇੰਡੈਕਸ)। ਆਪਣੀ API ਵਾਰਤਾ ਨੂੰ ਵੀ ਵਰਜ਼ਨ ਕਰੋ ਤਾਂ ਕਿ ਪੁਰਾਣੀਆਂ ਐਪ ਵਰਜ਼ਨ ਗ੍ਰੇਸਫੁੱਲੀ ਡਿਗਰੇਡ ਕਰਨ, ਬਜਾਏ ਕਿ ਖ਼ਾਮੋਸ਼ੀ ਨਾਲ ਫੀਲਡਾਂ ਨੂੰ ਛੱਡ ਦੇਣ।
ਫੀਲਡ ਟੀਮਾਂ ਲਈ ਛੋਟੇ ਟ੍ਰੇਨਿੰਗ ਗਾਈਡ ਬਣਾਓ: ਡੇਟਾ ਸੇਵ ਹੋਣ ਦੀ ਪੁਸ਼ਟੀ ਕਿਵੇਂ ਕਰਨੀ ਹੈ, “pending upload” ਕਿਵੇਂ ਦੇਖਣਾ ਹੈ, ਅਤੇ ਕਦੋਂ retry ਕਰਨਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਆਫਲਾਈਨ-ਪਹਿਲਾ ਰੋਲਆਉਟ ਬਾਰੇ ਸਮਗਰੀ ਜਾਂ ਅੰਦਰੂਨੀ ਏਨੇਬਲਮਨਟ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਇਸਨੂੰ ਪ੍ਰੋਤਸਾਹਿਤ ਕਰਨ ਦੇ ਤਰੀਕੇ ਸੋਚੋ। ਉਦਾਹਰਨ ਲਈ, Koder.ai ਇੱਕ “earn credits” ਪ੍ਰੋਗਰਾਮ ਦਿੰਦਾ ਹੈ ਜਿਹੜਾ ਪਲੇਟਫਾਰਮ ਬਾਰੇ ਸਮਗਰੀ ਬਣਾਉਣ ਲਈ ਅਤੇ ਇੱਕ referral ਪ੍ਰੋਗਰਾਮ—ਦੋਹਾਂ ਉਹ ਟੀਮਾਂ ਲਈ ਲਾਭਕਾਰੀ ਹੋ ਸਕਦੇ ਹਨ ਜੋ ਨਿਰਮਾਣ ਪਹੁੰਚਾਂ ਦਸਤਾਵੇਜ਼ ਕਰ ਰਹੀਆਂ ਹਨ ਅਤੇ ਅਪਣਾ ਲਈ ਉਤਸ਼ਾਹ ਪੈਦਾ ਕਰ ਰਹੀਆਂ ਹਨ।
If you need help scoping rollout or support, point stakeholders to /pricing or /contact.
Start by writing down operational targets:
These numbers directly determine local storage needs, database performance, and whether sync must be incremental, batched, or Wi‑Fi only.
Capture:
Turn this into testable requirements like “create a full inspection in airplane mode” and “finish a job without any spinners.”
Most teams start with the smallest loop that keeps work moving:
Defer heavy features (offline dashboards, global search across everything, complex approvals) until core capture + sync is reliable.
Use simple rules that reduce risk:
Make the rule visible in the UI (e.g., “Draft saved. Sync required to submit”).
Pick a local database that supports:
Common choices:
Model “work in progress,” not just final server records:
Treat attachments as separate jobs:
Don’t block form completion on immediate file upload; let the record sync and attachments catch up when connectivity returns.
Use an outbox pattern:
Combine triggers (background when open + a manual “Sync now” button) and handle big backlogs with batching, pagination, and retry/backoff.
Pick and document conflict rules by record type:
For high-value records (inspections, signatures), show a conflict screen that compares local vs server and lets users choose what to keep.
Focus on device risk and auditability:
If you need help scoping security tradeoffs or rollout support, route stakeholders to /contact or /pricing.
Choose based on your team’s platform and your need for predictable performance on older devices.
created_atupdated_atdevice_iduser_idversionThis makes offline edits, deletions, and retries predictable after app restarts.