UI-ਕਿੱਟ ਤੋਂ ਡਿਜ਼ਾਈਨ ਸਿਸਟਮ ਤੱਕ

ਆਈਵੀ ਆਨਲਾਈਨ ਸਿਨੇਮਾ ਅਨੁਭਵ

ਜਦੋਂ 2017 ਦੀ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਅਸੀਂ ਪਹਿਲੀ ਵਾਰ ਆਪਣਾ ਡਿਜ਼ਾਇਨ-ਟੂ-ਕੋਡ ਡਿਲੀਵਰੀ ਸਿਸਟਮ ਬਣਾਉਣ ਬਾਰੇ ਸੋਚਿਆ, ਬਹੁਤ ਸਾਰੇ ਪਹਿਲਾਂ ਹੀ ਇਸ ਬਾਰੇ ਗੱਲ ਕਰ ਰਹੇ ਸਨ ਅਤੇ ਕੁਝ ਇਸਨੂੰ ਕਰ ਵੀ ਰਹੇ ਸਨ। ਹਾਲਾਂਕਿ, ਅੱਜ ਤੱਕ ਕ੍ਰਾਸ-ਪਲੇਟਫਾਰਮ ਡਿਜ਼ਾਈਨ ਪ੍ਰਣਾਲੀਆਂ ਦੇ ਨਿਰਮਾਣ ਦੇ ਤਜ਼ਰਬੇ ਬਾਰੇ ਬਹੁਤ ਘੱਟ ਜਾਣਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਪਹਿਲਾਂ ਹੀ ਕੰਮ ਕਰਨ ਵਾਲੇ ਉਤਪਾਦ ਵਿੱਚ ਡਿਜ਼ਾਈਨ ਲਾਗੂ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਦੇ ਅਜਿਹੇ ਪਰਿਵਰਤਨ ਲਈ ਤਕਨਾਲੋਜੀਆਂ ਅਤੇ ਤਰੀਕਿਆਂ ਦਾ ਵਰਣਨ ਕਰਨ ਵਾਲੀਆਂ ਕੋਈ ਸਪੱਸ਼ਟ ਅਤੇ ਸਾਬਤ ਪਕਵਾਨਾਂ ਨਹੀਂ ਹਨ। ਅਤੇ "ਕੋਡ ਵਿੱਚ ਭਾਗ" ਦੁਆਰਾ ਉਹਨਾਂ ਦਾ ਅਕਸਰ ਬਹੁਤ ਵੱਖਰੀਆਂ ਚੀਜ਼ਾਂ ਦਾ ਮਤਲਬ ਹੁੰਦਾ ਹੈ।

ਇਸ ਦੌਰਾਨ, ਕੰਪਨੀ ਨੇ ਸਾਲ ਦਰ ਸਾਲ ਆਪਣੇ ਸਟਾਫ ਨੂੰ ਦੁੱਗਣਾ ਕਰ ਦਿੱਤਾ - ਡਿਜ਼ਾਇਨ ਵਿਭਾਗ ਨੂੰ ਸਕੇਲ ਕਰਨਾ ਅਤੇ ਵਿਕਾਸ ਲਈ ਲੇਆਉਟ ਬਣਾਉਣ ਅਤੇ ਟ੍ਰਾਂਸਫਰ ਕਰਨ ਦੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣਾ ਜ਼ਰੂਰੀ ਸੀ। ਅਸੀਂ ਇਸ ਸਭ ਨੂੰ ਪਲੇਟਫਾਰਮਾਂ ਦੇ "ਚਿੜੀਆਘਰ" ਦੁਆਰਾ ਗੁਣਾ ਕਰਦੇ ਹਾਂ ਜਿਨ੍ਹਾਂ ਨੂੰ ਸਮਰਥਨ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਸਾਨੂੰ ਬੇਬੀਲੋਨੀਅਨ ਪੈਂਡੇਮੋਨਿਅਮ ਦੀ ਝਲਕ ਮਿਲਦੀ ਹੈ, ਜੋ ਕਿ "ਇਸ ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਕਰਨ" ਅਤੇ ਆਮਦਨ ਪੈਦਾ ਕਰਨ ਦੇ ਯੋਗ ਨਹੀਂ ਹੈ। ਪਲੇਟਫਾਰਮਾਂ ਦਾ ਵਿਕਾਸ ਅਕਸਰ ਸਮਾਨਾਂਤਰ ਤੌਰ 'ਤੇ ਅੱਗੇ ਵਧਦਾ ਹੈ, ਅਤੇ ਉਹੀ ਕਾਰਜਕੁਸ਼ਲਤਾ ਕਈ ਮਹੀਨਿਆਂ ਦੇ ਪਛੜ ਨਾਲ ਵੱਖ-ਵੱਖ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ ਜਾਰੀ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ।


ਹਰੇਕ ਪਲੇਟਫਾਰਮ ਲਈ ਵੱਖਰਾ ਖਾਕਾ ਸੈੱਟ

ਪਰੰਪਰਾਗਤ ਤੌਰ 'ਤੇ, ਅਸੀਂ ਉਹਨਾਂ ਸਮੱਸਿਆਵਾਂ ਨਾਲ ਸ਼ੁਰੂਆਤ ਕੀਤੀ ਸੀ ਜੋ ਇੱਕ ਡਿਜ਼ਾਇਨ ਸਿਸਟਮ ਨੂੰ ਹੱਲ ਕਰਨ ਅਤੇ ਇਸਦੇ ਡਿਜ਼ਾਈਨ ਲਈ ਲੋੜਾਂ ਨੂੰ ਤਿਆਰ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰੇਗੀ। ਇੱਕ ਯੂਨੀਫਾਈਡ ਵਿਜ਼ੂਅਲ ਭਾਸ਼ਾ ਬਣਾਉਣ ਤੋਂ ਇਲਾਵਾ, ਲੇਆਉਟ ਅਤੇ ਵਿਕਾਸ ਦੀ ਗਤੀ ਨੂੰ ਵਧਾਉਣਾ, ਅਤੇ ਸਮੁੱਚੇ ਉਤਪਾਦ ਦੀ ਗੁਣਵੱਤਾ ਵਿੱਚ ਸੁਧਾਰ ਕਰਨਾ, ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਡਿਜ਼ਾਇਨ ਨੂੰ ਏਕੀਕ੍ਰਿਤ ਕਰਨਾ ਬਹੁਤ ਜ਼ਰੂਰੀ ਸੀ। ਇਹ ਜ਼ਰੂਰੀ ਹੈ ਤਾਂ ਜੋ ਸਾਡੇ ਸਾਰੇ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ ਇੱਕੋ ਸਮੇਂ ਕਾਰਜਸ਼ੀਲਤਾ ਦਾ ਵਿਕਾਸ ਸੰਭਵ ਹੋ ਸਕੇ: ਵੈੱਬ, ਆਈਓਐਸ, ਐਂਡਰੌਇਡ, ਸਮਾਰਟ ਟੀਵੀ, ਟੀਵੀਓਐਸ, ਐਂਡਰੌਇਡ ਟੀਵੀ, ਵਿੰਡੋਜ਼ 10, ਐਕਸਬਾਕਸ ਵਨ, ਪੀਐਸ4, ਰੋਕੂ - ਉਹਨਾਂ ਵਿੱਚੋਂ ਹਰੇਕ 'ਤੇ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਕੰਮ ਕੀਤੇ ਬਿਨਾਂ। ਅਤੇ ਅਸੀਂ ਇਹ ਕੀਤਾ!

