Android findviewbyid custom view

Kotlin Android Extensions: полное руководство

Oct 9, 2018 · 7 min read

Если у вас уже есть опыт разработки приложений для Android, вероятно, вы уже устали использовать findViewById, чтобы восстанавливать view. Или, может быть, вы уже сдались и начали использовать известную библиотеку ― Butterknife. Если это ваш случай, то вы влюбитесь в Kotlin Android Extensions.

Что такое Kotlin Android Extensions?

Kotlin Android Extensions — это плагин для Kotlin, который включён в стандартный пакет. Он позволяет восстанавливать view из Activities, Fragments, и Views удивительно-бесшовным способом.

Плагин генерирует дополнительный код, который позволяет получить доступ к view в виде XML, так же, как если бы вы имели дело с properties с именем id, который вы использовали при определении структуры.

Т а кже он создаёт локальный кэш view. При первом использовании свойства, плагин выполнит стандартный findViewById. В последующем, view будет восстановлен из кэша, поэтому доступ к нему будет быстрее.

Как этим пользоваться

Посмотрим, насколько это просто. В первом примере рассмотрим activity:

Включаем Kotlin Android Extensions в наш код

Хотя плагин уже интегрирован (устанавливать новый не нужно), если вы хотите его использовать, вам нужно подключить плагин в модуль Android:

И это все что вам потребуется. Теперь вы можете начать работу с ним.

Восстанавливаем view из XML

С этого момента, восстановить view, также просто, как использовать view id, которое вы определили в XML, непосредственно в вашем activity.

Представьте, что у вас есть такой XML:

Как видно, в TextView есть id welcomeMessage .

Просто напишите следующий код в MainActivity:

Чтобы это работало, нужен специальный импорт (я написал его ниже), но IDE может автоматически импортировать его. Проще и быть не может!

Как я уже упоминал, сгенерированный код включает кэш view, поэтому, если вы повторно обратитесь к view, это не потребует выполнения findViewById снова.

Давайте посмотрим, что происходит под капотом.

Магия Kotlin Android Extensions

Когда начинаешь работать с Kotlin, действительно интересно понять байт-код, который генерируется при использовании той или иной функции. Это поможет вам понять скрытую цену ваших решений.

В меню Tools → Kotlin, вы найдёте мощный инструмент Show Kotlin Bytecode. Если кликнуть по нему, вы увидите байт-код, который будет сгенерирован, когда открытый файл класса будет скомпилирован.

Для большинства людей, байт-код не особенно полезен, но тут есть ещё одна опция: Decompile.

Эта опция покажет вам Java репрезентацию байт-кода, который был сгенерирован в Kotlin. Так, вы сможете более-менее понять, как будет выглядеть код Java, эквивалентный тому, что вы написали на Kotlin.

Я собираюсь использовать это на примере activity и посмотреть код, сгенерированный Kotlin Android Extensions.

Вот интересная часть:

Это и есть кэш view, о котором мы говорили.

При запросе view, его поиск начинается в кэше. Если view нет в кэше, то он туда будет добавлен, как только будет найден. Всё просто.

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

Тогда, эта строка:

Превращается в эту:

Таким образом, плагин не генерирует свойства для каждого view, это ненастоящие свойства. Плагин просто заменяет код во время компиляции, чтобы получить доступ к кэшу view. Затем, он приводит к нужному типу и вызывает метод.

Kotlin Android Extensions ― работа с фрагментами

Этот плагин можно использовать с фрагментами.

Проблема с фрагментами заключается в том, что view может обновится, а экземпляр фрагмента останется прежним. Что произойдёт? А то, что view находящееся в кэше, перестанет быть валидным.

Давайте посмотрим код, который генерирует плагин, если мы используем его с фрагментом. Я создаю простой фрагмент, который использует тот же XML, который я написал выше:

В onViewCreated , я снова изменяю текст TextView . Что насчёт сгенерированного байт-кода?

Всё тоже самое, как и в activity, с небольшой разницей:

Когда view перестанет быть актуальным, этот метод вызовет clearFindViewByIdCache , так что мы в безопасности!

Kotlin Android extensions и Custom View

С custom view, плагин работает схожим образом. Скажем, у нас есть такой view:

Я создаю очень простое custom view и генерирую конструкторы с новым намерением, которое использует аннотацию @JvmOverloads :

В примере выше, я изменяю текст в itemTitle . Сгенерированный код должен искать view в кэше. Не имеет смысла снова копировать тот же код полностью. Вы можете наблюдать это в строке, которая изменяет текст:

Отлично! В custom views мы тоже вызываем findViewById только первый раз.

Восстанавливаем views из другого view

Последняя альтернатива, которую предлагает Kotlin Android Extensions: использовать свойства напрямую из другого view.

Я использую схему, схожую с той, что была в предыдущем разделе. Представьте, что это было закачано в адаптер для примера.

Вы также можете получить доступ к subviews напрямую, просто используя этот плагин:

Хотя плагин и может помочь заполнить import, здесь есть небольшое отличие:

Несколько вещей, которые вам нужно знать:

• Во время компиляции, вы можете ссылаться на любое view из любого другого view. Это значит, вы можете ссылаться на view, которое не является его прямым потомком. Это плохо скажется на времени выполнения при попытке восстановить view, которого не существует.
• В этом случае, view не кэшировано, как в случае с Activities и Fragments.

Почему так? В отличие от предыдущих случаев, здесь у плагина нет места, чтобы генерировать необходимый код для кэша.

Если вы снова перечитаете код, который сгенерирован плагином, где вызываются свойства из view, вы увидите это:

Как видно, здесь нет запроса к кэшу. Будьте осторожны, если у вас комплексное view, и вы используете его в адаптере. Это может повлиять на производительность.

Также у вас есть альтернатива: Kotlin 1.1.4

Kotlin Android Extensions версии 1.1.4

Начиная с этой, новой версии Kotlin, в Android Extensions включили новые интересные функции: кэш в любом классе (включая ViewHolder ) и новая аннотация, названная @Parcelize . Также есть способ настраивать сгенерированный кэш.

Мы вернёмся к ним через минуту, но вам следует знать, что эти новые фичи ― не завершены, так что, вам нужно включить их с помощью build.gradle :

Применяем на ViewHolder (или любом пользовательском классе)

Теперь есть простой способ построить кэш для любого класса. Единственное требование заключается в том, чтобы класс имплементировал интерфейс LayoutContainer . Этот интерфейс предоставит view, которое плагин будет использовать, чтобы искать subviews. Представьте, что у вас есть ViewHolder, который содержит view со структурой, описанной в предыдущем примере. Всё что вам нужно сделать:

containerView ― единственное, что мы перезаписываем из интерфейса LayoutContainer . Это все что вам необходимо.

С этого момента, у вас есть доступ к views напрямую. Нет необходимости присоединять itemView, чтобы получить доступ к subviews.

Ещё раз, если вы посмотрите на сгенерированный код, вы увидите, что view берётся из кэша:

Здесь я применял его на ViewHolder , но это достаточно универсальный подход и его можно использовать с любым классом.

Kotlin Android Extension. Реализация Parcelable

С новой аннотацией @Parcelize , можно с лёгкостью имплементировать Parcelable c любым классом.

Вам нужно добавить аннотацию, а плагин сделает за вас всю сложную работу:

Далее, как вам должно быть известно, можно добавить объект к любому намерению:

И восстановить объект из намерения в любой точке (в этом случае: из activity):

Настройка кэша

В этот экспериментальный набор, включена новая фича ― аннотация @ContainerOptions . Она даёт возможность настраивать способ построения кэша, или даже предотвращать его создание классом.

По умолчанию, используется Hashmap , как мы видели ранее. Его можно заменить на SparseArray из Android framework, что может быть более эффективно в некоторых ситуациях. Или, если вам не нужен кэш для класса, по каким-то причинам, такая возможность тоже есть.

Вот как это использовать:

На данный момент существуют следующие варианты:

Заключение

Вы увидели, как легко работать с Android views в Kotlin. Благодаря простому плагину, можно забыть обо всём этом ужасном коде, связанном с восстановлением view. Этот плагин создаёт для нас необходимые свойства с приведением правильного типа, безо всяких проблем.

Кроме того, Kotlin 1.1.4 добавляет интересные фичи, которые будут действительно полезны в некоторых случаях, к которым плагин ранее не имел отношения.

Источник

Use view binding to replace findViewById

New in Android Studio 3.6, view binding gives you the ability to replace findViewById with generated binding objects to simplify code, remove bugs, and avoid all the boilerplate of findViewById .

• Enable view binding in build.gradle (no libraries dependencies)
• View binding generates a binding object for every layout in your module ( activity_awesome.xml → ActivityAwesomeBinding.java )
• Binding object contains one property for every view with an id in the layout — with the correct type and null-safety
• Full support for both the Java programming language and Kotlin

Update build.gradle to enable view binding

You don’t need to include any extra libraries to enable view binding. It’s built into the Android Gradle Plugin starting with the versions shipped in Android Studio 3.6. To enable view binding, configure viewBinding in your module-level build.gradle file.

In Android Studio 4.0, viewBinding has been moved into buildFeatures [release notes] and you should use:

Once enabled for a project, view binding will generate a binding class for all of your layouts automatically. You don’t have to make changes to your XML — it’ll automatically work with your existing layouts.

View binding works with your existing XML, and will generate a binding object for each layout in a module.

You can use the binding class whenever you inflate layouts such as Fragment , Activity , or even a RecyclerView Adapter (or ViewHolder ).

Use view binding in an Activity

If you have a layout called activity_awesome.xml , which contains a button and two text views, view binding generates a small class called ActivityAwesomeBinding that contains a property for every view with an ID in the layout.

You don’t have to call findViewById when using view binding — instead just use the properties provided to reference any view in the layout with an id.

The root element of the layout is always stored in a property called root which is generated automatically for you. In an Activity ’s onCreate method you pass root to setContentView to tell the Activity to use the layout from the binding object.

