Android

Những thay đổi về thư viện Framework và Support sau Google I/O 2018

Kể từ “cuộc cách mạng mang tên Kotlin” diễn ra tại Google I/O năm ngoái, Google chính thức biến Kotlin thành ngôn ngữ hàng đầu cho việc lập trình Android. Và với I/O 2018, Google tiến thêm một bước nữa với việc “Kotlin hóa” các thư viện Support. Ngoài ra, cũng có những thay đổi đáng chú ý khác mà tôi sẽ giới thiệu với các bạn ngay sau đây.

Google-IO-2018

1. Deprecate khá nhiều classes trong bộ thư viện Framework và chỉ duy trì và phát triển trong thư viện Support:

Thực tế là có nhiều lúc bản thân tôi không hiểu việc duy trì và bổ sung thư viện Framework trong Android có ý nghĩa gì vì chúng (các phiên bản mới nhất đi cùng phiên bản Android mới) cũng sẽ được tách ra gói vào bộ thư viện Support. Chẳng hạn, phiên bản stable đầu tiên của android.app.Fragment của Android 8.1 Oreo API 27 Framework chính là phiên bản android.support.v4.app.Fragment của phiên bản thư viện Support 27.0.0. Đúng là “bê nguyên si” đó bạn à, vì chúng đều extends Object nên việc bưng bê sang là dễ ợt như trở bàn tay. Và bản thân Google cũng không sử dụng thư viện Framework về Fragment để viết ứng dụng hệ thống cho Android. Chẳng hạn ứng dụng Cài đặt (android.system.settings) có sử dụng bộ thư viện Preference Support (android.support.v14.preference) trong khi việc sử dụng bộ thư viện Preference của Framework sẽ có lí hơn. Ngay cả ứng dụng hệ thống còn dùng thư viện Support trong package đó thì việc duy trì bộ thư viện Framework tương ứng là để làm gì khi có ai thèm dùng đâu? Ngoài ra, các thư viện Support được thường xuyên nâng cấp và sửa lỗi, vd ta có các phiên bản 27.0.0, 27.0.1, 27.0.2, 27.1.0 và 27.1.1 cho các thư viện Support version 27 trong khi thư viện Framework thì phải “chịu trận”, việc cập nhật bảo mật hàng tháng của Android đâu cố ý và cũng không gồm các sửa lỗi cho android.app.Fragment đâu?

Vì vậy, dù trễ nhưng vẫn còn kịp, kể từ Android P sắp ra mắt thì Google cho deprecate hàng loạt các classes và packages trong thư viện Framework vốn có các packages và classes tương đương trong thư viện Support, chẳng hạn android.app.Fragment sẽ bị deprecated và kể từ bây giờ, Google chỉ tập trung phát triển android.support.v4.app.Fragment mà thôi. Theo tôi, điều này là rất đáng hoan nghênh vì việc duy trì bộ thư viện Framework tương ứng không chỉ làm chật chỗ, tốn thời gian vô ích, mà còn có thể gây xung đột và làm chậm thời gian cập nhật phiên bản Android mới trên các thiết bị chạy giao diện đặc trưng của nhà sản xuất và vốn có thêm những tính năng vượt trước cả chính phiên bản Android gốc của Google như Samsung hay LG. Cái nào có thư viện Support rồi thì giờ chỉ tập trung trong thư viện Support mà thôi.

Cá nhân tôi tổng hợp được một số classes và packages được liệt kê dưới đây. Và do đây là sự tổng hợp của cá nhân tôi, cộng thêm việc các APIs mới của Android P chưa được “gút lại”, danh sách này là không đầy đủ. Nếu tìm thấy một cái tên mới và muốn chia sẻ, bạn vui lòng để lại ở phần bình luận bên dưới:

  • Các classes trong android.app: Fragment và các classes liên quan như FragmentManager, PreferenceFragment, LoaderManager và các classes liên quan như LoaderManager.Callback.
  • Các classes trong android.content: AsyncTaskLoader, CursorLoader.

Ngoài ra, cá nhân tôi muốn The Big G deprecate thêm nhiều thứ khác như android.widget.Toolbar hay android.widget.SearchView, v.v… nhưng có lẽ chúng chưa bị ảnh hưởng là do chúng chưa bị thay đổi trong Android P. Trong các phiên bản sau thì có thể chúng cũng theo con đường trên mà thôi.