ਡਿਜ਼ਾਈਨ → ਡਾਟਾ

ਜਦੋਂ ਉਤਪਾਦ ਅਤੇ ਵਿਕਾਸ ਵਿਭਾਗਾਂ ਵਿਚਕਾਰ ਬੁਨਿਆਦੀ ਸਮਝੌਤਿਆਂ 'ਤੇ ਪਹੁੰਚ ਗਏ, ਅਸੀਂ ਇੱਕ ਤਕਨਾਲੋਜੀ ਸਟੈਕ ਦੀ ਚੋਣ ਕਰਨ ਲਈ ਬੈਠ ਗਏ ਅਤੇ ਸਾਰੀ ਪ੍ਰਕਿਰਿਆ ਦੇ ਵੇਰਵਿਆਂ 'ਤੇ ਕੰਮ ਕੀਤਾ - ਲੇਆਉਟ ਤੋਂ ਰਿਲੀਜ਼ ਤੱਕ। ਡਿਜ਼ਾਇਨ ਨੂੰ ਵਿਕਾਸ ਵਿੱਚ ਤਬਦੀਲ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਵੈਚਲਿਤ ਕਰਨ ਲਈ, ਅਸੀਂ ਲੇਆਉਟ ਦੇ ਨਾਲ ਸਕੈਚ ਫਾਈਲਾਂ ਤੋਂ ਕੰਪੋਨੈਂਟ ਪੈਰਾਮੀਟਰਾਂ ਨੂੰ ਪਾਰਸ ਕਰਨ ਦੇ ਵਿਕਲਪ ਦੀ ਖੋਜ ਕੀਤੀ। ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ ਸਾਨੂੰ ਲੋੜੀਂਦੇ ਕੋਡ ਦੇ ਟੁਕੜਿਆਂ ਨੂੰ ਲੱਭਣਾ ਅਤੇ ਲੋੜੀਂਦੇ ਮਾਪਦੰਡਾਂ ਨੂੰ ਕੱਢਣਾ ਇੱਕ ਗੁੰਝਲਦਾਰ ਅਤੇ ਖਤਰਨਾਕ ਕੰਮ ਸੀ। ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਡਿਜ਼ਾਇਨਰਜ਼ ਨੂੰ ਸਰੋਤ ਕੋਡ ਦੀਆਂ ਸਾਰੀਆਂ ਪਰਤਾਂ ਦਾ ਨਾਮ ਦੇਣ ਵਿੱਚ ਬਹੁਤ ਧਿਆਨ ਰੱਖਣਾ ਹੋਵੇਗਾ, ਦੂਜਾ, ਇਹ ਸਿਰਫ ਸਰਲ ਭਾਗਾਂ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ, ਅਤੇ ਤੀਜਾ, ਕਿਸੇ ਹੋਰ ਦੀ ਤਕਨਾਲੋਜੀ ਅਤੇ ਮੂਲ ਸਕੈਚ ਲੇਆਉਟ ਦੇ ਕੋਡ ਢਾਂਚੇ 'ਤੇ ਨਿਰਭਰਤਾ ਸਮੁੱਚੇ ਦੇ ਭਵਿੱਖ ਨੂੰ ਖ਼ਤਰੇ ਵਿੱਚ ਪਾਉਂਦੀ ਹੈ। ਪ੍ਰੋਜੈਕਟ. ਅਸੀਂ ਇਸ ਖੇਤਰ ਵਿੱਚ ਆਟੋਮੇਸ਼ਨ ਨੂੰ ਛੱਡਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ। ਇਸ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਇਨ ਸਿਸਟਮ ਟੀਮ ਵਿੱਚ ਪਹਿਲਾ ਵਿਅਕਤੀ ਪ੍ਰਗਟ ਹੋਇਆ, ਜਿਸਦਾ ਇਨਪੁਟ ਡਿਜ਼ਾਇਨ ਲੇਆਉਟ ਹੈ, ਅਤੇ ਆਉਟਪੁੱਟ ਭਾਗਾਂ ਦੇ ਸਾਰੇ ਮਾਪਦੰਡਾਂ ਦਾ ਵਰਣਨ ਕਰਨ ਵਾਲਾ ਡੇਟਾ ਹੈ ਅਤੇ ਪਰਮਾਣੂ ਡਿਜ਼ਾਈਨ ਵਿਧੀ ਦੇ ਅਨੁਸਾਰ ਲੜੀਵਾਰ ਕ੍ਰਮਬੱਧ ਕੀਤਾ ਗਿਆ ਹੈ।

ਸਿਰਫ਼ ਇਹ ਕਰਨਾ ਬਾਕੀ ਸੀ ਕਿ ਡੇਟਾ ਨੂੰ ਕਿੱਥੇ ਅਤੇ ਕਿਵੇਂ ਸਟੋਰ ਕਰਨਾ ਹੈ, ਇਸਨੂੰ ਵਿਕਾਸ ਵਿੱਚ ਕਿਵੇਂ ਟ੍ਰਾਂਸਫਰ ਕਰਨਾ ਹੈ ਅਤੇ ਸਾਡੇ ਦੁਆਰਾ ਸਮਰਥਨ ਕੀਤੇ ਸਾਰੇ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ ਵਿਕਾਸ ਵਿੱਚ ਇਸਦੀ ਵਿਆਖਿਆ ਕਿਵੇਂ ਕਰਨੀ ਹੈ। ਸ਼ਾਮ ਢਲਣੀ ਬੰਦ ਹੋ ਗਈ... ਹਰੇਕ ਪਲੇਟਫਾਰਮ ਤੋਂ ਡਿਜ਼ਾਈਨਰਾਂ ਅਤੇ ਟੀਮ ਦੀ ਅਗਵਾਈ ਵਾਲੇ ਕਾਰਜ ਸਮੂਹ ਦੀਆਂ ਨਿਯਮਤ ਮੀਟਿੰਗਾਂ ਦਾ ਨਤੀਜਾ ਹੇਠ ਲਿਖੇ 'ਤੇ ਸਮਝੌਤਾ ਸੀ।

