7

Vì tôi đã cập nhật dự án của mình lên SDK phiên bản 27 và các plugin bổ sung cho thư viện hỗ trợ cho phiên bản 27.0.0 Tôi cần thay đổi mã của mình.Thư viện hỗ trợ Android 27, Cập nhật phân đoạn?

Với 26.1.0 Tôi chỉ có thể sử dụng getContext() (với Kotlin context) trong tôi Fragment (android.support.v4.app) và tôi không có vấn đề nullability, nhưng kể từ khi tôi sử dụng Kotlin Tôi có một vấn đề với phiên bản 27.0.0, tất cả context cuộc gọi của tôi đã không làm việc nữa , tôi cần một người điều hành an toàn, như context!!, nhưng vì cá nhân tôi thấy nó là một hối hả để làm điều đó mỗi khi tôi chỉ làm bản thân mình tôi workaround chức năng

override fun getContext() = super.getContext()!! 

một điều mà thay đổi (đột nhiên và đó là lý do tại sao tôi đang hỏi) là các phương pháp onCreateView()onViewCreated(). Trong onCreateView các inflater không có thể null nữa, vì vậy tôi cần phải thay đổi chữ ký chức năng của tôi để ghi đè đúng từ onCreateView(inflater: LayoutInflater?...) đến onCreateView(inflater: LayoutInflater...) và tương tự cho tham số createdView trong onViewCreated.

Vì vậy, bây giờ tôi đã tự hỏi tại sao, đặc biệt là (đối với Kotlin) rất xấu xí getContext() thay đổi đã được thực hiện và hướng đến https://developer.android.com/sdk/support_api_diff/27.0.0/changes.html.

Nhưng chờ đã, dường như họ không thay đổi? Vì vậy, bây giờ câu hỏi của tôi là nếu tôi làm điều gì đó sai hoặc nếu họ thực sự thay đổi nó và nếu như vậy tôi có thể hỏi họ tại sao?

Bằng cách này, cũng áp dụng cho getActivity(), tôi nghĩ rằng việc kiểm tra mHost == null đã được bổ sung và phương pháp getActivity thậm chí còn thức, vì vậy tôi không thể sử dụng workaround của tôi ở đó, mà làm cho nó rất rất xấu xí. Trên thực tế, trong các tệp nguồn, các phương thức trông giống nhau, nhưng 26.1.0 có loại trả về Kotlin Context!27.0.0 loại trả về Context?.

+0

Sligthly related ... non null inflater có nghĩa là fragmen không có ui nhưng được sử dụng làm nhân viên không phải là một sự thay thế ngay bây giờ? – cutiko

+0

@cutiko Tôi không biết ý bạn là gì. – creativecreatorormaybenot

Trả lời

13

Đây là những thay đổi có chủ ý. Trước phiên bản này của thư viện hỗ trợ, các lớp này không có chú thích nullability, do đó từ Kotlin, tất cả các kiểu này chỉ là platform types. Trong 27, họ thêm các chú thích cần thiết, vì vậy bây giờ các loại này chắc chắn được đánh dấu là nullable hoặc không nullable trong Kotlin - không cần phải đoán xem chúng có thể là null hay không.

Đối với các phương pháp cụ thể mà bạn đã đề cập:

  • Các getActivitygetContext phương pháp trở lại các loại nullable vì khi Fragment không gắn liền với một Activity, các phương pháp này đã trở null. Không có thay đổi về hành vi, nó chỉ được đánh dấu rõ ràng ngay bây giờ, vì vậy bạn có thể xử lý nó một cách an toàn.
  • Thông số inflater của phương thức onCreateView được sử dụng làm loại nền tảng, do đó, tùy thuộc vào bạn bạn có đánh dấu nó là không có giá trị hay không. Vì nó sẽ không bao giờ được gọi với null, nó đã được chú thích rõ ràng là @NonNull, do đó, loại của nó trong Kotlin bây giờ là đúng LayoutInflater thay vì loại "looser" LayoutInflater!.
+3

Cảm ơn bạn đã trả lời. Nó rất xấu cho Kotlin vì 'getContext()' trong trường hợp của tôi sẽ không bao giờ là null, cũng không phải 'getActivity()'.Điều đó có nghĩa rằng bây giờ tôi cần phải khẳng định '!!' đằng sau họ cho mọi cuộc gọi, điều này rất khó chịu. – creativecreatorormaybenot

+0

Lưu ý rằng nếu phương thức có thể được gọi là nơi hoạt động/phân đoạn là null, bạn có thể muốn xử lý nó khác với việc sử dụng xác nhận null '!!'. Một cách tiếp cận khác là sử dụng ví dụ: 'activity? .let {/ * Thực hiện điều gì đó * /}' – Fhl

Các vấn đề liên quan