2. AndroidX

Có lẽ các bạn đã khá ngao ngán trong việc nhớ tên các Support Library Packages vì có nhiều tên như V4, V7, V13, V14, rồi lại có V4 Fragment, V7 Appcompat, V14 Preference là con của những tên V4, V7, V14, rồi hơn nữa là một class trong một bộ thư viện thuộc V7 lại extends một tên thuộc bộ thư viện V4 như android.support.v7.app.AppCompatActivity extennds android.support.v4.app.FragmentActivity, rồi sự chuyển dời, deprecate các class thuộc package này sang package khác như android.support.v7.app.NotificationCompat được chuyển sang package V4 thành android.support.v4.app.NotificationCompat. Rồi tệ hơn nữa là các minSdk của tất cả các bộ thư viện Support hiện tại là 14 (ngoại từ bộ Emoji là 19) thì những con số 4, 7, 13 kia lại chẳng có ý nghĩa gì ngoài việc làm khó developers và thực sự, cá nhân tôi thấy kẻ thù và đối tác của Google là Apple không hề có động thái làm khó developers nào cho vui như vậy. Vì vậy, dù khá trễ nhưng The Big G đã nhận ra sự vô lí vớ va vớ vẩn này và cho ra đời bộ thư viện AndroidX.

Nhưng đừng có hốt hoảng mà hò hét rằng “Tôi phải học lại từ đầu à?”. Thực chất, AndroidX chỉ là cái bình mới, thống nhất hơn, bớt đi sự vớ vẩn trên nhãn – nhưng vẫn còn ít nhiều, cho phần rượu bia là các classes và interfaces trong các bộ thư viện Support kia. Chẳng hạn, khá nhiều các classes trong bộ android.support.v4.appandroid.support.v7.app được quy tựu vào bộ androidx.core.app. Tất nhiên cũng còn những class android.support.vX.app nằm trong package khác nhưng ít nhiều thì sự thống nhất đã cao hơn hẳn và sự vớ vẩn đã bớt đi nhiều. Và do là bình mới rượu cũ nên các class đều y như cũ và bạn không phải ghi nhớ lại gì khác ngoài tên package mà thôi.

Chính vì bớt vớ vẩn và thống nhất hơn trước nên các thư viện android.support sẽ bị deprecated trong thời gian sớm nhất, và khả năng phiên bản cuối sẽ là 28.0.0 stable (hiện giờ là alpha). Ngay bây giờ thì bạn có thể chuyển qua dùng bộ AndroidX này ngay bằng cách thay đổi “chút đỉnh” phần implementation trong build.gradle:app hoặc build.gradle:lib:

Bạn nên thay dấu “+” bằng phiên bản cụ thể, vd 1.0.0-alpha1 để tránh xung đột. Và như bạn có thể thấy, tên thư viện tương đối đơn giản, dễ nhớ và đặc biệt là hiện chỉ có 5 tên mà thôi. Không biết tương lai có dư lào, nhưng hiện tại thì ngon rồi. Lưu ý là khi thay đổi xong thì bạn cần Refactor lại project và chỉ khả dụng trên google maven và android gradle plugin cần phải là 3.0.0 trở lên. Và bạn có thể thấy gì nữa không? KTX to đùng đó. Vì vậy, xin bạn đừng bỏ qua phần sau.

3. Ưu tiên Kotlin

Kể từ khi “la lối” là Kotlin sẽ trở thành first-class language for Android development, Google không ngừng “lao động” vất vả để cụ thể hóa điều đó. Và trên thực tế thì với AndroidX bên trên, bạn có thể thấy bộ AndroidX rất Kotlin-friendly, nếu không muốn nói là tối ưu hóa cho Kotlin. Vì vậy, để trả lời cho câu hỏi “Bây giờ em muốn theo làm Android thì em nên học Kotlin hay Java?”, câu “Always Java” có vẻ không còn “always right” nữa. Bây giờ bạn có thể vào Kotlin ngay và luôn, dù bạn vẫn nên học về Java ở mức cho biết syntax này nọ. Ngoài ra bộ AndroidX này còn giúp làm gọn code hơn với Kotlin trong khi với Java thì bạn lại phải viết đủ code. Chi tiết, bạn có thể xem trong video này. Chúc các bạn vui vẻ với AndroidX và Kotlin.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.