ਅਸੀਂ ਵਿਜ਼ੂਅਲ ਨੂੰ ਪਰਮਾਣੂ ਤੱਤਾਂ ਵਿੱਚ ਹੱਥੀਂ ਪਾਰਸ ਕਰਦੇ ਹਾਂ: ਐਨੀਮੇਸ਼ਨਾਂ ਲਈ ਫੌਂਟ, ਰੰਗ, ਪਾਰਦਰਸ਼ਤਾ, ਇੰਡੈਂਟ, ਰਾਊਂਡਿੰਗ, ਆਈਕਨ, ਤਸਵੀਰਾਂ ਅਤੇ ਮਿਆਦ। ਅਤੇ ਅਸੀਂ ਇਸ ਬਟਨਾਂ, ਇਨਪੁਟਸ, ਚੈਕਬਾਕਸਾਂ, ਬੈਂਕ ਕਾਰਡ ਵਿਜੇਟਸ ਆਦਿ ਤੋਂ ਇਕੱਤਰ ਕਰਦੇ ਹਾਂ। ਅਸੀਂ ਆਈਕਾਨਾਂ ਨੂੰ ਛੱਡ ਕੇ, ਕਿਸੇ ਵੀ ਪੱਧਰ ਦੀਆਂ ਸ਼ੈਲੀਆਂ ਲਈ ਗੈਰ-ਅਰਥਿਕ ਨਾਮ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਾਂ, ਉਦਾਹਰਨ ਲਈ, ਸ਼ਹਿਰਾਂ ਦੇ ਨਾਮ, ਨਿੰਫਸ ਦੇ ਨਾਮ, ਪੋਕੇਮੋਨ, ਕਾਰ ਬ੍ਰਾਂਡਸ... ਇੱਥੇ ਸਿਰਫ ਇੱਕ ਸ਼ਰਤ ਹੈ - ਸੂਚੀ ਪਹਿਲਾਂ ਖਤਮ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ, ਸ਼ੈਲੀ ਕਿਵੇਂ ਖਤਮ ਹੁੰਦੀ ਹੈ - ਸ਼ੋਅ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ! ਤੁਹਾਨੂੰ ਅਰਥ ਵਿਗਿਆਨ ਨਾਲ ਦੂਰ ਨਹੀਂ ਜਾਣਾ ਚਾਹੀਦਾ, ਤਾਂ ਜੋ ਤੁਹਾਨੂੰ "ਛੋਟੇ" ਅਤੇ "ਮੱਧਮ" ਦੇ ਵਿਚਕਾਰ ਇੱਕ ਮੱਧ ਬਟਨ ਜੋੜਨਾ ਨਾ ਪਵੇ, ਉਦਾਹਰਣ ਵਜੋਂ।

ਵਿਜ਼ੂਅਲ ਭਾਸ਼ਾ

ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਇਸ ਬਾਰੇ ਸੋਚਣ ਲਈ ਛੱਡ ਦਿੱਤਾ ਗਿਆ ਸੀ ਕਿ ਸਾਰੇ ਪਲੇਟਫਾਰਮਾਂ ਦੇ ਅਨੁਕੂਲ ਹੋਣ ਵਾਲੇ ਤਰੀਕੇ ਨਾਲ ਡੇਟਾ ਨੂੰ ਕਿਵੇਂ ਸਟੋਰ ਕਰਨਾ ਅਤੇ ਟ੍ਰਾਂਸਫਰ ਕਰਨਾ ਹੈ, ਅਤੇ ਡਿਜ਼ਾਈਨ ਨੂੰ ਇੰਟਰਫੇਸ ਐਲੀਮੈਂਟਸ ਡਿਜ਼ਾਇਨ ਕਰਨੇ ਪੈਂਦੇ ਹਨ ਜੋ ਵਧੀਆ ਦਿਖਾਈ ਦੇ ਸਕਦੇ ਹਨ ਅਤੇ ਸਮਰਥਿਤ ਡਿਵਾਈਸਾਂ ਦੇ ਪੂਰੇ ਫਲੀਟ ਵਿੱਚ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰ ਸਕਦੇ ਹਨ।

ਪਹਿਲਾਂ, ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਵਿੰਡੋਜ਼ 10 ਲਈ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਜ਼ਿਆਦਾਤਰ ਡਿਜ਼ਾਈਨ ਤੱਤਾਂ ਦੀ "ਟੈਸਟ" ਕਰਨ ਵਿੱਚ ਕਾਮਯਾਬ ਹੋ ਗਏ ਸੀ, ਜੋ ਕਿ ਉਸ ਸਮੇਂ ਸਾਡੇ ਲਈ ਇੱਕ ਨਵਾਂ ਪਲੇਟਫਾਰਮ ਸੀ, ਯਾਨੀ ਇਸਨੂੰ "ਸ਼ੁਰੂ ਤੋਂ" ਪੇਸ਼ਕਾਰੀ ਅਤੇ ਵਿਕਾਸ ਦੀ ਲੋੜ ਸੀ। ਇਸਨੂੰ ਡਰਾਇੰਗ ਕਰਕੇ, ਅਸੀਂ ਜ਼ਿਆਦਾਤਰ ਭਾਗਾਂ ਨੂੰ ਤਿਆਰ ਕਰਨ ਅਤੇ ਉਹਨਾਂ ਦੀ ਜਾਂਚ ਕਰਨ ਦੇ ਯੋਗ ਹੋ ਗਏ ਅਤੇ ਇਹ ਸਮਝਣ ਦੇ ਯੋਗ ਹੋ ਗਏ ਕਿ ਉਹਨਾਂ ਵਿੱਚੋਂ ਕਿਸ ਨੂੰ ਭਵਿੱਖ ਦੀ Eevee ਡਿਜ਼ਾਈਨ ਪ੍ਰਣਾਲੀ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਅਜਿਹੇ ਸੈਂਡਬੌਕਸ ਤੋਂ ਬਿਨਾਂ, ਅਜਿਹਾ ਅਨੁਭਵ ਪਹਿਲਾਂ ਤੋਂ ਹੀ ਕੰਮ ਕਰਨ ਵਾਲੇ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਦੁਹਰਾਓ ਦੁਆਰਾ ਪ੍ਰਾਪਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਸ ਵਿੱਚ ਇੱਕ ਸਾਲ ਤੋਂ ਵੱਧ ਸਮਾਂ ਲੱਗੇਗਾ।

