Kotlin ਨੇ ਸੁਰੱਖਿਅਤ ਸਿੰਟੈਕਸ, ਬਿਹਤਰ ਟੂਲਿੰਗ ਅਤੇ Java ਇੰਟਰਓਪਰੇਬਿਲਿਟੀ ਜੋੜ ਕੇ JVM ਨੂੰ ਆਧੁਨਿਕ ਬਣਾਇਆ—ਨਤੀਜੇ ਵਜੋਂ Android ਐਪ ਤੇਜ਼ੀ ਨਾਲ ਬਣਦੀਆਂ ਅਤੇ ਮੈਨਟੇਨ ਕਰਨਾ ਆਸਾਨ ਹੋ ਗਿਆ।
Kotlin JetBrains ਵੱਲੋਂ ਬਣਾਈ ਇੱਕ ਆਧੁਨਿਕ ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾ ਹੈ ਜੋ JVM ਬਾਈਟਕੋਡ ਵਿੱਚ ਕੰਪਾਇਲ ਹੁੰਦੀ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਇਹ ਉਥੇ ਚੱਲਦੀ ਹੈ ਜਿੱਥੇ Java ਚੱਲਦੀ ਹੈ: ਬੈਕਐਂਡ ਸਰਵਿਸਿਜ਼, ਡੈਸਕਟਾਪ ਐਪ ਅਤੇ—ਸਭ ਤੋਂ ਦਿੱਖਣਯੋਗ—Android। ਇਸਦੇ ਨਾਲ-ਨਾਲ Kotlin JavaScript ਅਤੇ ਨੇਟਿਵ ਪਲੇਟਫਾਰਮਾਂ ਲਈ ਵੀ ਟਾਰਗਟ ਕਰ ਸਕਦਾ ਹੈ (Kotlin Multiplatform), ਪਰ ਇਸਦੀ “ਘਰ ਦੀ ਜਗ੍ਹਾ” ਅਜੇ ਵੀ JVM ਹੈ।
Kotlin ਨੇ Java ਨੂੰ ਬਦਲਿਆ ਨਹੀਂ; ਇਸ ਨੇ JVM ਵਿਕਾਸ ਦਾ ਮਿਆਰ ਉੱਪਰ ਲਿਆ। ਅਮਲੀ ਜ਼ਿੰਦਗੀ 'ਚ ਇਹ ਸੁਧਾਰ ਇਸ ਤਰ੍ਹਾਂ ਦਿੱਸਦਾ ਹੈ:
Android ਪਹਿਲਾਂ ਹੀ Java APIs, ਟੂਲਿੰਗ ਅਤੇ ਲਾਇਬ੍ਰੇਰੀਆਂ 'ਤੇ ਮੂਲ ਰੂਪ ਵਿੱਚ ਨਿਰਭਰ ਸੀ। Kotlin ਦੀ ਨਿਰਵਿਘਨ ਇੰਟਰਓਪਰੇਬਿਲਿਟੀ ਨੇ ਟੀਮਾਂ ਨੂੰ ਇੱਕ-ਫਾਈਲ-ਦਰ-ਇੱਕ-ਫਾਈਲ ਤਰੀਕੇ ਨਾਲ ਇਸਨੂੰ ਲਗਾਉਣ ਦੀ ਆਜ਼ਾਦੀ ਦਿੱਤੀ: Kotlin ਤੋਂ Java ਕਾਲ ਕਰੋ, Java ਤੋਂ Kotlin ਕਾਲ ਕਰੋ, ਅਤੇ ਓਹੀ ਬਿਲਡ ਸਿਸਟਮ ਅਤੇ ਰਨਟਾਈਮ ਰੱਖੋ।
ਉਤਨਾ ਹੀ ਜ਼ਰੂਰੀ, Kotlin Android Studio ਅਤੇ Gradle ਵਰਕਫਲੋਜ਼ ਵਿੱਚ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਫਿੱਟ ਹੋ ਗਿਆ, ਇਸ ਲਈ ਇਸਨੂੰ ਅਪਨਾਉਣਾ ਕੋਈ ਨਵਾਂ ਟੂਲਚੇਨ ਜਾਂ ਪੂਰੀ ਰੀਰਾਈਟ ਮੰਗਦਾ ਨਹੀਂ ਸੀ। ਟੀਮਾਂ ਛੋਟੇ ਮੋਡੀਊਲ ਨਾਲ ਸ਼ੁਰੂ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਖਤਰਾ ਘਟਾਉਂਦੀਆਂ ਹਨ, ਅਤੇ ਜਦੋਂ ਪ੍ਰੋਡਕਟਿਵਟੀ ਜਿਆਂਚੀ ਗਈ ਤਾਂ ਵਧਾ ਸਕਦੀਆਂ ਹਨ।
Kotlin ਅਕਸਰ ਫਾਇਦਾ ਦਿੰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਕਿਸੇ ਵੱਡੇ Android ਕੋਡਬੇਸ ਨੂੰ ਬਣਾਉਂਦੇ ਜਾਂ ਰੱਖ-ਰਖਾਅ ਕਰ ਰਹੇ ਹੁੰਦੇ ਹੋ, ਖਾਸ ਕਰਕੇ ਜਿੱਥੇ ਸਹੀਪਣ ਅਤੇ ਪੜ੍ਹਨਯੋਗਤਾ ਲੋੜੀਦੀ ਹੋਵੇ। ਟਰੇਡ-ਆਫ ਨੁਮਾਇੰਦਗੀ ਹਨ: ਬਿਲਡ ਸਮੇਂ ਵੱਧ ਸਕਦੇ ਹਨ, APIs ਇੱਕੋਂ-ਜੇਹੇ ਕੰਮ ਕਰਨ ਦੇ ਕਈ ਤਰੀਕੇ ਦੇ ਸਕਦੀਆਂ ਹਨ, ਅਤੇ ਮਿਕਸਡ Java/Kotlin ਪ੍ਰੋਜੈਕਟਾਂ ਨੂੰ ਲਗਾਤਾਰ ਸਟਾਈਲ ਅਤੇ ਕਨਵੈਂਸ਼ਨਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
ਇਹ ਲੇਖ ਪ੍ਰੇਕਟਿਕਲ ਜੇਤੂਆਂ, ਫਠਕਾਰਾਂ ਅਤੇ ਉਹ ਸਮੇਂ ਜਦੋਂ Kotlin ਤੁਹਾਡੇ Android ਐਪ ਅਤੇ JVM ਪ੍ਰੋਜੈਕਟਾਂ ਲਈ ਠੀਕ ਚੋਣ ਹੈ, ਉਤੇ ਰੋਸ਼ਨੀ ਡਾਲਦਾ ਹੈ।
Kotlin ਸਿਰਫ਼ ਨਵੀਂ ਸੁੰਦਰ ਸਿੰਟੈਕਸ ਜੋੜਨ ਕਾਰਨ ਕਾਮਯਾਬ ਨਹੀਂ ਹੋਈ। ਇਸਨੇ ਉਹ ਖਾਸ ਤਰ੍ਹਾਂ ਦੀਆਂ ਟੋਟਕੀਆਂ ਟਾਰਗਟ ਕੀਤੀਆਂ ਜੋ JVM ਅਤੇ Android ਟੀਮਾਂ ਕਈ ਸਾਲਾਂ ਤੋਂ ਜ਼ਾਹਰ ਕਰ ਰਹੀਆਂ ਸਨ—ਉਹ ਸਮੱਸਿਆਵਾਂ ਜਦੋਂ ਐਪ, ਕੋਡਬੇਸ ਅਤੇ ਅੰਗਠਾ ਵੱਧਦੇ ਗਏ ਤਾਂ ਹੋਰ ਤੇਜ਼ ਹੋ ਗਈਆਂ।
ਸ਼ੁਰੂਆਤੀ Android ਵਿਕਾਸ Java ਦੇ ਪੈਟਰਨਾਂ 'ਤੇ ਬਹੁਤ ਨਿਰਭਰ ਕਰਦਾ ਸੀ ਜੋ ਸਰਵਰ ਪਾਸੇ ਠੀਕ ਸਨ, ਪਰ ਮੋਬਾਈਲ 'ਤੇ ਝਟਪਟ ਅਤੇ ਅਜੀਬ ਲੱਗਦੇ ਸਨ। ਰੋਜ਼ਾਨਾ ਤਾਸਕ ਅਕਸਰ ਲੰਮੇ-ਲੰਮੇ ਬੋਇਲੇਰਪਲੇਟ ਵਿਚ ਬਦਲ ਜਾਂਦੇ: getters/setters, builders, callbacks, ਅਤੇ ਡੇਟਾ ਹਿਲਾਉਣ ਲਈ ਦੁਹਰਾਵਾਂ “ਪਲੰਬਿੰਗ” ਕੋਡ।
ਨਲ ਹੈਂਡਲਿੰਗ ਇਕ ਹੋਰ ਮੁੱਖ ਸਰੋਤ ਸੀ। ਇੱਕ ਅਚਾਨਕ null ਐਪ ਨੂੰ ਰਨਟਾਈਮ 'ਤੇ ਗਿਰਾ ਸਕਦਾ ਸੀ, ਅਤੇ ਡੀਫੈਂਸਿਵ ਚੈਕਸ (if (x != null)) ਹਰ ਥਾਂ ਫੈਲ ਗਈ—ਜੋ ਕੋਡ ਨੂੰ ਸ਼ੋਰ ਕਰ ਦਿੰਦਾ ਪਰ ਫਿਰ ਭੀ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸੁਰੱਖਿਅਤ ਨਹੀਂ ਸੀ।
ਜਿਵੇਂ-ਜਿਵੇਂ Android ਐਪ "ਅਸਲ ਉਤਪਾਦ" ਬਣੇ (ਕਈ ਸਕ੍ਰੀਨ, ਫਲਾਈਨ ਸਹਾਇਤਾ, ਐਨਾਲਿਟਿਕਸ, ਟੈਸਟਿੰਗ, ਫੀਚਰ ਫਲੈਗ), ਟੀਮਾਂ ਨੂੰ ਐਸਾ ਕੋਡ ਚਾਹੀਦਾ ਸੀ ਜੋ ਦਬਾਅ ਹੇਠ ਵੀ ਪੜ੍ਹਨਯੋਗ ਰਹੇ। ਵੱਧ ਯੋਗਦਾਨਕਾਰਾਂ ਦਾ ਮਤਲਬ ਵੱਧ ਰਿਵਿਊਓਵਰਹੈੱਡ ਅਤੇ ਜਦ APIs ਅਸਪਸ਼ਟ ਹੁੰਦੇ ਤਾਂ ਲਾਗਤ ਵਧ ਜਾਂਦੀ।
ਇਸ ਮਾਹੌਲ ਵਿੱਚ, ਇੱਕ ਭਾਸ਼ਾ ਜੋ ਸੰਕੁਚਿਤ, ਪੇਸ਼ਗੀ-ਭਰੋਸੇਯੋਗ ਕੋਡ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਦੀ ਸੀ, ਉਹ ਸਿਰਫ਼ ਇੱਕ ਆਲੋਕਿਕ ਲੋੜ ਨਹੀਂ ਰਹੀ—ਇਹ ਸਿੱਧਾ ਨਿਕਾਸੀ ਰਫਤਾਰ ਅਤੇ ਡੈਫੈਕਟ ਰੇਟ 'ਤੇ ਅਸਰ ਪਾਉਂਦੀ ਸੀ।
ਮੋਬਾਈਲ ਐਪ ਤਕਨਿਕੀ ਰੂਪ ਵਿੱਚ asynchronous ਹਨ: ਨੈੱਟਵਰਕ ਕਾਲ, ਡੇਟਾਬੇਸ, ਸੈਂਸਰ, UI ਇਵੈਂਟ ਆਦਿ। Java-ਯੁੱਗ ਦਾ Android ਅਕਸਰ nested callbacks, ਕਸਟਮ ਥ੍ਰੇਡ ਹੈਂਡਲਿੰਗ, ਜਾਂ ਐਡ-ਹੌਕ ਅਬਸਟ੍ਰੈਕਸ਼ਨਾਂ ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਸੀ। ਨਤੀਜਾ "callback spaghetti" ਬਣਣਾ, ਐਰਰ propagation ਮੁਸ਼ਕਲ ਹੋਣਾ, ਅਤੇ ਕੋਡ ਜੋ ਰੱਦ ਕਰਨਾ, ਟੈਸਟ ਕਰਨਾ ਜਾਂ ਸਮਝਣਾ ਮੁਸ਼ਕਲ ਹੁੰਦਾ।
Kotlin ਦਾ ਉਭਾਰ ਇੰਨ੍ਹਾਂ ਜ਼ਰੂਰਤਾਂ ਨਾਲ ਮਿਲ ਕੇ ਆਇਆ: ਡਿਫੌਲਟ ਪੈਟਰਨ ਜੋ UI ਥ੍ਰੇਡ ਨੂੰ ਰੋਕਣ, ਸਕ੍ਰੀਨ ਦੀ ਲਾਈਫਸਾਈਕਲ ਤੋਂ ਕੰਮ ਲੀਕ ਹੋਣ, ਜਾਂ ਫੇਲਿਯਰਾਂ ਨੂੰ ਚੁਪਚਾਪ ਗੁਆਉਣ ਨੂੰ ਔਖਾ ਬਣਾਉਂਦੇ ਹਨ।
ਅਹੰਕਾਰਪੂਰਕ ਤੌਰ 'ਤੇ, Kotlin ਕੋਈ ਸਾਫ-ਸਲੇਟ ਰੀਰਾਈਟ ਮੰਗ ਨਹੀਂ ਸਕਦੀ ਸੀ। JVM ਇਕੋਸਿਸਟਮ ਦਹਾਕਿਆਂ ਦੀ ਨਿਵੇਸ਼ ਦਰਸਾਉਂਦਾ ਹੈ: ਮੌਜੂਦਾ ਲਾਇਬ੍ਰੇਰੀਆਂ, ਬਿਲਡ ਸਿਸਟਮ, ਅਤੇ Java ਵਿਚ ਨਿਪੁੰਨ ਟੀਮਾਂ।
ਇਸ ਲਈ Kotlin ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਗਿਆ ਕਿ ਉਹ ਵਿਕਾਸਕਾਰਾਂ ਦੀ ਮੌਜੂਦਾ ਦੁਨੀਆ ਵਿੱਚ ਅਸਾਨੀ ਨਾਲ ਫਿੱਟ ਹੋ ਜਾਵੇ—JVM ਬਾਈਟਕੋਡ ਵਿੱਚ ਕੰਪਾਇਲ ਹੋਣਾ, Android Studio ਅਤੇ Gradle ਵਿੱਚ ਕੰਮ ਕਰਨਾ, ਅਤੇ Java ਨਾਲ ਇੰਟਰਓਪਰੇਬਿਲਿਟੀ ਦੇਣਾ ਤਾਂ ਜੋ ਟੀਮਾਂ ਫਾਇਲ-ਦਰ-ਫਾਇਲ ਅਪਨਾਉਣ ਸਕਣ ਬਿਨਾਂ ਵੱਡੇ ਮਾਈਗ੍ਰੇਸ਼ਨ 'ਤੇ ਦਾਅਵਾਂ ਲਗਾਏ।
Kotlin ਦਾ JVM ਇਕੋਸਿਸਟਮ ਵਿੱਚ ਸਭ ਤੋਂ ਤੇਜ਼ ਰਸਤਾ ਸਧਾਰਨ ਸੀ: ਇਸਨੇ ਟੀਮਾਂ ਨੂੰ Java ਛੱਡਣ ਦੀ ਮੰਗ ਨਹੀਂ ਕੀਤੀ। Kotlin ਸਧਾਰਨ JVM ਬਾਈਟਕੋਡ ਵਿੱਚ ਕੰਪਾਇਲ ਹੁੰਦਾ, ਉਹੀ ਲਾਇਬ੍ਰੇਰੀਆਂ ਵਰਤਦਾ, ਅਤੇ ਇੱਕੋ ਮੋਡੀਊਲ ਵਿੱਚ Java ਫਾਈਲਾਂ ਦੇ ਨਾਲ ਰਹਿ ਸਕਦਾ। "100% interoperability" ਦਾ ਸੁਨੇਹਾ ਅਡਾਪਸ਼ਨ ਖਤਰੇ ਨੂੰ ਘਟਾਉਂਦਾ ਸੀ ਕਿਉਂਕਿ ਮੌਜੂਦਾ ਕੋਡ, ਡੀਪੈਂਡੈਂਸੀਜ਼, ਬਿਲਡ ਟੂਲ ਅਤੇ ਡਿਵੈਲਪਰ ਹੁਨਰ ਤਗੜੇ ਰਹਿੰਦੇ ਸਨ।
ਅਸਲ Android ਕੋਡਬੇਸ ਵਿੱਚ, ਆਮ ਹੈ ਕਿ ਕਿਸੇ ਫੀਚਰ ਵਿੱਚ Java ਤੋਂ Kotlin ਅਤੇ Kotlin ਤੋਂ Java ਕਾਲ ਹੁੰਦੇ ਹਨ। Kotlin Java ਕਲਾਸਾਂ ਨੂੰ ਬਿਨਾਂ ਬਦਲਾਅ ਦੇ ਖਪਤ ਕਰ ਸਕਦਾ ਹੈ:
val user = UserRepository().findById("42") // UserRepository is Java
ਅਤੇ Java Kotlin ਨੂੰ ਕਾਲ ਕਰ ਸਕਦਾ ਹੈ, ਟਾਪ-ਲੇਵਲ ਫੰਕਸ਼ਨਾਂ (ਜਨਰੇਟ ਕੀਤੇ *Kt ਕਲਾਸਾਂ ਰਾਹੀਂ) ਅਤੇ ਨਿਰਮਲ ਕਲਾਸਾਂ ਸਮੇਤ:
String token = AuthKt.generateToken(userId); // generateToken is a Kotlin top-level function
ਇਹ mixing gradual migration ਨੂੰ ਪ੍ਰਾਇਕਟਿਕਲ ਬਣਾ ਦਿੰਦਾ: ਟੀਮ ਨਵੇਂ ਸਕ੍ਰੀਨਾਂ ਨੂੰ Kotlin ਵਿੱਚ ਲਿਖ ਕੇ ਸ਼ੁਰੂ ਕਰ ਸਕਦੀ ਹੈ, ਫਿਰ ਛੋਟੇ leaf ਕੰਪੋਨੈਂਟਾਂ ਨੂੰ ਕਨਵਰਟ ਕਰ ਸਕਦੀ ਹੈ, ਅਤੇ ਸਮੇਂ ਨਾਲ ਗਹਿਰੇ ਲੇਅਰਾਂ ਨੂੰ ਹਿਲਾ ਸਕਦੀ ਹੈ—ਬਿਨਾਂ ਕਿਸੇ "ਵੱਡੇ ਰੀਰਾਈਟ" ਦੀ ਲੋੜ ਦੇ।
ਇੰਟਰਓਪ ਸਦਾਬਹਾਰ ਹੈ, ਪਰ ਜਾਦੂ ਨਹੀਂ। ਮੁੱਖ friction-ਪੁਆਇੰਟ ਆਮ ਤੌਰ 'ਤੇ:
String! ਵਜੋਂ ਦਿਖ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਬਿਨਾਂ ਵੈਰੀਫਿਕੇਸ਼ਨ ਦੇ NullPointerException ਆ ਸਕਦਾ ਹੈ।@Nullable/@NonNull (ਜਾਂ JSpecify) ਵਰਤਦੇ ਹਨ ਤਾਂ Kotlin ਹੋਰ ਸੁਰੱਖਿਅਤ ਹੋ ਜਾਂਦਾ ਹੈ। ਉਹਨਾਂ ਦੇ ਬਿਨਾ, Kotlin ਨੱਲ ਸੇਫਟੀ ਲਾਗੂ ਨਹੀਂ ਕਰ ਸਕਦਾ।ਇੰਟਰਓਪਰੇਬਿਲਿਟੀ ਨੇ Kotlin ਨੂੰ ਸਿਰਫ਼ ਅਨੁਕੂਲ ਨਹੀਂ ਬਣਾਇਆ—ਇਸਨੇ ਅਪਨਾਉਣ ਨੂੰ ਵਾਪਸੀਯੋਗ, ਦਰਜਾਬੰਦੀ ਅਧਾਰ ਤੇ ਅਤੇ ਇਸ ਲਈ ਉਤਪਾਦਕ ਟੀਮਾਂ ਲਈ ਹਕੀਕਤੀ ਬਣਾਇਆ।
Kotlin ਦੀ ਪ੍ਰਭਾਵਸ਼ੀਲਤਾ ਇੱਕHEADLINE ਫੀਚਰ ਦਾ ਨਤੀਜਾ ਨਹੀਂ ਸੀ—ਇਹ ਲਗਾਤਾਰ ਉਹਨਾਂ ਛੋਟੀਆਂ, ਰੋਜ਼ਾਨਾ ਆਉਣ ਵਾਲੀਆਂ ਖਾਮੀਆਂ ਅਤੇ ਸ਼ੋਰ ਨੂੰ ਹਟਾਉਣ ਦਾ ਨਤੀਜਾ ਸੀ। ਰੋਜ਼ਾਨਾ ਕੋਡ ਛੋਟਾ ਹੋਇਆ, ਪਰ ਮਨੋਰਥ ਦੇ ਬਾਰੇ ਹੋਰ ਸਪਸ਼ਟ ਹੋ ਗਿਆ, ਜਿਸ ਨਾਲ ਇਸ ਨੂੰ ਰਿਵਿਊ ਕਰਨਾ ਅਤੇ ਬਦਲਣਾ ਸੁਰੱਖਿਅਤ ਹੋਇਆ।
Kotlin nullable ਅਤੇ non-nullable ਟਾਈਪਾਂ ਵਿਚ ਵੱਖ ਕੀਤnessa ਹੈ: String ਅਤੇ String? ਵੱਖ-ਵੱਖ ਹਨ। ਇਹ ਸਧਾਰਨ ਵੰਡ ਕਈ "ਨਲ ਚੈੱਕ ਭੁੱਲਣ" ਵਾਲੇ ਮੁੱਦਿਆਂ ਨੂੰ ਰਨ-ਟਾਈਮ ਤੋਂ ਕੰਪਾਇਲ-ਟਾਈਮ ਤੇ ਲੈ ਜਾਂਦੀ ਹੈ।
ਡਿਫੈਂਸਿਵ ਚੈਕਸ ਛਿੜਕੇ ਦੇਣ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਸਪਸ਼ਟ ਪੈਟਰਨਾਂ ਵੱਲ ਪ੍ਰੇਰਿਤ ਹੁੰਦੇ ਹੋ ਜਿਵੇਂ ?., ?:, ਅਤੇ let { } ਜਦੋਂ ਤੁਸੀਂ ਵਾਕਈ ਮਿਸਿੰਗ ਵੈਲਿਊ ਨੂੰ ਹੈਂਡਲ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ।
ਕੁਝ ਫੀਚਰ ਤੁਰੰਤ ਪ੍ਰਭਾਵ ਦਿਖਾਉਂਦੇ ਹਨ:
equals(), hashCode(), toString(), ਅਤੇ copy() ਆਪਣੇ ਆਪ ਜਨਰੇਟ ਕਰ ਦਿੰਦੇ ਹਨ, ਜੋ ਮਾਡਲਜ਼ ਵਿੱਚ ਹਥ-ਲਿਖੇ ਕੋਡ ਅਤੇ consistency ਦੀ ਘਾਟ ਘਟਾਉਂਦਾ ਹੈ।Extension functions ਤੁਹਾਨੂੰ ਮੌਜੂਦਾ ਟਾਈਪਾਂ 'ਤੇ ਯੂਟਿਲਿਟੀ ਮੈਥਡ ਜੋੜਨ ਦਿੰਦੀਆਂ ਹਨ ਬਿਨਾਂ ਉਹਨਾਂ ਨੂੰ ਸੋਧੇ। ਇਹ ਛੋਟੇ, ਖੋਜਯੋਗ ਹੈਲਪਰਾਂ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਦਾ ਅਤੇ ਇੱਥੇ-ਉਥੇ ਵਰਤੇ ਜਾਣ ਵਾਲੇ "Utils" ਕਲਾਸਾਂ ਤੋਂ ਬਚਾਉਂਦਾ।
ਡਿਫੌਲਟ arguments ਉਹਨਾਂ constructor ਅਤੇ method overloads ਨੂੰ ਹਟਾਉਂਦੇ ਜੋ ਸਿਰਫ਼ ਆਮ ਮੁੱਲ ਦਿੰਦੇ। Named parameters ਕਾਲਾਂ ਨੂੰ ਖਾਸ ਕਰਕੇ ਜਦ ਕਈ arguments ਇੱਕੋ ਟਾਈਪ ਦੇ ਹੋਵਨ ਤਾਂ ਸਵੈ-ਦਸਤਾਵੇਜ਼ੀ ਬਣਾਉਂਦੇ ਹਨ।
ਇਹ ਸਾਰੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ pull requests ਵਿੱਚ “ceremony” ਘਟਾਉਂਦੀਆਂ ਹਨ। ਰਿਵਿਊਅਰ ਹੁਣ ਦੁਹਰਾਏ ਪਲੰਬਿੰਗ ਨੂੰ ਵੈਧ ਕਰਨ 'ਤੇ ਘੱਟ ਸਮਾਂ ਲਾਉਂਦੇ ਅਤੇ ਵਿਹਾਰਕ ਲਾਜਿਕ 'ਤੇ ਜ਼ਿਆਦਾ ਧਿਆਨ ਦਿੰਦੇ—ਇਹ ਫਾਇਦਾ ਟੀਮਾਂ ਅਤੇ ਕੋਡਬੇਸ ਵਧਣ ਨਾਲੋਂ ਗੁਣਾ ਜਿਆਦਾ ਹੁੰਦਾ ਹੈ।
Kotlin ਨੇ ਕੋਡ ਨੂੰ ਆਧੁਨਿਕ ਮਹਿਸੂਸ ਕਰਵਾਇਆ ਜਦੋਂ ਭੀ ਇਹ ਸਧਾਰਨ JVM ਬਾਈਟਕੋਡ ਵਿੱਚ ਕੰਪਾਇਲ ਹੁੰਦਾ ਅਤੇ ਆਮ Java-ਅਧਾਰਿਤ ਬਿਲਡ ਅਤੇ ਡਿਪਲਾਇਮੈਂਟ ਸੈਟਅੱਪ ਵਿੱਚ ਫਿੱਟ ਹੁੰਦਾ।
ਸਭ ਤੋਂ ਵੱਡਾ ਬਦਲਾਅ ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਮੂੱਲ-ਮਾਨ (values) ਵਜੋਂ ਦੇਖਣਾ ਹੈ। ਛੋਟੀਆਂ, ਨਾਮਿਤ “listener” ਕਲਾਸਾਂ ਜਾਂ verbose anonymous implementation ਲਿਖਣ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਸਿੱਧਾ ਵਰਤੋਂ-ਪੁੱਜਾਰ ਫੰਕਸ਼ਨ ਪਾਸ ਕਰ ਸਕਦੇ ਹੋ।
ਇਹ UI ਅਤੇ ਇਵੈਂਟ-ਚਲਤ ਕੋਡ ਵਿੱਚ ਖਾਸ ਤੌਰ 'ਤੇ ਨਜ਼ਰ ਆਉਂਦਾ: lambdas ਮਨੋਰਥ ਨੂੰ ਸਪਸ਼ਟ ਕਰਦੀਆਂ ਹਨ ("ਇਹ ਹੋਣ 'ਤੇ ਇਹ ਕਰੋ") ਅਤੇ ਸੰਬੰਧਿਤ ਲਾਜਿਕ ਨੂੰ ਇੱਕਥੇ ਰੱਖਦੀਆਂ ਹਨ, ਜਿਸ ਨਾਲ ਫਲੋ ਸਮਝਣਾ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ।
ਕੁਝ Kotlin ਪੈਟਰਨ plain Java ਵਿੱਚ ਮਹਿੰਗੇ ਜਾਂ ਔਖੇ ਹੁੰਦੇ:
parse<T>() ਜਾਂ findView<T>() ਵਰਗੇ ਹੈਲਪਰ ਲਿਖ ਸਕੋ ਬਿਨਾਂ callers ਨੂੰ Class<T> ਹਮੇਸ਼ਾਂ ਪਾਸ ਕਰਨ ਦੇ।ਕਈ ਐਪ "ਸਟੇਟ" ਨੂੰ ਮਾਡਲ ਕਰਦੇ ਹਨ ਜਿਵੇਂ Loading/Success/Error। Java ਵਿੱਚ ਇਹ ਆਮ ਤੌਰ 'ਤੇ enums + ਜ਼ਿਆਦਾ ਫੀਲਡ ਜਾਂ inheritance ਨਾਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜਿਨ੍ਹਾਂ 'ਤੇ ਕੋਈ ਰੋਕ-ਟੋਕ ਨਹੀਂ ਹੁੰਦੀ।
Kotlin ਦੀ sealed classes ਤੁਹਾਨੂੰ ਇੱਕ ਬੰਦ ਸੰਭਾਵਨਾਵਾਂ ਦਾ ਸੈਟ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਦਿੰਦੀ ਹੈ। ਨਤੀਜਾ ਇਹ ਹੈ ਕਿ when ਬਿਆਨ exhaustive ਹੋ ਸਕਦਾ ਹੈ: ਕੰਪਾਇਲਰ ਤੁਹਾਨੂੰ ਚੇਤਾਵਨੀ ਦੇ ਸਕਦਾ ਹੈ ਜੇ ਤੁਸੀਂ ਕਿਸੇ ਸਟੇਟ ਨੂੰ ਹੈਂਡਲ ਕਰਨਾ ਭੁੱਲ ਗਏ—ਇਸ ਨਾਲ ਇਹ ਰੋਕਿਆ ਜਾ ਸਕਦਾ ਹੈ ਕਿ ਨਵੇਂ ਕੇਸ ਜੋੜਨ ਤੇ UI ਬਗ ਬਣਨ।
Kotlin ਸੰਦਰਭ ਤੋਂ ਟਾਈਪਾਂ ਅਨੁਮਾਨ ਲਾ ਸਕਦਾ ਹੈ, ਜੋ ਦੁਹਰਾਏ ਘਟਾਉਂਦਾ ਅਤੇ ਕੋਡ ਨੂੰ ਘੱਟ ਸ਼ੋਰਮਈ ਬਣਾਉਂਦਾ ਹੈ। ਚੰਗੀ ਤਰ੍ਹਾਂ ਵਰਤਣ 'ਤੇ ਇਹ ਪੜ੍ਹਨਯੋਗਤਾ ਨੂੰ ਸੁਧਾਰਦਾ ਹੈ।
ਸੰਤੁਲਨ ਇਹ ਹੈ ਕਿ ਜਦੋਂ ਇਨਫਰੈਂਸ ਮਹੱਤਵਪੂਰਨ ਜਾਣਕਾਰੀ ਲੁਕਾ ਸਕਦੀ ਹੈ—ਖਾਸਨੁਮਾ ਪਬਲਿਕ API ਹੱਦਾਂ 'ਤੇ—ਤਾਂ ਟਾਈਪਾਂ ਸਪਸ਼ਟ ਰੱਖਣੀ ਚਾਹੀਦੀ ਹੈ ਤਾਂ ਜੋ ਅਗਲਾ ਵਿਅਕਤੀ ਕੋਡ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਸਮਝ ਸਕੇ।
Android 'ਤੇ async ਕੰਮ ਅਟਲ ਹਨ। UI ਥ੍ਰੇਡ ਨੂੰ ਪ੍ਰਭਾਵਤ ਕੀਤੇ ਬਗੈਰ ਐਪ ਨੂੰ ਜਵਾਬਦੇਹ ਰੱਖਣਾ ਲਾਜ਼ਮੀ ਹੈ ਜਦੋਂ ਐਪ ਡੇਟਾ ਫ਼ੈਚ ਕਰਦਾ, ਸਟੋਰੇਜ ਪੜ੍ਹਦਾ/ਲਿਖਦਾ, ਇਮੇਜ ਡਿਕੋਡ ਕਰਦਾ, ਜਾਂ ਸੈਂਸਰ/ਲੋਕੇਸ਼ਨ ਕਾਲ ਕਰਦਾ। Coroutines ਇਸ ਰੋਜ਼ਾਨਾ ਹਕੀਕਤ ਨੂੰ "ਥ੍ਰੇਡ ਮੈਨੇਜਮੈਂਟ" ਵਾਂਗ ਨਹੀਂ ਪਰ ਸਿੱਧੀ, ਕ੍ਰਮਿਕ ਕੋਡ ਵਾਂਗ ਮਹਿਸੂਸ ਕਰਵਾ ਦਿੱਤਾ।
Coroutines ਤੋਂ ਪਹਿਲਾਂ, ਡਿਵੈਲਪਰਾਂ ਅਕਸਰ callback chains ਨਾਲ ਗੁੰਝਲ ਵਿੱਚ ਫਸ ਜਾਂਦੇ ਸਨ: ਪੜ੍ਹਨ ਵਿੱਚ ਔਖਾ, ਟੈਸਟ ਕਰਨਾ ਔਖਾ, ਅਤੇ ਐਰਰ ਮੱਧ-ਫਲੋ ਵਿੱਚ ਹੋਣ 'ਤੇ ਟੁੱਟਣਾ ਆਸਾਨ। Coroutines ਤੁਹਾਨੂੰ asynchronous ਲਾਜਿਕ ਸਿੱਧੀ ਕ੍ਰਮਿਕ ਸ਼ੈਲੀ ਵਿੱਚ ਲਿਖਣ ਦਿੰਦੀਆਂ ਹਨ: ਰਿਕਵੇਸਟ ਕਰੋ, ਨਤੀਜਾ ਪਾਰਸ ਕਰੋ, ਸਟੇਟ ਅਪਡੇਟ ਕਰੋ—ਫਿਰ ਭੀ ਇਹ ਬੈਕਗਰਾਉਂਡ 'ਤੇ ਚੱਲਦਾ ਰਹਿੰਦਾ ਹੈ।
ਐਰਰ ਹੈਂਡਲਿੰਗ ਵੀ ਹੋਰ ਇਕਸਾਰ ਹੋ ਜਾਂਦੀ ਹੈ। ਕਈ ਕਾਲਬੈਕਸ ਵਿੱਚ ਸਫਲਤਾ ਅਤੇ ਨਾਕਾਮੀ ਵੱਖ-ਵੱਖ ਥਾਂ ਤਾਂ ਵੰਡ ਜਾਂਦੀ ਸੀ, ਪਰ ਹੁਣ ਤੁਸੀਂ ਆਮ try/catch ਵਰਤ ਕੇ ਇਨੁ ਕੇਂਦਰਿਤ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ retries, fallbacks ਅਤੇ ਲੌਗਿੰਗ ਹੋਰ ਸਾਫ਼ ਤਰੀਕੇ ਨਾਲ ਨਿਭਾ ਸਕਦੇ ਹੋ।
Coroutines ਸਿਰਫ਼ "ਹਲਕੇ ਥ੍ਰੇਡ" ਨਹੀਂ ਹਨ। ਵੱਡਾ ਬਦਲਾਅ structured concurrency ਹੈ: ਕੰਮ ਕਿਸੇ ਸਕੋਪ ਦਾ ਹਿੱਸਾ ਹੁੰਦਾ ਹੈ ਅਤੇ ਸਕੋਪ ਰੱਦ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। Android 'ਤੇ ਇਹ ਮਤਲਬ ਰੱਖਦਾ ਹੈ ਕਿ ਸਕ੍ਰੀਨਜ਼ ਅਤੇ view models ਦੀਆਂ lifecycle ਹੁੰਦੀਆਂ—ਜੇ ਉਪਭੋਗਤਾ ਦੂਰ ਚੱਲ ਜਾਵੇ ਤਾਂ ਸੰਬੰਧਤ ਕੰਮ ਰੁੱਕ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
ਸਕੋਪਡ coroutines ਨਾਲ ਰੱਦ ਆਪਣੇ-ਆਪੇ ਫੈਲਦੀ ਹੈ, ਜੋ ਨਵੇਂ ਕੰਮ ਨੂੰ ਬਚਾਉਂਦੀ ਹੈ, memory leaks ਘਟਾਉਂਦੀ ਹੈ, ਅਤੇ "UI ਹੋਣ ਤੋਂ ਬਾਦ ਅਪਡੇਟ" ਵਾਲੇ ਕਰੈਸ਼ ਰੋਕਦੀ ਹੈ।
ਕਈ Android ਲਾਇਬ੍ਰੇਰੀਆਂ coroutine-friendly APIs ਦਿੰਦੀਆਂ ਹਨ: networking, databases, ਅਤੇ background work suspend ਫੰਕਸ਼ਨਾਂ ਜਾਂ ਮੁੱਲਾਂ ਦੀਆਂ ਸਟ੍ਰੀਮਾਂ ਵਜੋਂ ਮੁਹੱਈਆ ਕਰ ਸਕਦੀਆਂ ਹਨ। ਅਰਥਾਤ, ਤੁਸੀਂ operations (fetch → cache → display) ਬਿਨਾਂ ਘੁਮਾਫਿਰ ਕੇ ਜੋੜ ਸਕਦੇ ਹੋ।
Coroutines request/response flows, ਅਜ਼ਾਦ ਟਾਸਕਾਂ ਦੀ ਪੈਰਲਲਾਈਜ਼ੇਸ਼ਨ, ਅਤੇ UI ਇਵੈਂਟਾਂ ਨੂੰ ਬੈਕਗਰਾਊਂਡ ਕੰਮ ਨਾਲ ਜੋੜਨ ਵਿੱਚ ਚਮਕਦਾਰ ਹਨ। ਗਲਤ ਵਰਤੋਂ ਤਦ ਹੋਂਦੀ ਹੈ ਜਦ ਭਾਰੇ CPU ਕੰਮ ਮੈਨ ਥ੍ਰੇਡ 'ਤੇ ਰਹਿੰਦਾ ਹੈ, ਜਦ ਸਕੋਪ UI ਤੋਂ ਲੰਮਾ ਜੀਵਿਤ ਰਹਿੰਦਾ ਹੈ, ਜਾਂ ਜਦ ਡਿਵੈਲਪਰਾਂ “fire-and-forget” ਜ਼ਾਬਾਂ ਲਾਂਚ ਕਰਦੇ ਬਿਨਾਂ ਮਲਕੀਅਤ ਜਾਂ ਰੱਦ ਦੇ ਸਪਸ਼ਟ ਨਿਯਮ ਦੇ।
Kotlin ਲਫ਼ਜ਼ਾਂ ਦੇ ਕਰਣ ਨਹੀਂ ਫੈਲਿਆ—ਇਹ ਇਸ ਲਈ ਫੈਲਿਆ ਕਿਉਂਕਿ ਇਸ ਨੂੰ ਉਹਨਾਂ ਟੂਲਾਂ ਵਿੱਚ "ਦੇਸੀ" ਮਹਿਸੂਸ ਹੋਇਆ ਜੋ ਡਿਵੈਲਪਰ ਪਹਿਲਾਂ ਹੀ ਵਰਤਦੇ ਸਨ। ਮਜ਼ਬੂਤ ਐਡੀਟਰ ਸਪੋਰਟ ਅਪਨਾਉਣ ਨੂੰ ਘੱਟ-ਖਤਰੇ ਵਾਲਿਆ ਕਦਮਾਂ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ ਨਾ ਕਿ ਵਿਘਟਨ-ਪੂਰਨ ਰੀਰਾਈਟ ਵਿੱਚ।
Android Studio ਅਤੇ IntelliJ ਨੇ Kotlin ਸਪੋਰਟ ਦਿੱਤੀ ਜੋ ਸਿਰਫ਼ ਹਾਈਲਾਈਟਿੰਗ ਤੋਂ ਵੱਧ ਸੀ। Autocomplete Kotlin idioms ਨੂੰ ਸਮਝਦਾ, quick-fixes ਸੁਰੱਖਿਅਤ ਪੈਟਰਨ ਸੁਝਾਉਂਦੇ, ਅਤੇ navigation ਮਿਕਸਡ Java/Kotlin ਪ੍ਰੋਜੈਕਟਾਂ 'ਚ ਸਾਫ਼ ਕੰਮ ਕਰਦੀ। ਟੀਮਾਂ ਇਕ-ਫਾਇਲ-ਦਰ-ਇੱਕ-ਫਾਇਲ Kotlin ਲਗਾਉ ਸਕਦੀਆਂ ਸਨ ਬਿਨਾਂ ਰੋਜ਼ਾਨਾ ਕੰਮ ਰੁਕਣ ਦੇ।
ਦੋ ਫੀਚਰਾਂ ਨੇ ਘੱਟ ਦਰੜਤਾ ਹਟਾਈ:
ਕਨਵਰter ਪੂਰਨ ਨਹੀਂ ਹੈ, ਪਰ ਇਹ ਇੱਕ ਫਾਇਲ ਦਾ 70–80% ਤਕ ਜਲਦੀ ਮਾਈਗ੍ਰੇਟ ਕਰਨ ਲਈ ਵਧੀਆ ਹੈ, ਫਿਰ ਡਿਵੈਲਪਰ IDE hints ਨਾਲ ਸਟਾਈਲ ਅਤੇ ਨਲਬਲਟੀ ਸੁਧਾਰ ਸਕਦਾ ਹੈ।
ਕਈ ਟੀਮਾਂ ਨੇ Gradle Kotlin DSL ਵੀ ਅਪਨਾਇਆ ਕਿਉਂਕਿ ਇਹ ਬਿਲਡ ਸਕ੍ਰਿਪਟਾਂ ਵਿੱਚ autocomplete, ਸੁਰੱਖਿਅਤ ਰੀਫੈਕਟਰ ਅਤੇ ਘੱਟ "stringly-typed" ਗਲਤੀਆਂ ਲਿਆਉਂਦਾ ਹੈ। ਜੇਕਰ ਪ੍ਰੋਜੈਕਟ Groovy ਰੱਖਦਾ ਵੀ ਹੋਵੇ, Kotlin DSL ਵੱਡੇ ਬਿਲਡਾਂ ਲਈ ਪੜ੍ਹਨਯੋਗਤਾ ਅਤੇ ਟੂਲਿੰਗ ਫੀਡਬੈਕ ਲਈ ਜ਼ਿਆਦਾ ਮਨਪਸੰਦ ਹੋ ਸਕਦਾ ਹੈ।
ਟੂਲਿੰਗ ਦੀ ਪੱਕੜ CI ਵਿੱਚ ਦੇਖੀ ਗਈ: incremental compilation, build caching, ਅਤੇ ਬਿਹਤਰ ਡਾਇਗਨੋਸਟਿਕਸ ਨੇ Kotlin builds ਨੂੰ ਸਕੇਲ ਤੇ predictably ਬਣਾਇਆ। ਟੀਮਾਂ ਨੇ compile ਸਮੇਂ ਉਤੇ ਨਜ਼ਰ ਰੱਖਣਾ ਸਿੱਖਿਆ, caching ਚਾਲੂ ਕੀਤੀ, ਅਤੇ dependencies ਸਾਫ਼ ਰੱਖ ਕੇ ਬੇਵਰਜ਼ਤ recompiles ਤੋਂ ਬਚਿਆ।
Kotlin JUnit ਅਤੇ ਪ੍ਰਸਿੱਧ mocking ਲਾਇਬ੍ਰੇਰੀਆਂ ਨਾਲ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦਾ ਹੈ, ਅਤੇ ਟੈਸਟ ਲਿਖਣਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ (ਸਪਸ਼ਟ ਨਾਂ, ਘੱਟ ਬੋਇਲੇਰਪਲੇਟ ਸੈਟਅੱਪ)। ਨਤੀਜਾ ਇਹ ਨਹੀਂ ਕਿ "ਟੈਸਟਿੰਗ ਵੱਖਰੀ ਹੋ ਗਈ"—ਸਗੋਂ ਟੈਸਟ ਤੇਜ਼ੀ ਨਾਲ ਲਿਖੇ ਅਤੇ ਆਸਾਨੀ ਨਾਲ ਮੈਨਟੇਨ ਹੋਣ ਲੱਗੇ।
Kotlin ਓਧੋ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਸੀ, ਪਰ Google ਦੇ ਸਹਿਯੋਗ ਨੇ ਇਸ ਫੈਸਲੇ ਨੂੰ "ਦਿਲਚਸਪ ਵਿਕਲਪ" ਤੋਂ "ਸੁਰੱਖਿਅਤ ਡਿਫੌਲਟ" ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ। ਕਈ ਟੀਮਾਂ ਲਈ, ਇਹ ਸਿਗਨਲ ਕਿਸੇ ਭਾਸ਼ਾ ਫੀਚਰ ਤੋਂ ਵੀ ਵੱਧ ਮਹੱਤਵ ਰੱਖਦਾ ਸੀ।
ਸਰਕਾਰੀ ਸਹਿਯੋਗ ਦਾ ਮਤਲਬ ਸੀ ਕਿ Kotlin ਨੂੰ Android ਦੇ ਮੁੱਖ ਵਰਕਫਲੋ ਵਿੱਚ ਪਹਿਲ-ਕਲਾਸ ਨਾਗਰਿਕ ਮੰਨਿਆ ਗਿਆ: Android Studio templates, Lint checks, ਬਿਲਡ ਟੂਲਿੰਗ, ਅਤੇ ਪਲੇਟਫਾਰਮ ਗਾਈਡੈਂਸ ਇਹ ਉਮੀਦ ਕਰਦੇ ਰਹੇ ਕਿ Kotlin ਵਰਤੇ ਜਾਏਗਾ—ਸਿਰਫ਼ ਬਰਦਾਸ਼ਤ ਨਹੀਂ ਕੀਤਾ ਜਾਵੇ।
ਇਸਦਾ ਮਤਲਬ clearer documentation ਵੀ ਸੀ। ਜਦ Android ਦੀ ਆਪਣੀ ਡੌਕਸ ਅਤੇ ਨਮੂਨੇ Kotlin ਨੂੰ ਡਿਫੌਲਟ ਵਜੋਂ ਦਿਖਾਉਂਦੇ ਹਨ, ਟੀਮਾਂ Java ਉਦਾਹਰਣਾਂ ਦਾ ਅਨੁਵਾਦ ਕਰਨ ਜਾਂ ਸਰਵੋਤਮ ਅਭਿਆਸਾਂ ਦਾ ਅਨੁਮਾਨ ਲਗਾਉਣ ਵਿੱਚ ਘੱਟ ਸਮਾਂ ਗੁਆਉਂਦੀਆਂ ਹਨ।
ਜਦ Kotlin ਸਿਫਾਰਸ਼ੀ ਰਸਤਾ ਬਣ ਗਿਆ, ਇਹ ਇੱਕ ਨਿਛਲ ਨਹੀਂ ਰਹਿ ਗਿਆ। ਉਮੀਦਵਾਰ ਮਿਆਰੀ Android ਡੌਕਸ, ਅਧਿਕਾਰਕ codelabs, ਅਤੇ ਵਿਆਪਕ ਲਾਇਬ੍ਰੇਰੀਆਂ ਨੂੰ ਆਪਣੀ ਤਜਰਬੇ ਦੀ ਸਾਂਝ ਵਜੋਂ ਦਿਖਾ ਸਕਦੇ ਸਨ। ਕੰਪਨੀਆਂ ਲਈ ਵੀ ਫਾਇਦਾ: onboarding ਆਸਾਨ ਹੋਇਆ, ਰਿਵਿਊ ਇੱਕਸਾਰ ਹੋਏ, ਅਤੇ "ਕੌਣ ਇਹ ਭਾਸ਼ਾ ਜਾਣਦਾ ਹੈ?" ਵਾਂਗ ਸਵਾਲ ਖਤਰੇ ਵਾਲਾ ਨਹੀਂ ਰਿਹਾ।
Android ਦਾ endorsement ਇਹ ਭੀ ਦਰਸਾਉਂਦਾ ਸੀ ਕਿ ਅਨੁਕੂਲਤਾ ਅਤੇ ਲੰਬੇ ਸਮੇਂ ਦਾ ਸਮਰਥਨ ਉਮੀਦਯੋਗ ਹੈ। Kotlin ਦਾ ਵਿਕਾਸ ਪ੍ਰਾਗਮੈਟਿਕ ਬਦਲਾਅ, ਮਜ਼ਬੂਤ ਟੂਲਿੰਗ, ਅਤੇ ਬੈਕਵਰਡ ਕੰਪੈਟਬਿਲਟੀ 'ਤੇ ਜ਼ੋਰ ਦਿੰਦਾ ਹੈ—ਜੋ ਬਿਜ਼ਨਸਾਂ ਲਈ ਇਸ ਡਰ ਨੂੰ ਘਟਾਉਂਦਾ ਕਿ ਕੋਈ ਨਵਾਂ ਵਰਜਨ ਇੱਕ ਦਰਦਨਾਕ ਰੀਰਾਈਟ ਮੰਗ ਜਾਵੇ।
ਬਹੁਤ ਸਾਰੀਆਂ JVM ਭਾਸ਼ਾਵਾਂ ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਯੋਗਯ ਹਨ, ਪਰ ਪਲੇਟਫਾਰਮ-ਸਤਰ ਦੇ ਬੈਕਿੰਗ ਤੋਂ ਬਿਨਾਂ ਉਹ ਵੱਧ ਵੱਡਾ ਜੂਆ ਲੱਗਦੇ ਹਨ। ਅਧਿਕਾਰਕ Android ਸਹਿਯੋਗ ਨੇ ਉਹ ਅਣਸੁਨੀ ਸ਼ੱਕ ਨੂੰ ਘਟਾਇਆ: ਸਾਫ਼ ਅੱਪਗ੍ਰੇਡ ਰਸਤੇ, ਘੱਟ ਹੈਰਾਨੀ, ਅਤੇ ਯਕੀਨ ਕਿ ਲਾਇਬ੍ਰੇਰੀਆਂ, ਨਮੂਨੇ, ਅਤੇ ਟੂਲਿੰਗ ਰਫ਼ਤਾਰ ਰੱਖਣਗੇ।
Kotlin ਨੇ ਸਿਰਫ਼ Android ਕੋਡ ਨੂੰ ਸੁੰਦਰ ਨਹੀਂ ਬਣਾਇਆ—ਇਹਨੂੰ Android ਦੇ APIs ਅਤੇ ਲਾਇਬ੍ਰੇਰੀਆਂ ਨੂੰ ਵੀ ਜ਼ਿਆਦਾ ਪ੍ਰਗਟਭਾਸ਼ਾ-ਅਨੁਕੂਲ ਬਣਾਉਣ ਲਈ ਪ੍ਰੇਰਿਤ ਕੀਤਾ। ਜਿਵੇਂ-ਜਿਵੇਂ ਅਪਨਾਉਣ ਵਧਿਆ, ਪਲੇਟਫਾਰਮ ਟੀਮ ਅਤੇ ਲਾਇਬ੍ਰੇਰੀ ਲੇਖਕ Kotlin ਦੀਆਂ ਤਾਕਤਾਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖ ਕੇ APIs ਡਿਜ਼ਾਈਨ ਕਰਨ ਲੱਗੇ: extension functions, default parameters, named arguments, ਅਤੇ ਮਜ਼ਬੂਤ ਟਾਈਪ ਮਾਡਲਿੰਗ।
Android KTX ਅਸਲ ਵਿੱਚ Kotlin extensions ਦਾ ਸੈੱਟ ਹੈ ਜੋ ਮੌਜੂਦਾ Android ਅਤੇ Jetpack APIs ਨੂੰ Kotlin ਵਿੱਚ ਕੁਦਰਤੀ ਮਹਿਸੂਸ ਕਰਵਾਂਦਾ ਹੈ।
ਵਰਤੋਂ ਦੀ ਭਾਰੀ ਜਟਿਲਤਾ (builders, listeners, utility classes) ਦੀ ਜਗ੍ਹਾ, KTX ਇੰਨਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ:
ਉੱਚ-ਪੱਧਰੀ ਪ੍ਰਭਾਵ "ਘੱਟ scaffolding" ਹੈ। ਤੁਸੀਂ ਘੱਟ ਲਾਈਨਾਂ ਵਿੱਚ ਸੈਟਅੱਪ ਕਰਦੇ ਹੋ ਅਤੇ ਜ਼ਿਆਦਾ ਲਾਈਨਾਂ ਉਨ੍ਹਾਂ ਗੱਲਾਂ ਲਈ ਜੋ ਤੁਸੀਂ ਕਰਵਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ।
Jetpack ਲਾਇਬ੍ਰੇਰੀਆਂ ਹੌਲੀ-ਹੌਲੀ Kotlin ਵਰਤੋਂ ਨੂੰ ਮਨਨ ਕਰਦੀਆਂ ਹਨ—ਖ਼ਾਸ ਕਰਕੇ API ਕਿਵੇਂ ਐਕਸਪੋਜ਼ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ।
Lifecycle-aware components, navigation, ਅਤੇ paging ਆਮ ਤੌਰ 'ਤੇ Kotlin ਦੇ concise lambdas, ਮਜ਼ਬੂਤ ਟਾਈਪਿੰਗ, ਅਤੇ ਸਟੀਟ ਅਤੇ ਇਵੈਂਟਾਂ ਦੀ بہتر ਮਾਡਲਿੰਗ ਨਾਲ ਢੰਗ ਨਾਲ ਜੁੜਦੇ ਹਨ। ਇਹ ਸਿਰਫ਼ ਬੋਇਲੇਰਪਲੇਟ ਘਟਾਉਂਦਾ ਹੀ ਨਹੀਂ; ਇਹ ਸਾਫ਼ ਐਪ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਦਾ ਕਿਉਂਕਿ ਲਾਇਬ੍ਰੇਰੀਆਂ explicit, well-typed ਡੇਟਾ ਫਲੋਜ਼ ਨੂੰ ਇਨਾਮ ਦਿੰਦੀਆਂ ਹਨ।
Jetpack Compose ਉਹ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ Kotlin ਦਾ ਪ੍ਰਭਾਵ ਸਭ ਤੋਂ ਸਪੱਸ਼ਟ ਹੈ। Compose UI ਨੂੰ ਸਟੀਟ ਦਾ ਫੰਕਸ਼ਨ ਮੰਨਦਾ ਹੈ, ਅਤੇ Kotlin ਇਸ ਸ਼ੈਲੀ ਲਈ ਬਿਲਕੁਲ ਯੋਗ ਹੈ:
Compose XML ਫਾਈਲਾਂ ਅਤੇ view wiring ਤੋਂ complexity ਨੂੰ ਦੂਰ ਕਰਦਾ ਹੈ ਅਤੇ Kotlin ਕੋਡ ਵੱਲ ਜ਼ਿਆਦਾ ਸੁਚਾਰੇ ਰੂਪ ਵਿੱਚ ਸੰਕੁਚਿਤ ਕਰਦਾ ਹੈ—ਜੋ refactor, ਟੈਸਟ ਅਤੇ ਰੱਖ-ਰਖਾਅ ਲਈ ਆਸਾਨ ਹੈ।
Kotlin ਸਪਸ਼ਟ मॉडलਿੰਗ ਨਾਲ state-driven UIs ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਦਾ:
ਜਦ UI ਸਟੇਟ ਇਸ ਤਰ੍ਹਾਂ ਮਾਡਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ "ਅਸੰਭਵ ਸਟੇਟ" ਘੱਟ ਹੁੰਦੇ ਹਨ—ਇਹ crashes ਅਤੇ ajeeb UI ਵਿਹਾਰ ਦਾ ਆਮ ਸਰੋਤ ਹੈ।
KTX + Jetpack + Compose ਨਾਲ Kotlin Android ਵਿਕਾਸ ਨੂੰ ਪ੍ਰੇਰਿਤ ਕਰਦਾ ਹੈ ਕਿ ਉਹ declarative, state-driven UI ਅਤੇ ਲਾਇਬ੍ਰੇਰੀ-ਪ੍ਰੇਰਿਤ ਆਰਕੀਟੈਕਚਰ ਵੱਲ ਵਧੇ। ਨਤੀਜਾ: ਘੱਟ glue code, ਘੱਟ ਨਲ-ਸੰਬੰਧੀ ਝੰਜਟ, ਅਤੇ UI ਕੋਡ ਜੋ ਸਕ੍ਰੀਨ ਦੇ ਵਰਣਨ ਵਾਂਗ ਪੜ੍ਹਾਈ ਦੇ ਤਰੀਕੇ ਨਾਲ ਜਿਆਦਾ ਸਦृਸ਼ ਹੁੰਦਾ ਹੈ।
Kotlin ਸਿਰਫ਼ Android ਐਪਸ ਨੂੰ ਆਸਾਨ ਬਣਾਉਣ ਤੱਕ ਸੀਮਿਤ ਨਹੀਂ ਰਿਹਾ। ਇਸਨੇ ਵਿਆਪਕ JVM ਇਕੋਸਿਸਟਮ ਨੂੰ ਵੀ ਮਜ਼ਬੂਤ ਕੀਤਾ—ਟੀਂਮਾਂ ਨੂੰ ਇੱਕ ਆਧੁਨਿਕ ਭਾਸ਼ਾ ਦਿੱਤੀ ਜੋ ਹਰ ਥਾਂ Java ਚੱਲਦੀ ਹੈ—ਸਰਵਰ, ਡੈਸਕਟਾਪ ਐਪ, ਅਤੇ ਬਿਲਡ ਟੂਲਿੰਗ—ਬਿਨਾਂ "ਦੁਨੀਆਂ ਨੂੰ ਰੀਰਾਈਟ" ਕਰਨ ਦੀ ਲੋੜ ਦੇ।
JVM 'ਤੇ, Kotlin ਬੈਕਐਂਡ ਸਰਵਿਸਿਜ਼ ਲਈ ਅਕਸਰ ਵਰਤੀ ਜਾਂਦੀ ਹੈ Java ਲਾਇਬ੍ਰੇਰੀਆਂ ਅਤੇ ਫਰੇਮਵਰਕਾਂ ਨਾਲ। ਕਈ ਟੀਮਾਂ ਲਈ sangਠਨਾਤਮਕ ਜਿੱਤ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ Android ਅਤੇ ਸਰਵਰ ਕੋਡ 'ਤੇ ਇੱਕੋ ਭਾਸ਼ਾ standardize ਕਰ ਸਕਦੇ ਹੋ, conventions ਸਾਂਝੇ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਹੁਨਰ reuse ਕਰ ਸਕਦੇ ਹੋ—ਫਿਰ ਭੀ ਮੈਚੁਰ Java ਇਕੋਸਿਸਟਮ 'ਤੇ ਨਿਰਭਰ ਰਹਿ ਸਕਦੇ ਹੋ।
Kotlin Multiplatform ਤੁਹਾਨੂੰ ਇੱਕੋ ਕੋਡ ਦੇ ਕੁਝ ਹਿੱਸਿਆਂ ਨੂੰ ਇਕ ਵਾਰੀ ਲਿਖ ਕੇ ਕਈ ਟਾਰਗਟ (Android, iOS, ਡੈਸਕਟਾਪ, ਵੈੱਬ) 'ਤੇ ਵਰਤਣ ਦੀ ਆਜ਼ਾਦੀ ਦਿੰਦਾ ਹੈ, ਜਦਕਿ ਹਰ ਪਲੇਟਫਾਰਮ ਲਈ ਅਜੇ ਵੀ ਨੈਟਿਵ ਐਪ ਬਣਦਾ ਹੈ।
ਇਸਨੂੰ ਐਪ ਦਾ "ਦਿਮਾਗ" ਸਾਂਝਾ ਕਰਨ ਵਜੋਂ ਸੋਚੋ—ਸਾਰੀ ਐਪ ਸਾਂਝੀ ਨਹੀਂ ਹੁੰਦੀ। ਤੁਹਾਡੀ UI ਨੈਟਿਵ ਰਹਿੰਦੀ ਹੈ (Android UI Android 'ਤੇ, iOS UI iOS 'ਤੇ), ਪਰ ਸਾਂਝਾ ਕੋਡ ਵਿਚ ਸ਼ਾਮਲ ਹੋ ਸਕਦਾ ਹੈ:
ਕਿਉਂਕਿ Android ਪਹਿਲਾਂ ਹੀ JVM 'ਤੇ ਚਲਦਾ ਹੈ, KMP ਇੱਕ ਕੁਦਰਤੀ ਵਧੋ ਹੋ ਸਕਦਾ ਹੈ: ਤੁਸੀਂ JVM-ਇੰਗਲ-ਫ੍ਰੇਂਡਲੀ ਕੋਡ ਰੱਖਦੇ ਹੋ ਜਿੱਥੇ ਮਾਇਲਡ ਹੁੰਦਾ ਹੈ ਅਤੇ ਉਹ ਬਿੰਦੂ ਜਿੱਥੇ ਪਲੇਟਫਾਰਮ ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ ਉਹਨਾਂ 'ਤੇ_BRANCH ਕਰਦੇ ਹੋ।
KMP ਸਮਾਂ ਬਚਾ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਜੁਟਿਲਤਾ ਵੀ ਵਧਾਉਂਦਾ ਹੈ:
KMP ਵਧੀਆ ਫਿੱਟ ਹੈ ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਪੈਰਾਲਲ Android + iOS ਐਪ ਹਨ, ਸਾਂਝੇ ਪ੍ਰੋਡਕਟ ਨਿਯਮ ਹਨ, ਅਤੇ ਇੱਕ ਟੀਮ ਸਾਂਝੀ ਆਰਕੀਟੈਕਚਰ ਵਿੱਚ ਨਿਵੇਸ਼ ਕਰਨ ਲਈ ਤਿਆਰ ਹੈ। ਜੇ ਤੁਹਾਡਾ ਰੋਡਮੇਪ Android-ਫਰਸਟ ਹੈ, ਤੁਹਾਡੀ ਐਪ UI-ਭਾਰ ਹੈ ਜਿਸ ਵਿੱਚ ਘੱਟ ਸਾਂਝਾ ਲਾਜਿਕ ਹੈ, ਜਾਂ ਤੁਹਾਨੂੰ ਤੁਰੰਤ ਵਿਆਪਕ ਪਲੇਟਫਾਰਮ-ਖਾਸ ਲਾਇਬ੍ਰੇਰੀਆਂ ਦੀ ਜ਼ਰੂਰਤ ਹੈ, ਤਾਂ ਸਿਰਫ़ Android 'ਤੇ ਰਹਿਣਾ ਵਧੀਆ ਹੋ ਸਕਦਾ ਹੈ।
Kotlin ਇੱਕ ਵੱਡੀ ਪ੍ਰੋਡਕਟੀਵਿਟੀ ਜਿੱਤ ਹੈ, ਪਰ ਇਹ "ਮੁਫ਼ਤ" ਨਹੀਂ ਹੈ। ਜਿੱਥੇ ਤੇਜ਼-ਧਾਰ ਵਾਲੇ ਕਿਨਾਰੇ ਹਨ ਉਹ ਜਾਣਨਾ ਤੁਹਾਨੂੰ ਕੋਡ ਪੜ੍ਹਨਯੋਗ, ਤੇਜ਼ ਅਤੇ ਰੱਖ-ਰਖਾਅ ਵਿੱਚ ਆਸਾਨ ਰੱਖਣ ਵਿੱਚ ਮਦਦ ਕਰੇਗਾ—ਖ਼ਾਸ ਕਰਕੇ Java-ਤੋਂ-Kotlin ਟ੍ਰਾਂਜ਼ੀਸ਼ਨ ਦੌਰਾਨ।
ਜ਼ਿਆਦਾਤਰ ਐਪਾਂ ਵਿੱਚ, Kotlin ਪ੍ਰਦਰਸ਼ਨ Java ਦੇ ਕੰਮ ਦੇ ਮਿਆਰ ਦੇ ਨੇੜੇ ਹੁੰਦੀ ਹੈ ਕਿਉਂਕਿ ਇਹ JVM ਬਾਈਟਕੋਡ ਵਿੱਚ ਕੰਪਾਇਲ ਹੁੰਦੀ ਅਤੇ ਉਹੀ ਰਨਟਾਈਮ ਵਰਤਦੀ ਹੈ। ਫਰਕ ਆਮ ਤੌਰ 'ਤੇ ਇਸ 'ਤੇ ਆਉਂਦੇ ਹਨ ਕਿ ਤੁਸੀਂ Kotlin ਕਿਵੇਂ ਲਿਖਦੇ ਹੋ:
ਨਿਯਮ-ਹਾਥ: idiomatic Kotlin ਲਿਖੋ, ਫਿਰ ਮਾਪੋ। ਜੇ ਕੁਝ ਧੀਮਾ ਹੋ ਰਿਹਾ ਹੈ, ਤਾਂ ਖ਼ਾਸ ਬੋਤਲ-ਨੇਕ ਨੂੰ optimize ਕਰੋ ਨਾ ਕਿ "Kotlin ਤੋਂ ਬਚੋ"।
Kotlin concise ਕੋਡ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਦਾ ਹੈ, ਜੋ ਟੀਮਾਂ ਨੂੰ "ਪਜ਼ਲ Kotlin" ਵੱਲ ਖਿੱਚ ਸਕਦਾ ਹੈ। ਦੋ ਆਮ ਮੁੱਦੇ:
let, run, apply, also, with) ਦੀ ਬੇਹਦ ਵਰਤੋਂ ਜਦੋਂ ਤੱਕ ਕੰਟਰੋਲ ਫਲੋ follows
ਥੀਕ ਨਹੀਂ ਰਹਿੰਦਾਸਪਸ਼ਟਤਾ ਨੂੰ ਤਰਜੀਹ ਦਿਓ: complex expressions ਨੂੰ ਨਾਮੀ ਅਤੇ ਛੋਟੇ ਫੰਕਸ਼ਨਾਂ ਵਿੱਚ ਵੰਡੋ।
Interop ਸ਼ਾਨਦਾਰ ਹੈ, ਪਰ ਧਿਆਨ ਰੱਖੋ:
@Nullable/@NonNull ਐਨੋਟੇਸ਼ਨ ਜੋੜੋ ਜਾਂ ਅਸੁਰੱਖਿਅਤ calls ਨੂੰ ਵੈਪਰ ਕਰੋ।@Throws ਵਰਤਣ ਜਾਂ document ਕਰਨ ਦੀ ਸੋਚੋ।ਕਦਮ-ਦਰ-ਕਦਮ ਮਾਈਗ੍ਰੇਟ ਕਰੋ:
ਜਲਦੀ ਤੋਂ ਜਲਦੀ ਸਟਾਈਲ ਅਤੇ ਰਿਵਿਊ ਨਿਯਮ ਤੇ ਸਹਿਮਤੀ ਕਰੋ: ਕਦੋਂ scope functions ਵਰਤਣੀਆਂ ਹਨ, ਨਾਂ-ਨੀਤੀ, ਨਲ-ਹੈਂਡਲਿੰਗ ਪੈਟਰਨ, ਅਤੇ ਜਦ explicit types ਨੂੰ ਤਰਜੀਹ ਦੇਣੀ ਹੈ। ਇੱਕ ਛੋਟੀ داخلی ਗਾਈਡ ਅਤੇ ਕੁਝ ਟ੍ਰੇਨਿੰਗ ਸੈਸ਼ਨਾਂ ਮਹੀਨਿਆਂ ਦੀ churn ਬਚਾ ਸਕਦੀਆਂ ਹਨ।
ਜੇ ਤੁਸੀਂ ਕਈ ਰਿਪੋ ਜਾਂ ਸਕੁਆਂਡਾਂ 'ਚ ਮਾਈਗ੍ਰੇਟ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਇੱਕ ਹਲਕਾ "ਯੋਜਨਾ ਮੋਡ" ਵਰਕਫਲੋ (migration checklist, module boundaries, rollback steps) ਸਥਾਪਿਤ ਕਰੋ। ਕੁਝ ਟੀਮਾਂ ਇੱਕ ਹੋਰ ਮਦਦਗਾਰ ਅਪ੍ਰੋਚ ਲਈ Koder.ai ਵਰਤਦੀਆਂ ਹਨ ਤਾਂ ਕਿ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਯੋਜਨਾਵਾਂ, ਸੰਬੰਧਿਤ ਸਰਵਿਸਿਜ਼ ਲਈ ਸਕੈਫੋਲਡਿੰਗ (ਅਕਸਰ React ਡੈਸ਼ਬੋਰਡ ਜਾਂ Go + PostgreSQL ਬੈਕਐਂਡ), ਅਤੇ iteration ਦੌਰਾਨ snapshots/rollback points ਤਿਆਰ ਕਰਨ ਵਿੱਚ ਸਹਾਇਤਾ ਮਿਲੇ—ਬਿਨਾਂ ਪੂਰੇ ਪਾਈਪਲਾਈਨ ਨੂੰ ਬਦਲੇ।
Kotlin ਨੇ JVM ਦੁਨੀਆਂ ਨੂੰ ਰੀਪਲੇਸ ਕਰਕੇ ਨਹੀਂ ਜਿੱਤਿਆ, ਬਲਕਿ ਇਸਨੂੰ ਆਧੁਨਿਕ ਮਹਿਸੂਸ ਕਰਵਾ ਕੇ ਜਿੱਤਿਆ—ਉਹ ਵੀ ਬਿਨਾਂ ਪੂਰੇ ਤੌਰ 'ਤੇ ਤੋੜ-ਮੋੜ ਕੀਤੇ। ਟੀਮਾਂ ਆਪਣਾ ਮੌਜੂਦਾ Java ਕੋਡ, Gradle builds, ਅਤੇ ਲਾਇਬ੍ਰੇਰੀ ਸਟੈਕ ਰੱਖ ਸਕਦੀਆਂ ਸੀ—ਫਿਰ ਕ੍ਰਮਬੱਧਤਾ ਨਾਲ Kotlin ਨੂੰ ਉਹਨਾਂ ਥਾਵਾਂ ਤੇ ਜੋੜ ਸਕਦੀਆਂ ਜਿੱਥੇ ਇਹ ਤੁਰੰਤ ਮੁੱਲ ਦਿਖਾਉਂਦਾ ਸੀ।
ਛੋਟਾ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਪ੍ਰਯੋਗ ਨੂੰ ਮਾਪਯੋਗ ਰੱਖੋ:
ਜੇ ਤੁਸੀਂ ਪ੍ਰਾਇਕਟਿਕਲ ਗਾਈਡਾਂ ਅਤੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਕਹਾਣੀਆਂ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ /blog ਵੇਖੋ। ਜੇ ਤੁਸੀਂ ਟੂਲਿੰਗ ਜਾਂ ਟੀਮਾਂ ਲਈ ਸਹਿਯੋਗ ਦਾ ਮੁਲਾਂਕਣ ਕਰ ਰਹੇ ਹੋ ਤਾਂ /pricing ਵੇਖੋ।
Kotlin ਨੇ JVM 'ਤੇ ਡਿਵੈਲਪਰ ਅਨੁਭਵ ਦੀ ਬੇਸਲਾਈਨ ਉੱਚੀ ਕੀਤੀ—ਆਮ ਬੋਇਲੇਰਪਲੇਟ (ਉਦਾਹਰਨ ਲਈ data classes, properties, smart casts) ਘਟਾ ਕੇ ਅਤੇ ਨੱਲ-ਸੇਫਟੀ ਵਰਗੀਆਂ ਸੁਰੱਖਿਅਤ ਡਿਫੌਲਟਸ ਜੋੜ ਕੇ—ਫਿਰ ਭੀ ਇਹ ਸਧਾਰਨ JVM ਬਾਈਟਕੋਡ ਵਿੱਚ ਕੰਪਾਇਲ ਹੁੰਦਾ ਅਤੇ ਉਹੀ Java ਲਾਇਬ੍ਰੇਰੀਆਂ ਅਤੇ ਟੂਲਿੰਗ ਵਰਤਦਾ ਰਿਹਾ।
ਇਹ ਸੋਧ ਅਤੇ ਬਾਈਟਕੋਡ-ਪੱਧਰ ਤੇ ਇੰਟਰਓਪਰੇਬਿਲਿਟੀ ਕਰਕੇ ਸੀਧਾ ਸੰਭਵ ਹੋਇਆ। ਟੀਮ ਇੱਕ-ਫਾਇਲ ਆਧਾਰ 'ਤੇ Kotlin ਸ਼ੁਰੂ ਕਰ ਸਕਦੀਆਂ ਹਨ—ਨਵੇਂ ਫਾਈਲਾਂ Kotlin ਵਿੱਚ ਲਿਖੋ, Java ਨੂੰ ਕਾਲ ਕਰੋ ਜਾਂ Java ਤੋਂ Kotlin ਨੂੰ ਕਾਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ—ਅਤੇ ਮੌਜੂਦਾ ਲਾਇਬ੍ਰੇਰੀਆਂ ਅਤੇ Gradle ਬਿਲਡ сохран ਰਹਿੰਦੀਆਂ ਹਨ, ਇਸ ਨਾਲ ਵੱਡੇ ਰੀਰਾਈਟ ਦੇ ਖਤਰੇ ਤੋਂ ਬਚਿਆ ਜਾ ਸਕਦਾ ਹੈ।
String! ਵਰਗੇ ਦਿਖ ਸਕਦੇ ਹਨ ਅਤੇ ਬਿਨਾਂ ਵੈਰੀਫਿਕੇਸ਼ਨ ਦੇ NullPointerException ਹੋ ਸਕਦਾ ਹੈ।@Nullable/@NonNull ਜਾਂ JSpecify ਵਰਗੀਆਂ ਐਨੋਟੇਸ਼ਨ ਨਹੀਂ ਦਿੰਦੇ, ਤਾਂ Kotlin compiler ਉਤੇ ਸੁਰੱਖਿਆ ਘਟਦੀ ਹੈ।Kotlin ਕਿਸੇ ਟਾਈਪ ਨੂੰ nullable (T?) ਜਾਂ non-null (T) ਵਜੋਂ ਵੱਖ ਕਰਦਾ ਹੈ ਅਤੇ ਗੁੰਝਲਦਾਰ ਨੱਲ-ਤੁਟਣ ਵਾਲੇ ਕੇਸਾਂ ਨੂੰ ਰਨਟਾਈਮ ਤੋਂ ਕੰਪਾਇਲ-ਟਾਈਮ ਤੇ ਲਿਆਉਂਦਾ ਹੈ। ਵਰਤੋਂਕਾਰ ਵਧੋਂ ਸਪਸ਼ਟ ਪੈਟਰਨ ਵਰਤਦੇ ਹਨ, ਉਦਾਹਰਨ ਲਈ:
?. (ਸੇਫ਼ ਕਾਲ)?: (Elvis) ਫਾਲਬੈਕlet { } ਸਕੋਪਡ ਹੈਂਡਲਿੰਗਹਾਂ—ਅਕਸਰ ਕਾਫ਼ੀ। data classes ਆਮ ਮਾਡਲ ਅਤੇ UI ਸਟੇਟ ਲਈ ਵਧੀਆ ਹੁੰਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਇਹ ਆਪਣੇ ਆਪ equals(), hashCode(), toString(), ਅਤੇ copy() ਜਨਰੇਟ ਕਰਦੀਆਂ ਹਨ। ਇਸ ਨਾਲ ਹੈਂਡ-ਲਿਖੇ ਕੋਡ ਘੱਟ ਹੁੰਦਾ ਅਤੇ ਸਟੇਟ ਅਪਡੇਟਸ ਜ਼ਿਆਦਾ ਸਪਸ਼ਟ ਰਹਿੰਦੀਆਂ ਹਨ।
ਇਹ ਤੁਹਾਨੂੰ ਮੌਜੂਦਾ ਕਿਸੇ ਟਾਈਪ (ਜਿਸ ਵਿੱਚ Java/Android ਕਲਾਸਾਂ ਵੀ ਸ਼ਾਮਲ ਹਨ) 'ਤੇ ਨਵੇਂ ਫੰਕਸ਼ਨ/ਪ੍ਰੋਪ੍ਰਟੀज़ ਜੋੜਨ ਦਿੰਦੇ ਹਨ ਬਿਨਾਂ ਅਸਲੀ ਕਲਾਸ ਨੂੰ ਸੋਧੇ। ਇਹ ਛੋਟੇ, ਖੋਜਯੋਗ ਹੈਲਪਰਾਂ ਨੂੰ ਉਤਸਾਹਿਤ ਕਰਦਾ ਹੈ ਅਤੇ ਵੱਡੇ “Utils” ਕਲਾਸਾਂ ਤੋਂ ਬਚਾਉਂਦਾ—ਖ਼ਾਸ ਕਰਕੇ ਜਦੋਂ Android KTX ਨਾਲ ਜੋੜਿਆ ਹੋਵੇ।
ਕਾਲਬੈਕ ਦੀ ਥਾਂ Coroutines ਤੁਹਾਨੂੰ suspend ਫੰਕਸ਼ਨਾਂ ਵਰਗੇ ਸਾਦੇ, ਕ੍ਰਮਿਕ (sequential) ਸਟਾਈਲ ਵਿੱਚ async ਲਾਜਿਕ ਲਿਖਣ ਦਿੰਦੀਆਂ ਹਨ। ਵੱਡਾ ਫਾਇਦਾ ਹੈ structured concurrency: ਕੰਮ ਕਿਸੇ ਸਕੋਪ ਨੂੰ ਮਲਕियत ਹੁੰਦਾ ਹੈ, ਸਕੋਪ ਰੱਦ ਹੋ ਸਕਦਾ ਹੈ, ਅਤੇ lifecycle-aware cancellation ਨਾਲ ਲੀਕ ਅਤੇ "UI ਦੇ ਗੁਆਚ ਹੋਣ 'ਤੇ ਅਪਡੇਟ" ਵਰਗੀਆਂ ਗਲਤੀਆਂ ਘਟਦੀਆਂ ਹਨ।
ਹਾਂ, ਕੁਝ ਟੀਮਾਂ ਲਈ ਕੋਡ ਪੜ੍ਹਨਯੋਗਤਾ ਬਹਿਤਰ ਹੋ ਜਾਂਦੀ ਹੈ, ਪਰ ਕੰਪਾਇਲ ਸਮੇਂ ਵੱਧ ਸਕਦੇ ਹਨ। ਰੋਕਣ ਲਈ ਆਮ ਤਰੀਕੇ:
ਪੜ੍ਹਨਯੋਗਤਾ ਨੂੰ ਜਿਆਦਾ ਤਰਜੀਹ ਦਿਓ। ਆਮ ਫਿੱਟੀ-ਟ੍ਰੈਪਾਂ:
let, run, apply, also, with) ਦਾ ਬੇਤਰਤੀਬ ਵਰਤੋਂ ਗਲਤ ਕੰਟਰੋਲ-ਫਲੋ ਪੈਦਾ ਕਰ ਸਕਦੀ ਹੈਇੱਕ ਸੁਝਾਵੀ ਯੋਜਨਾ:
ਇਹ ਤਰੀਕਾ ਖ਼ਤਰੇ ਘੱਟ ਰੱਖਦਾ ਹੈ ਅਤੇ ਟੀਮ ਦੀ Kotlin ਫਲੂਇੰਸੀ ਬਣਾਉਂਦਾ ਹੈ।
ਇਸ ਨਾਲ ਕਈ ਸਧਾਰਨ ਕਰੈਸ਼ ਹੁਣ ਕੋਡ ਲਿਖਦੇ ਸਮੇਂ ਹੀ ਪਕੜ ਲਈ ਜਾਂਦੇ ਹਨ।
ਸਪਸ਼ਟਤਾ ਵਧਾਉਣ ਲਈ ਕਾਮਪਲੈਕਸ Eਕਸਪ੍ਰੈਸ਼ਨਾਂ ਨੂੰ ਨਾਮਿਤ ਵੈਰੀਏਬਲਾਂ ਵਿੱਚ ਵੰਡੋ ਅਤੇ ਛੋਟੇ ਫੰਕਸ਼ਨ ਬਣਾਓ।