Как использовать / не использовать устаревшие методы в Android

Я слишком долго не просил этого вопроса. Я столкнулся с множеством методов в Android, которые устарели, но по-прежнему работают в новых версиях API. Итак, каков риск использования устаревшего метода до тех пор, пока он работает?

Вот более конкретный вопрос. Я работаю с TimePickers, и метод getCurrentHour () устарел в API 23 и заменен на getHour () . Я, очевидно, не могу использовать getHour() исключительно, так как большинство устройств еще не на API 23, но использует getCurrentHour() «неправильно» для новейшей версии Android? Какое из следующих действий я должен сделать?

  1. Продолжайте использовать getCurrentHour() до тех пор, пока не пройдут годы, а API 23 станет моей новой minSdkVersion ?
  2. В коде явно проверьте версию API и вызовите либо getCurrentHour() либо getHour() на основе результата?

Спасибо, что помогли мне учиться.

Использует getCurrentHour () «неправильно» для новейшей версии Android?

Если «неправильно» вы подразумеваете, что он убьет щенка, нет, это не будет ошибкой. А для уровня API 23, это вряд ли вызовет какую-либо проблему.

В общем, «устаревший» означает «у нас есть что-то еще, что мы хотели бы использовать». То, что происходит с устаревшим материалом, меняется:

  • Иногда устаревшие вещи по-прежнему можно использовать спустя годы. AbsoluteLayout был устаревшим в API Level 3, еще в 2009 году. Он по-прежнему работает так же безумно сегодня, как и тогда.

  • Иногда устаревшие вещи будут иметь меньшую функциональность. Различные методы в ActivityManager устарели и возвращают подмножество того, к чему они привыкли, в целях безопасности и конфиденциальности.

  • Иногда устаревшие вещи будут удалены прямо (см. HttpClient в Android 6.0 (или, фактически, не видите его, поскольку он был удален)). Это довольно необычно.

Следовательно, предупреждение об устаревании является признаком того, чтобы обратить внимание и задуматься о том, какая ваша долгосрочная стратегия будет для этого конкретного момента функциональности.

Какое из следующих действий я должен сделать?

Для чего-то столь же тривиального, как этот метод переименовать, вы, вероятно, будете в безопасности с вашим первым вариантом (придерживайтесь устаревшего метода, пока ваш minSdkVersion достаточно высоким).

Однако для чего-то большего, чем это, я бы пошел со вторым вариантом. Иногда вы будете явно проверять эту версию. Иногда вы можете использовать библиотеку, которая будет скрывать проверку версии для вас. Например, почти где угодно в библиотеке support-v4 которую вы видите ...Compat Класс ...Compat (например, NotificationCompat , ContextCompat , ActivityCompat ), роль этого класса заключается в предоставлении API, эквивалентного новейшему и ContextCompat API Но тот, который может использоваться на широком спектре устройств, потому что он изящно деградирует на более старых устройствах, выполняя эти проверки версий для вас.

Примечание: никакие фактические щенки не пострадали при создании этого ответа