ਵੱਖ-ਵੱਖ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ ਇੱਕੋ ਜਿਹੇ ਭਾਗਾਂ ਦੀ ਮੁੜ ਵਰਤੋਂ ਕਰਨ ਨਾਲ ਲੇਆਉਟ ਦੀ ਗਿਣਤੀ ਅਤੇ ਡਿਜ਼ਾਇਨ ਸਿਸਟਮ ਦੇ ਡੇਟਾ ਦੀ ਲੜੀ ਨੂੰ ਮਹੱਤਵਪੂਰਣ ਰੂਪ ਵਿੱਚ ਘਟਾਉਂਦਾ ਹੈ, ਇਸ ਲਈ ਡਿਜ਼ਾਈਨ ਨੂੰ ਇੱਕ ਹੋਰ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨਾ ਪਿਆ, ਜੋ ਪਹਿਲਾਂ ਉਤਪਾਦ ਡਿਜ਼ਾਈਨ ਅਤੇ ਵਿਕਾਸ ਦੇ ਅਭਿਆਸਾਂ ਵਿੱਚ ਵਰਣਨ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਸੀ - ਕਿਵੇਂ, ਉਦਾਹਰਨ ਲਈ, ਕੀ ਫ਼ੋਨਾਂ ਅਤੇ ਟੈਬਲੇਟਾਂ ਲਈ ਇੱਕ ਬਟਨ ਟੀਵੀ 'ਤੇ ਦੁਬਾਰਾ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ? ਅਤੇ ਸਾਨੂੰ ਅਜਿਹੇ ਵੱਖ-ਵੱਖ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ ਫੌਂਟਾਂ ਅਤੇ ਤੱਤਾਂ ਦੇ ਆਕਾਰਾਂ ਨਾਲ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ?

ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ, ਇੱਕ ਕਰਾਸ-ਪਲੇਟਫਾਰਮ ਮਾਡਿਊਲਰ ਗਰਿੱਡ ਨੂੰ ਡਿਜ਼ਾਈਨ ਕਰਨਾ ਜ਼ਰੂਰੀ ਸੀ ਜੋ ਹਰੇਕ ਖਾਸ ਪਲੇਟਫਾਰਮ ਲਈ ਲੋੜੀਂਦੇ ਟੈਕਸਟ ਅਤੇ ਐਲੀਮੈਂਟ ਆਕਾਰਾਂ ਨੂੰ ਸੈੱਟ ਕਰੇਗਾ। ਗਰਿੱਡ ਲਈ ਸ਼ੁਰੂਆਤੀ ਬਿੰਦੂ ਦੇ ਤੌਰ 'ਤੇ, ਅਸੀਂ ਮੂਵੀ ਪੋਸਟਰਾਂ ਦੇ ਆਕਾਰ ਅਤੇ ਸੰਖਿਆ ਨੂੰ ਚੁਣਿਆ ਹੈ ਜੋ ਅਸੀਂ ਕਿਸੇ ਖਾਸ ਸਕ੍ਰੀਨ 'ਤੇ ਦੇਖਣਾ ਚਾਹੁੰਦੇ ਹਾਂ ਅਤੇ, ਇਸਦੇ ਆਧਾਰ 'ਤੇ, ਅਸੀਂ ਗਰਿੱਡ ਕਾਲਮ ਬਣਾਉਣ ਲਈ ਇੱਕ ਨਿਯਮ ਤਿਆਰ ਕੀਤਾ ਹੈ, ਬਸ਼ਰਤੇ ਕਿ ਇੱਕ ਕਾਲਮ ਦੀ ਚੌੜਾਈ ਬਰਾਬਰ ਹੋਵੇ। ਪੋਸਟਰ ਦੀ ਚੌੜਾਈ ਤੱਕ.

ਹੁਣ ਸਾਨੂੰ ਸਾਰੀਆਂ ਵੱਡੀਆਂ ਸਕ੍ਰੀਨਾਂ ਨੂੰ ਇੱਕੋ ਲੇਆਉਟ ਸਾਈਜ਼ ਵਿੱਚ ਲਿਆਉਣ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਸਾਂਝੇ ਗਰਿੱਡ ਵਿੱਚ ਫਿੱਟ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। Apple TV ਅਤੇ Roku 1920x1080, Android TV - 960x540, ਸਮਾਰਟ ਟੀਵੀ, ਵਿਕਰੇਤਾ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹੋਏ, ਇੱਕੋ ਜਿਹੇ ਹੁੰਦੇ ਹਨ, ਪਰ ਕਈ ਵਾਰ 1280x720 ਦੇ ਆਕਾਰ ਵਿੱਚ ਤਿਆਰ ਕੀਤੇ ਗਏ ਹਨ। ਜਦੋਂ ਐਪ ਨੂੰ ਪੂਰੀ HD ਸਕ੍ਰੀਨਾਂ 'ਤੇ ਰੈਂਡਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਪ੍ਰਦਰਸ਼ਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ 960 ਨੂੰ 2 ਨਾਲ ਗੁਣਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, 1280 ਨੂੰ 1,33 ਨਾਲ ਗੁਣਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ 1920 ਨੂੰ ਆਊਟਪੁੱਟ ਦੀ ਤਰ੍ਹਾਂ ਹੁੰਦਾ ਹੈ।

ਬੋਰਿੰਗ ਵੇਰਵਿਆਂ ਨੂੰ ਛੱਡਦੇ ਹੋਏ, ਅਸੀਂ ਇਸ ਸਿੱਟੇ 'ਤੇ ਪਹੁੰਚੇ ਕਿ ਆਮ ਤੌਰ 'ਤੇ ਟੈਲੀਵਿਜ਼ਨ ਸਕ੍ਰੀਨਾਂ ਸਮੇਤ ਸਾਰੀਆਂ ਸਕ੍ਰੀਨਾਂ, ਤੱਤਾਂ ਅਤੇ ਉਹਨਾਂ ਦੇ ਆਕਾਰਾਂ ਦੇ ਰੂਪ ਵਿੱਚ, ਇੱਕ ਡਿਜ਼ਾਈਨ ਲੇਆਉਟ ਦੁਆਰਾ ਕਵਰ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਅਤੇ ਸਾਰੀਆਂ ਟੈਲੀਵਿਜ਼ਨ ਸਕ੍ਰੀਨਾਂ ਆਮ ਕਰਾਸ-ਪਲੇਟਫਾਰਮ ਗਰਿੱਡ ਦਾ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਕੇਸ ਹਨ, ਅਤੇ ਪੰਜ ਜਾਂ ਛੇ ਕਾਲਮ ਹੁੰਦੇ ਹਨ, ਜਿਵੇਂ ਕਿ ਔਸਤ ਟੈਬਲੈੱਟ ਜਾਂ ਡੈਸਕਟਾਪ। ਵੇਰਵਿਆਂ ਵਿੱਚ ਕੌਣ ਦਿਲਚਸਪੀ ਰੱਖਦਾ ਹੈ, ਟਿੱਪਣੀਆਂ ਵਿੱਚ ਜਾਓ.

ਸਾਰੇ ਪਲੇਟਫਾਰਮਾਂ ਲਈ ਸਿੰਗਲ UI

ਹੁਣ, ਇੱਕ ਨਵੀਂ ਵਿਸ਼ੇਸ਼ਤਾ ਬਣਾਉਣ ਲਈ, ਸਾਨੂੰ ਹਰੇਕ ਪਲੇਟਫਾਰਮ ਲਈ ਲੇਆਉਟ ਬਣਾਉਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ, ਨਾਲ ਹੀ ਉਹਨਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਲਈ ਅਨੁਕੂਲਤਾ ਵਿਕਲਪ। ਇਹ ਕਿਸੇ ਵੀ ਚੌੜਾਈ ਦੇ ਸਾਰੇ ਪਲੇਟਫਾਰਮਾਂ ਅਤੇ ਡਿਵਾਈਸਾਂ ਲਈ ਇੱਕ ਲੇਆਉਟ ਅਤੇ ਇਸਦੀ ਅਨੁਕੂਲਤਾ ਦਿਖਾਉਣ ਲਈ ਕਾਫੀ ਹੈ: ਫੋਨ - 320-599, ਬਾਕੀ ਸਭ - 600-1280.