Easy Mistake: Calling setContentView(…) with the layout resource id instead of the inflated binding object is an easy mistake to make. This causes the layout to be inflated twice and listeners to be installed on the wrong layout object.

Solution: When using view binding in an Activity , you should always pass the layout from the binding object with setContentView(binding.root) .

Safe code using binding objects

findViewById is the source of many user-facing bugs in Android. It’s easy to pass an id that’s not in the current layout — producing null and a crash. And, since it doesn’t have any type-safety built in it’s easy to ship code that calls findViewById

(R.id.image) . View binding replaces findViewById with a concise, safe alternative.

View bindings are…

• Type-safe because properties are always correctly typed based on the views in the layout. So if you put a TextView in the layout, view binding will expose a TextView property.
• Null-safe for layouts defined in multiple configurations. View binding will detect if a view is only present in some configurations and create a @Nullable property.

And since the generated binding classes are regular Java classes with Kotlin-friendly annotations, you can use view binding from both the Java programming language and Kotlin.

What code does it generate?

View binding generates a Java class that replaces the need for findViewById in your code. It will generate one binding object for every XML layout in your module while mapping names so activity_awesome.xml maps to ActivityAwesomeBinding.java .

When editing an XML layout in Android Studio, code generation will be optimized to only update the binding object related to that XML file, and it will do so in memory to make things fast. This means that changes to the binding object are available immediately in the editor and you don’t have to wait for a full rebuild.

Android Studio is optimized to update the binding objects immediately when editing XML layouts.

Let’s step through the generated code for the example XML layout from earlier in this post to learn what view binding generates.

View binding will generate one correctly-typed property for each view with a specified id . It will also generate a property called rootView that’s exposed via a getter getRoot . View binding doesn’t do any logic– it just exposes your views in a binding object so you can wire them up without error-prone calls to findViewById . This keeps the generated file simple (and avoids slowing down builds).

If you’re using Kotlin, this class is optimized for interoperability. Since all properties are annotated with @Nullable or @NonNull Kotlin knows how to expose them as null-safe types. To learn more about interop between the languages, check out the documentation for calling Java from Kotlin.

In ActivityAwesomeBinding.java , view binding generates a public inflate method. The one argument version passes null as the parent view and doesn’t attach to parent. View binding also exposes a three argument version of inflate that lets you pass the parent and attachToParent parameters when needed.

The call to bind is where the magic happens. It will take the inflated layout and bind all of the properties, with some error checking added to generate readable error messages.

The bind method is the most complex code in the generated binding object, with a call to findViewById for each view to bind. And here you can see the magic happen – since the compiler can check the types and potential nullability of each property directly from the XML layouts it can safely call findViewById .

Note, the actual generated code for the bind method is longer and uses a labeled break to optimize bytecode. Check out this post by Jake Wharton to learn more about the optimizations applied.

On each binding class, view binding exposes three public static functions to create a binding an object, here’s a quick guide for when to use each:

• inflate(inflater) – Use this in an Activity onCreate where there is no parent view to pass to the binding object.
• inflate(inflater, parent, attachToParent) – Use this in a Fragment or a RecyclerView Adapter (or ViewHolder ) where you need to pass the parent ViewGroup to the binding object.
• bind(rootView) – Use this when you’ve already inflated the view and you just want to use view binding to avoid findViewById . This is useful for fitting view binding into your existing infrastructure and when refactoring code to use ViewBinding .

What about included layouts

One binding object will be generated for each layout.xml in a module. This is true even when another layout s this this layout.

In the case of included layouts, view binding will create a reference to the included layout’s binding object.

Note that the tag has an id: android:id=»@+id/includes» . This is required for view binding to generate a property (just like a normal view).

Include tags must have an id to generate a binding property.

View binding will generate a reference to the IncludedButtonsBinding object in ActivityAwesomeBinding .

Using view binding and data binding

View binding is only a replacement for findViewById . If you also want to automatically bind views in XML you can use the data binding library. Both libraries can be applied to the same module and they’ll work together.

When both are enabled, layouts that use a tag will use data binding to generate binding objects. All other layouts will use view binding to generate binding objects.

You can use data binding and view binding in the same module.

We developed view binding in addition to data binding because many developers provided feedback that they wanted a lighter weight solution to replace findViewById without the rest of the data binding library – and view binding provides that solution.

View binding and Kotlin synthetics or ButterKnife

One of the most common questions asked about view binding is, “Should I use view binding instead of Kotlin synthetics or ButterKnife?” Both of these libraries are used successfully by many apps and solve the same problem.

For most apps we recommend trying out view binding instead of these libraries because view binding provides safer, more concise view lookup.

While ButterKnife validates nullable/non-null at runtime, the compiler does not check that you’ve correctly matched what’s in your layouts

We recommend trying out view binding for safe, concise, view lookup.

Learn more

To learn more about view binding check out the official documentation.

And we’d love to hear your experiences with #ViewBinding library on twitter!

Источник