ਡਾਟਾ → ਵਿਕਾਸ

ਬੇਸ਼ੱਕ, ਜਿੰਨਾ ਅਸੀਂ ਇੱਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਏਕੀਕ੍ਰਿਤ ਡਿਜ਼ਾਈਨ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ, ਹਰੇਕ ਪਲੇਟਫਾਰਮ ਦੀਆਂ ਆਪਣੀਆਂ ਵਿਲੱਖਣ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਹੁੰਦੀਆਂ ਹਨ। ਹਾਲਾਂਕਿ ਵੈੱਬ ਅਤੇ ਸਮਾਰਟ ਟੀਵੀ ਦੋਵੇਂ ReactJS + TypeScript ਸਟੈਕ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ, ਸਮਾਰਟ ਟੀਵੀ ਐਪ ਪੁਰਾਤਨ ਵੈਬਕਿੱਟ ਅਤੇ ਪ੍ਰੈਸਟੋ ਕਲਾਇੰਟਸ 'ਤੇ ਚੱਲਦੀ ਹੈ ਅਤੇ ਇਸਲਈ ਵੈੱਬ ਨਾਲ ਸ਼ੈਲੀਆਂ ਸਾਂਝੀਆਂ ਨਹੀਂ ਕਰ ਸਕਦੀਆਂ। ਅਤੇ ਈਮੇਲ ਨਿਊਜ਼ਲੈਟਰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਟੇਬਲ ਲੇਆਉਟ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਮਜਬੂਰ ਹਨ। ਇਸ ਦੇ ਨਾਲ ਹੀ, ਕੋਈ ਵੀ ਗੈਰ-html ਪਲੇਟਫਾਰਮਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਰੀਐਕਟ ਨੇਟਿਵ ਜਾਂ ਇਸਦੇ ਕਿਸੇ ਵੀ ਐਨਾਲਾਗ ਦੀ ਵਰਤੋਂ ਜਾਂ ਵਰਤੋਂ ਕਰਨ ਦੀ ਯੋਜਨਾ ਨਹੀਂ ਬਣਾਉਂਦਾ, ਕਾਰਗੁਜ਼ਾਰੀ ਵਿੱਚ ਗਿਰਾਵਟ ਤੋਂ ਡਰਦਾ ਹੈ, ਕਿਉਂਕਿ ਸਾਡੇ ਕੋਲ ਬਹੁਤ ਸਾਰੇ ਕਸਟਮ ਲੇਆਉਟ ਹਨ, ਗੁੰਝਲਦਾਰ ਅੱਪਡੇਟ ਤਰਕ, ਚਿੱਤਰ ਅਤੇ ਵੀਡੀਓ ਦੇ ਨਾਲ ਸੰਗ੍ਰਹਿ। ਇਸ ਲਈ, ਤਿਆਰ-ਕੀਤੀ CSS ਸਟਾਈਲ ਜਾਂ ਪ੍ਰਤੀਕਿਰਿਆ ਵਾਲੇ ਹਿੱਸੇ ਪ੍ਰਦਾਨ ਕਰਨ ਦੀ ਆਮ ਸਕੀਮ ਸਾਡੇ ਲਈ ਢੁਕਵੀਂ ਨਹੀਂ ਹੈ। ਇਸ ਲਈ, ਅਸੀਂ ਇੱਕ ਸੰਖੇਪ ਘੋਸ਼ਣਾਤਮਕ ਰੂਪ ਵਿੱਚ ਮੁੱਲਾਂ ਦਾ ਵਰਣਨ ਕਰਦੇ ਹੋਏ, JSON ਫਾਰਮੈਟ ਵਿੱਚ ਡੇਟਾ ਪ੍ਰਸਾਰਿਤ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ।

ਇਸ ਲਈ ਜਾਇਦਾਦ rounding: 8 Windows 10 ਐਪ ਵਿੱਚ ਬਦਲਦਾ ਹੈ CornerRadius="8", ਵੈੱਬ - border-radius: 8px, Android - android:radius="8dp", iOS - self.layer.cornerRadius = 8.0.
ਜਾਇਦਾਦ offsetTop: 12 ਵੱਖ-ਵੱਖ ਮਾਮਲਿਆਂ ਵਿੱਚ ਇੱਕੋ ਵੈਬ ਕਲਾਇੰਟ ਦੀ ਵਿਆਖਿਆ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ top, margin-top, padding-top ਜ transform

ਵਰਣਨ ਦੀ ਘੋਸ਼ਣਾਤਮਕਤਾ ਇਹ ਵੀ ਦਰਸਾਉਂਦੀ ਹੈ ਕਿ ਜੇਕਰ ਪਲੇਟਫਾਰਮ ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਕਿਸੇ ਜਾਇਦਾਦ ਜਾਂ ਇਸਦੇ ਮੁੱਲ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਤਾਂ ਇਹ ਇਸਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰ ਸਕਦਾ ਹੈ। ਪਰਿਭਾਸ਼ਾ ਦੇ ਰੂਪ ਵਿੱਚ, ਅਸੀਂ ਇੱਕ ਕਿਸਮ ਦੀ ਐਸਪੇਰਾਂਟੋ ਭਾਸ਼ਾ ਬਣਾਈ ਹੈ: ਕੁਝ ਐਂਡਰਾਇਡ ਤੋਂ, ਕੁਝ SVG ਤੋਂ, ਕੁਝ CSS ਤੋਂ ਲਈਆਂ ਗਈਆਂ ਸਨ।

ਜੇਕਰ ਕਿਸੇ ਖਾਸ ਪਲੇਟਫਾਰਮ 'ਤੇ ਤੁਹਾਨੂੰ ਤੱਤਾਂ ਨੂੰ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਅਸੀਂ ਇੱਕ ਵੱਖਰੀ JSON ਫਾਈਲ ਦੇ ਰੂਪ ਵਿੱਚ ਸੰਬੰਧਿਤ ਡੇਟਾ ਜਨਰੇਸ਼ਨ ਨੂੰ ਟ੍ਰਾਂਸਫਰ ਕਰਨ ਦੀ ਯੋਗਤਾ ਨੂੰ ਲਾਗੂ ਕੀਤਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਸਮਾਰਟ ਟੀਵੀ ਲਈ "ਫੋਕਸ ਵਿੱਚ" ਸਥਿਤੀ ਪੋਸਟਰ ਦੇ ਹੇਠਾਂ ਟੈਕਸਟ ਦੀ ਸਥਿਤੀ ਵਿੱਚ ਤਬਦੀਲੀ ਦਾ ਆਦੇਸ਼ ਦਿੰਦੀ ਹੈ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇਸ ਪਲੇਟਫਾਰਮ ਲਈ "ਇੰਡੈਂਟ" ਸੰਪੱਤੀ ਦੇ ਮੁੱਲ ਵਿੱਚ ਇਸ ਹਿੱਸੇ ਵਿੱਚ ਲੋੜੀਂਦੇ 8 ਇੰਡੈਂਟੇਸ਼ਨ ਪੁਆਇੰਟ ਹੋਣਗੇ। ਹਾਲਾਂਕਿ ਇਹ ਡਿਜ਼ਾਇਨ ਸਿਸਟਮ ਦੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਨੂੰ ਗੁੰਝਲਦਾਰ ਬਣਾਉਂਦਾ ਹੈ, ਇਹ ਆਜ਼ਾਦੀ ਦੀ ਇੱਕ ਵਾਧੂ ਡਿਗਰੀ ਦਿੰਦਾ ਹੈ, ਸਾਨੂੰ ਪਲੇਟਫਾਰਮਾਂ ਦੀ ਵਿਜ਼ੂਅਲ "ਅਸਮਾਨਤਾ" ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਦਾ ਮੌਕਾ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਸਾਡੇ ਦੁਆਰਾ ਬਣਾਏ ਗਏ ਆਰਕੀਟੈਕਚਰ ਦਾ ਬੰਧਕ ਨਾ ਬਣੋ।

ਪਿਕਟੋਗ੍ਰਾਮ

ਇੱਕ ਡਿਜੀਟਲ ਉਤਪਾਦ ਵਿੱਚ ਆਈਕੋਨੋਗ੍ਰਾਫੀ ਹਮੇਸ਼ਾਂ ਇੱਕ ਵਿਸ਼ਾਲ ਹੁੰਦੀ ਹੈ ਅਤੇ ਸਧਾਰਨ ਉਪ-ਪ੍ਰੋਜੈਕਟ ਨਹੀਂ ਹੁੰਦੀ, ਅਕਸਰ ਇੱਕ ਵੱਖਰੇ ਡਿਜ਼ਾਈਨਰ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇੱਥੇ ਹਮੇਸ਼ਾਂ ਬਹੁਤ ਸਾਰੇ ਗਲਾਈਫ ਹੁੰਦੇ ਹਨ, ਉਹਨਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਦੇ ਕਈ ਆਕਾਰ ਅਤੇ ਰੰਗ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਪਲੇਟਫਾਰਮਾਂ ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਵੱਖ-ਵੱਖ ਫਾਰਮੈਟਾਂ ਵਿੱਚ ਉਹਨਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਆਮ ਤੌਰ 'ਤੇ, ਇਸ ਸਭ ਨੂੰ ਡਿਜ਼ਾਈਨ ਪ੍ਰਣਾਲੀ ਵਿਚ ਨਾ ਪਾਉਣ ਦਾ ਕੋਈ ਕਾਰਨ ਨਹੀਂ ਸੀ.

ਗਲਾਈਫਸ ਨੂੰ SVG ਵੈਕਟਰ ਫਾਰਮੈਟ ਵਿੱਚ ਲੋਡ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਰੰਗ ਮੁੱਲ ਆਪਣੇ ਆਪ ਵੇਰੀਏਬਲ ਨਾਲ ਬਦਲ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ। ਕਲਾਇੰਟ ਐਪਲੀਕੇਸ਼ਨਾਂ ਉਹਨਾਂ ਨੂੰ ਵਰਤਣ ਲਈ ਤਿਆਰ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੀਆਂ ਹਨ - ਕਿਸੇ ਵੀ ਫਾਰਮੈਟ ਅਤੇ ਰੰਗ ਵਿੱਚ।

ਝਲਕ

JSON ਡੇਟਾ ਦੇ ਸਿਖਰ 'ਤੇ, ਅਸੀਂ ਕੰਪੋਨੈਂਟਸ ਦੀ ਪੂਰਵਦਰਸ਼ਨ ਲਈ ਇੱਕ ਟੂਲ ਲਿਖਿਆ ਹੈ - ਇੱਕ JS ਐਪਲੀਕੇਸ਼ਨ ਜੋ JSON ਡੇਟਾ ਨੂੰ ਇਸਦੇ ਮਾਰਕਅੱਪ ਅਤੇ ਸਟਾਈਲ ਜਨਰੇਟਰਾਂ ਦੁਆਰਾ ਫਲਾਈ 'ਤੇ ਪਾਸ ਕਰਦੀ ਹੈ, ਅਤੇ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਹਰੇਕ ਕੰਪੋਨੈਂਟ ਦੇ ਵੱਖ-ਵੱਖ ਰੂਪਾਂ ਨੂੰ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਦੀ ਹੈ। ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ, ਪੂਰਵਦਰਸ਼ਨ ਪਲੇਟਫਾਰਮ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਾਂਗ ਬਿਲਕੁਲ ਉਹੀ ਕਲਾਇੰਟ ਹੈ ਅਤੇ ਉਸੇ ਡੇਟਾ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ।

ਇਹ ਸਮਝਣ ਦਾ ਸਭ ਤੋਂ ਆਸਾਨ ਤਰੀਕਾ ਹੈ ਕਿ ਕੋਈ ਖਾਸ ਕੰਪੋਨੈਂਟ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ ਇਸਦੇ ਨਾਲ ਇੰਟਰੈਕਟ ਕਰਨਾ ਹੈ। ਇਸ ਲਈ, ਅਸੀਂ ਸਟੋਰੀਬੁੱਕ ਵਰਗੇ ਟੂਲਸ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕੀਤੀ, ਪਰ ਇੱਕ ਇੰਟਰਐਕਟਿਵ ਪੂਰਵਦਰਸ਼ਨ ਬਣਾਇਆ - ਤੁਸੀਂ ਛੂਹ ਸਕਦੇ ਹੋ, ਪੁਆਇੰਟ ਕਰ ਸਕਦੇ ਹੋ, ਕਲਿੱਕ ਕਰ ਸਕਦੇ ਹੋ... ਜਦੋਂ ਡਿਜ਼ਾਈਨ ਸਿਸਟਮ ਵਿੱਚ ਇੱਕ ਨਵਾਂ ਭਾਗ ਜੋੜਦੇ ਹੋ, ਤਾਂ ਇਹ ਪੂਰਵਦਰਸ਼ਨ ਵਿੱਚ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ ਤਾਂ ਜੋ ਪਲੇਟਫਾਰਮਾਂ ਨੂੰ ਇਸ ਗੱਲ 'ਤੇ ਧਿਆਨ ਦੇਣ ਲਈ ਕੁਝ ਹੋਵੇ ਕਿ ਕਦੋਂ ਇਸ ਨੂੰ ਲਾਗੂ ਕਰਨਾ.

ਦਸਤਾਵੇਜ਼

ਪਲੇਟਫਾਰਮਾਂ ਨੂੰ JSON ਦੇ ਰੂਪ ਵਿੱਚ ਸਪਲਾਈ ਕੀਤੇ ਗਏ ਡੇਟਾ ਦੇ ਅਧਾਰ 'ਤੇ, ਭਾਗਾਂ ਲਈ ਦਸਤਾਵੇਜ਼ ਆਪਣੇ ਆਪ ਤਿਆਰ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਉਹਨਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਵਿੱਚ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਅਤੇ ਸੰਭਾਵਿਤ ਕਿਸਮਾਂ ਦੇ ਮੁੱਲਾਂ ਦੀ ਸੂਚੀ ਦਿੱਤੀ ਗਈ ਹੈ। ਆਟੋ-ਜਨਰੇਸ਼ਨ ਤੋਂ ਬਾਅਦ, ਜਾਣਕਾਰੀ ਨੂੰ ਹੱਥੀਂ ਸਪੱਸ਼ਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਅਤੇ ਇੱਕ ਟੈਕਸਟ ਵੇਰਵਾ ਜੋੜਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਪੂਰਵਦਰਸ਼ਨ ਅਤੇ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਹਰੇਕ ਹਿੱਸੇ ਦੇ ਪੱਧਰ 'ਤੇ ਇੱਕ ਦੂਜੇ ਦਾ ਹਵਾਲਾ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਸ਼ਾਮਲ ਸਾਰੀ ਜਾਣਕਾਰੀ ਵਿਕਾਸਕਾਰਾਂ ਲਈ ਵਾਧੂ JSON ਫਾਈਲਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਉਪਲਬਧ ਹੁੰਦੀ ਹੈ।

ਅਪਮਾਨਜਨਕ

ਇੱਕ ਹੋਰ ਲੋੜ ਸਮੇਂ ਦੇ ਨਾਲ ਮੌਜੂਦਾ ਭਾਗਾਂ ਨੂੰ ਬਦਲਣ ਅਤੇ ਅਪਡੇਟ ਕਰਨ ਦੀ ਯੋਗਤਾ ਸੀ। ਡਿਜ਼ਾਇਨ ਸਿਸਟਮ ਨੇ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਇਹ ਦੱਸਣਾ ਸਿੱਖਿਆ ਹੈ ਕਿ ਕਿਹੜੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਜਾਂ ਇੱਥੋਂ ਤੱਕ ਕਿ ਪੂਰੇ ਕੰਪੋਨੈਂਟਸ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਹਟਾ ਦਿਓ ਕਿਉਂਕਿ ਉਹ ਹੁਣ ਸਾਰੇ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ ਨਹੀਂ ਵਰਤੇ ਜਾਂਦੇ ਹਨ। ਇਸ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਅਜੇ ਵੀ ਬਹੁਤ ਸਾਰੀ "ਹੱਥੀ" ਕਿਰਤ ਹੈ, ਪਰ ਅਸੀਂ ਸਥਿਰ ਨਹੀਂ ਹਾਂ।

ਗਾਹਕ ਵਿਕਾਸ

ਬਿਨਾਂ ਸ਼ੱਕ, ਸਭ ਤੋਂ ਗੁੰਝਲਦਾਰ ਪੜਾਅ ਸਾਡੇ ਦੁਆਰਾ ਸਮਰਥਤ ਸਾਰੇ ਪਲੇਟਫਾਰਮਾਂ ਦੇ ਕੋਡ ਵਿੱਚ ਡਿਜ਼ਾਈਨ ਸਿਸਟਮ ਡੇਟਾ ਦੀ ਵਿਆਖਿਆ ਸੀ। ਜੇ, ਉਦਾਹਰਨ ਲਈ, ਵੈੱਬ 'ਤੇ ਮਾਡਿਊਲਰ ਗਰਿੱਡ ਕੁਝ ਨਵਾਂ ਨਹੀਂ ਹਨ, ਤਾਂ ਆਈਓਐਸ ਅਤੇ ਐਂਡਰੌਇਡ ਲਈ ਨੇਟਿਵ ਮੋਬਾਈਲ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੇ ਡਿਵੈਲਪਰਾਂ ਨੇ ਇਸ ਨਾਲ ਕਿਵੇਂ ਰਹਿਣਾ ਹੈ ਇਹ ਸਮਝਣ ਤੋਂ ਪਹਿਲਾਂ ਸਖ਼ਤ ਮਿਹਨਤ ਕੀਤੀ।

ਆਈਓਐਸ ਐਪਲੀਕੇਸ਼ਨ ਸਕ੍ਰੀਨਾਂ ਦਾ ਲੇਆਉਟ ਕਰਨ ਲਈ, ਅਸੀਂ iviUIKit ਦੁਆਰਾ ਪ੍ਰਦਾਨ ਕੀਤੇ ਗਏ ਦੋ ਬੁਨਿਆਦੀ ਵਿਧੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ: ਤੱਤਾਂ ਦਾ ਮੁਫਤ ਖਾਕਾ ਅਤੇ ਤੱਤਾਂ ਦੇ ਸੰਗ੍ਰਹਿ ਦਾ ਖਾਕਾ। ਅਸੀਂ VIPER ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ, ਅਤੇ iviUIKit ਨਾਲ ਸਾਰੀ ਪਰਸਪਰ ਕ੍ਰਿਆ ਵਿਊ ਵਿੱਚ ਕੇਂਦ੍ਰਿਤ ਹੈ, ਅਤੇ Apple UIKit ਨਾਲ ਜ਼ਿਆਦਾਤਰ ਇੰਟਰੈਕਸ਼ਨ iviUIKit ਵਿੱਚ ਕੇਂਦ੍ਰਿਤ ਹੈ। ਤੱਤਾਂ ਦੇ ਆਕਾਰ ਅਤੇ ਪ੍ਰਬੰਧ ਕਾਲਮਾਂ ਅਤੇ ਸਿੰਟੈਕਟਿਕ ਢਾਂਚੇ ਦੇ ਰੂਪ ਵਿੱਚ ਨਿਰਧਾਰਤ ਕੀਤੇ ਗਏ ਹਨ ਜੋ ਮੂਲ iOS SDK ਸੀਮਾਵਾਂ ਦੇ ਸਿਖਰ 'ਤੇ ਕੰਮ ਕਰਦੇ ਹਨ, ਉਹਨਾਂ ਨੂੰ ਵਧੇਰੇ ਵਿਹਾਰਕ ਬਣਾਉਂਦੇ ਹਨ। UICollectionView ਨਾਲ ਕੰਮ ਕਰਦੇ ਸਮੇਂ ਇਸਨੇ ਖਾਸ ਤੌਰ 'ਤੇ ਸਾਡੀ ਜ਼ਿੰਦਗੀ ਨੂੰ ਸਰਲ ਬਣਾਇਆ। ਅਸੀਂ ਲੇਆਉਟ ਲਈ ਕਈ ਕਸਟਮ ਰੈਪਰ ਲਿਖੇ ਹਨ, ਜਿਸ ਵਿੱਚ ਕਾਫ਼ੀ ਗੁੰਝਲਦਾਰ ਵੀ ਸ਼ਾਮਲ ਹਨ। ਘੱਟੋ-ਘੱਟ ਕਲਾਇੰਟ ਕੋਡ ਸੀ ਅਤੇ ਇਹ ਘੋਸ਼ਣਾਤਮਕ ਬਣ ਗਿਆ।

ਐਂਡਰੌਇਡ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਸਟਾਈਲ ਬਣਾਉਣ ਲਈ, ਅਸੀਂ ਗ੍ਰੇਡਲ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ, ਡਿਜ਼ਾਈਨ ਸਿਸਟਮ ਡੇਟਾ ਨੂੰ XML ਫਾਰਮੈਟ ਵਿੱਚ ਸਟਾਈਲ ਵਿੱਚ ਬਦਲਦੇ ਹਾਂ। ਉਸੇ ਸਮੇਂ, ਸਾਡੇ ਕੋਲ ਵੱਖ-ਵੱਖ ਪੱਧਰਾਂ ਦੇ ਕਈ ਜਨਰੇਟਰ ਹਨ:

• ਮੁੱicਲਾ. ਉੱਚ ਪੱਧਰੀ ਜਨਰੇਟਰਾਂ ਲਈ ਮੁੱਢਲੇ ਡੇਟਾ ਨੂੰ ਪਾਰਸ ਕੀਤਾ ਜਾਂਦਾ ਹੈ.
• ਸਰੋਤ. ਤਸਵੀਰਾਂ, ਆਈਕਨਾਂ ਅਤੇ ਹੋਰ ਗ੍ਰਾਫਿਕਸ ਡਾਊਨਲੋਡ ਕਰੋ।
• ਕੰਪੋਨੈਂਟ. ਉਹ ਹਰੇਕ ਕੰਪੋਨੈਂਟ ਲਈ ਲਿਖੇ ਗਏ ਹਨ, ਜੋ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿਹੜੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਸਟਾਈਲ ਵਿੱਚ ਕਿਵੇਂ ਅਨੁਵਾਦ ਕਰਨਾ ਹੈ।

ਐਪਲੀਕੇਸ਼ਨ ਰੀਲੀਜ਼

ਡਿਜ਼ਾਇਨਰਜ਼ ਦੁਆਰਾ ਇੱਕ ਨਵਾਂ ਕੰਪੋਨੈਂਟ ਖਿੱਚਣ ਜਾਂ ਮੌਜੂਦਾ ਇੱਕ ਨੂੰ ਮੁੜ ਡਿਜ਼ਾਇਨ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਇਹਨਾਂ ਤਬਦੀਲੀਆਂ ਨੂੰ ਡਿਜ਼ਾਈਨ ਸਿਸਟਮ ਵਿੱਚ ਖੁਆਇਆ ਜਾਂਦਾ ਹੈ। ਹਰੇਕ ਪਲੇਟਫਾਰਮ ਦੇ ਡਿਵੈਲਪਰ ਤਬਦੀਲੀਆਂ ਦਾ ਸਮਰਥਨ ਕਰਨ ਲਈ ਆਪਣੇ ਕੋਡ ਜਨਰੇਸ਼ਨ ਨੂੰ ਵਧੀਆ ਬਣਾ ਰਹੇ ਹਨ। ਇਸ ਤੋਂ ਬਾਅਦ, ਇਸਦੀ ਵਰਤੋਂ ਨਵੀਂ ਕਾਰਜਸ਼ੀਲਤਾ ਨੂੰ ਲਾਗੂ ਕਰਨ ਵਿੱਚ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ ਜਿੱਥੇ ਇਸ ਭਾਗ ਦੀ ਜ਼ਰੂਰਤ ਹੈ. ਇਸ ਤਰ੍ਹਾਂ, ਡਿਜ਼ਾਇਨ ਸਿਸਟਮ ਨਾਲ ਪਰਸਪਰ ਪ੍ਰਭਾਵ ਅਸਲ ਸਮੇਂ ਵਿੱਚ ਨਹੀਂ ਹੁੰਦਾ, ਪਰ ਸਿਰਫ ਨਵੇਂ ਰੀਲੀਜ਼ਾਂ ਨੂੰ ਇਕੱਠਾ ਕਰਨ ਵੇਲੇ ਹੁੰਦਾ ਹੈ। ਇਹ ਪਹੁੰਚ ਡੇਟਾ ਟ੍ਰਾਂਸਫਰ ਪ੍ਰਕਿਰਿਆ 'ਤੇ ਬਿਹਤਰ ਨਿਯੰਤਰਣ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ ਅਤੇ ਗਾਹਕ ਵਿਕਾਸ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਕੋਡ ਕਾਰਜਕੁਸ਼ਲਤਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਂਦੀ ਹੈ।

ਨਤੀਜੇ

ਆਈਵੀ ਔਨਲਾਈਨ ਸਿਨੇਮਾ ਦੇ ਵਿਕਾਸ ਲਈ ਡਿਜ਼ਾਇਨ ਸਿਸਟਮ ਨੂੰ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦਾ ਹਿੱਸਾ ਬਣਨ ਤੋਂ ਇੱਕ ਸਾਲ ਹੋ ਗਿਆ ਹੈ, ਅਤੇ ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਕੁਝ ਸਿੱਟੇ ਕੱਢ ਸਕਦੇ ਹਾਂ:

• ਇਹ ਇੱਕ ਵਿਸ਼ਾਲ ਅਤੇ ਗੁੰਝਲਦਾਰ ਪ੍ਰੋਜੈਕਟ ਹੈ ਜਿਸ ਲਈ ਨਿਰੰਤਰ ਸਮਰਪਿਤ ਸਰੋਤਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
• ਇਸ ਨੇ ਸਾਨੂੰ ਆਪਣੀ ਵਿਲੱਖਣ ਕਰਾਸ-ਪਲੇਟਫਾਰਮ ਵਿਜ਼ੂਅਲ ਭਾਸ਼ਾ ਬਣਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੱਤੀ ਜੋ ਔਨਲਾਈਨ ਵੀਡੀਓ ਸੇਵਾ ਦੇ ਉਦੇਸ਼ਾਂ ਨੂੰ ਪੂਰਾ ਕਰਦੀ ਹੈ।
• ਸਾਡੇ ਕੋਲ ਹੁਣ ਦ੍ਰਿਸ਼ਟੀਗਤ ਅਤੇ ਕਾਰਜਸ਼ੀਲ ਤੌਰ 'ਤੇ ਪਛੜਨ ਵਾਲੇ ਪਲੇਟਫਾਰਮ ਨਹੀਂ ਹਨ।

ਆਈਵੀ ਡਿਜ਼ਾਈਨ ਸਿਸਟਮ ਭਾਗਾਂ ਦੀ ਝਲਕ - design.ivi.ru

ਸਰੋਤ: www.habr.com