Android studio setvisibility kotlin

From Kotlin synthetics to Android ViewBinding: the definitive guide

Binding your views like a pro in 2 minutes.

Since Kotlin 1.4.20, JetBrains deprecated the kotlin-android-extensions plugin in favor of Android View Binding solution.

If you have been using this plugin, it’s time to move on before this feature is completely removed (or switch to Compose?).

For having completely refactored our Android application to use View Binding, we know that it can be somehow painful and sometimes it looks less simple with this new solution. For example, the binding of your view will have to be done differently if you’re working with an Activity or a Fragment. If your layout uses include there are some tricky ways to handle them too.

That’s why we’ve been implementing some convenient methods to make it simpler.

Setup

If you’re refactoring your whole application code, we advise you to do it module per module to avoid committing too many updates.

Enable view binding

To enable the ViewBinding feature, you just need to enable this build feature on your module build.gradle files:

Remove android extensions plugin

If you’ve been using kotlin-android-extensions before, remove the plugin from the build.gradle file too:

Don’t forget to also remove the Android Extensions experimental flag:

Parcelize annotations

The Parcelize annotations have been moved to another package & the previous one has been deprecated.

So, if you used the Kotlin Parcelize annotation to automatize the implementation of your Parcelable objects, you’ll need to use the new plugin :

Then, replace imports in your code from kotlinx.android.parcel to kotlinx.parcelize.

Activities

To set up an Activity to use your binding class you basically have to:

1- Declare a late init variable for your binding class.

2- In the onCreate method, inflate your layout using the static inflate method from the generated Binding class.

3- Call the Activity setContentView with the root view from your binding class.

We can definitely make it way shorter using some extensions:

Our viewBinding method is a simple delegate that inflates lazily the view of the activity by using the inflater method given as a parameter.

In the Activity we just need to declare the binding as a simple val property and set the content view of the activity.

Fragments

Using View Binding in Fragments is quite less easy as you have to do many things to make it works:

1. 1- Declare a var property for your binding class instance.
2. In the onCreateView callback, inflate the layout for your binding class & return the root view of it.
3. To avoid potential leaks, reset your binding class to null in the onDestroyView callback.

As per the official documentation, it should look like that:

That’s a lot of code to add & you should also pay attention to potential leaks on the binding class. This can also be disturbing as the method is quite different from using it in an Activity. Note that you also need to use the !! operator to hide the nullability of the original field.

There’s a lot of room for improvement here and I found a way better solution to deal with it in 1 line:

Yep, really simple!🚀

Here are some explanations:

1. We pass to the Fragment constructor the id of our fragment layout, which will be inflated for us.
2. We declare the binding property that will handle the fragment lifecycle work for us.

Have a look at this Gist:

Our viewBindingWithBinder simply instantiate a delegate object that will bind the view of our fragment lazily. As the Fragment already inflate the view from the layout id that we pass to it in its constructor, we just need to bind our binding class from it.

The FragmentAutoClearedValueBinding class is the one that will be responsible to clear the reference to the binding class when the fragment gets destroyed by adding an observer to its lifecycle. In the getValue method, we bind the view to our binding class the first time we access our binding property from our fragment.

ViewHolder

If you’ve been using Kotlin synthetics, you probably have something that looks like this:

You can now remove the usage of LayoutContainer and make some updates in your view holder:

Here we have simply changed our constructor to take the binding class in parameter instead of having a view object.

To instantiate your view holder, you can create a static method in a companion object:

Includes

In your layouts, you probably have views that are included in your layout using the include tag. Then, you must be aware that it can be tricky to deal with it with view binding.

With a view group

If your included view has a root view that is a ViewGroup (LinearLayout, FrameLayout, etc.) then you can set an id to the include tag in your main layout.

The generated LayoutBinding class will have a property mergeLayout of type LayoutMergeBinding that reference the layout_mege layout views.

So in an activity, you can easily reference your TextView as:

With a

If your included view uses a tag in it like in this example:

And your main layout is:

Then, the layout_merge.xml file content will be merged into your main layout. But, the binding class will not expose a property titleLbl (it will only contain your root LinearLayout ) 😭.

So, what can you do to access to your titleLbl ? You’ll need to re-bind your view with another binding class. As each layout files have its own binding class, your layout_merge layout will have a LayoutMergeBinding class generated. That’s the one we will use to retrieve our views.

From an activity, you can add another property for the 2nd binding class:

The mergeBinding property will then allow you to access the titleLbl view.

Conclusion

We hope this article was useful to you if you’re still refactoring your views to use ViewBinding or to give you some hints to refactor how you’re using it.

And you, how did you implement it into your app? Don’t hesitate to share with us your tip&tricks!

If you want to join our Bureau of Technology or any other Back Market department, take a look here, we’re hiring! 🦄

Источник

Exploring Kotlin initialization with Android custom views

A closer look at the relationship between Kotlin and programmatic/dynamic view inflation

Today, we explore the question “Where does initialization occur around the lifecycle of a view?” This is topic my teammates hotly debated over for months, so I’ve decided to see for myself. This blurb covers two ways of inflating a custom view for comparison: via layout resource and programmatically.

For this exploration, we look at a small compass application. For convenience, you can download the code on Github to follow along/run the app on your own device.

This app uses View Binding and a custom view to spin the needle based on where the user’s device is facing. The two different cases exist on different branches from the main branch.

When are Kotlin constructors and init blocks called?

Like Java, Kotlin can declare multiple constructors, but makes a differentiation between primary and secondary constructors. Both are denoted with the keyword constructor .

In most cases, a Kotlin class will only use a primary constructor. If there are no visibility modifiers or annotations, then a class can omit the constructor keyword. A Kotlin class without a primary constructor exists will generate one that does nothing.

A primary constructor may also include an initializer block denoted with the keyword init . The initializer block executes the logic as soon as the class is initialized as part of the primary constructor.

Secondary constructors are mostly used for Java interoperability. For the case of CompassView below, no primary constructor is declared, but multiple secondary constructors are:

These secondary constructors will delegate to the proper constructor in the super class, or find one that does. But in what order, specifically, would a secondary constructor execute in relation to the primary constructor?

From Kotlin official documentation:

Delegation to the primary constructor happens as the first statement of a secondary constructor, so the code in all initializer blocks and property initializers is executed before the secondary constructor body.

In CompassView , the initialization block executes before the secondary constructors do. But where does Kotlin class initialization fall in relation to the View lifecycle, exactly? We answer this by examining how a view is inflated.

What happens when a view is created?

The answer depends on how a view is added in a tree. On the screen, all views in Android exists in a single tree. You can add views to that tree two ways:

• Programmatically: adding a View to that tree.
• XML: specifying another tree to via an Android layout file.

In our compass application, we inflate our custom CompassView on to the MainActivity as the only custom view component. This article demonstrates the differences between inflating a custom view both via XML ( CompassView(context, attrs) ) and code( CompassView(context) ).

Case 1: Custom Kotlin View inflated via XML

When you put a view element into an XML file, Android will use a LayoutInflater to parse and map the corresponding objects in the XML to the inflated Views. LayoutInflater retrieves the resource by opening up ResourceManager and examining all the possible layouts it could match within its current configuration. Android will then parse back the appropriate binary XML resource.

For CompassView(context, attrs) the second argument will utilize the properties necessary to tell the view hierarchy how to size and place the element in the tree. This post does not focus on these phases (Measure/Layout/Draw) of the View lifecycle, but there is a totally awesome talk from Drawn out: How Android renders (Google I/O ’18) that dives deep down into the mechanisms for whomever is curious.

This process of inflation is then repeated for its children and its children’s children, recursively until all views have been inflated. When inflation is complete, LayoutInflater sends a callback onFinishInflate() from the children views back up to the root to indicate the view is ready to interact with.

Now that we’ve described the process a bit more, let’s examine the code needed to instantiate our custom CompassView with XML:

In MainActivity , the CompassView via the view binding reference from the XML. When initializing the custom view this way, the default secondary constructor is executed:

The Kotlin initialization block is called first, then the secondary constructor CompassView(context, attrs) . Remember, there is no primary constructor for extending a View class (unless you create one yourself), so it makes sense that init is executed first before the secondary constructor does. Because calling CompassView(context, attrs) uses LayoutInflater , the onFinishInflate() callback is made when all views have finished inflating.

Case 2: Custom Kotlin View inflated programmatically

For the most part, initializing views via XML is the preferred way of creating view elements in Android since it becomes part of the tree view hierarchy. There are advantages to this: using XML is much more friendly for Android memory since it can compress easily, and helps to take off runtime workload a programmatic draw might have to do.

Suppose you have a case where you cannot include the creation of a custom view in the XML, but rather, you must initialize the view only at runtime.

This is what the code might look like:

As you can see, there’s a significant work load setting up the UI programmatically just to make the CompassView element fit in with ConstraintLayout. This particular case would be incredibly impractical in real life, but there is a special reason we talk about initializing CompassView(this) . To demonstrate, we’ll run this code:

Like the previous case, the Kotlin initialization block executes first, then the secondary constructor CompassView(context) . However, you might have noticed that no onFinishInflate() callback is ever made. This is because CompassView(context) is not instantiated by XML, meaning that no LayoutInflater is put into play. There’s no children to wait on for recursive instantiation, and so there’s no onFinishInflate() for callback.

If you needed to add shared logic for different constructor calls that doesn’t depend on this system call, this might pose a problem for creating more manual view bindings in older code and other UI-related actions.

The Recommendation

You can annotate a custom view with the @JvmOverloads annotation, which tells the Kotlin compiler to generate overloaded methods. Every overload will substitute with default values for any parameters omitted in the generated methods, which means that the code below is equivalent to the CompassView class constructors written in the beginning of this article:

Instead of depending on the system to call onFinishInflate , you can use Kotlin init < >for shared logic (even with views dynamically inflated in the code). Running the inflate method in the initialization block will guarantee inflation occurs no matter how you choose to initialize your custom view.

I hope you enjoyed this blurb: in Android, looking at certain concepts through the lens of Kotlin can shed new perspective to seemingly basic questions. You can find the recommended version of the code on the main project, and additional resources below.

Источник

10 лайфхаков для Android-разработчика: полезные extensions на Kotlin

Авторизуйтесь

10 лайфхаков для Android-разработчика: полезные extensions на Kotlin

Вот несколько советов и extensions на Kotlin, которые будут полезны в ежедневной работе Android-разработчика.

Совет 1: Добивайтесь зелёной галочки

Android Studio предоставляет множество встроенных проверок: от юнит-тестов до линтёра. К сожалению, пока нет хорошего способа убедиться, что на CI нет предупреждений, поэтому мы разместили наш профиль для проверки в репозитории, чтобы все видели один и тот же набор предупреждений.

Затем мы взяли за правило ВСЕГДА избавляться от предупреждений (фиксить или заглушать их). При появлении новых предупреждений (из-за рефакторинга или добавления новых проверок), мы следуем правилу бойскаута (всегда оставляй после себя код в лучшем состоянии, чем до тебя).

Зеленая галочка, которая находится в правом верхнем углу окна Android Studio

Однако есть более сложный случай — точки входа, такие как фрагменты, на которые ссылаются только с помощью рефлексии (Android Studio помечает их как неиспользуемые). Чтобы избавиться от таких предупреждений мы сделали TonalEntryPoint.

Используя эту аннотацию в классе или конструкторе, который помечен как неиспользуемый, и нажимая alt+enter, мы получим возможность добавить неиспользуемый код в список точек входа.

Совет 2: Относитесь к предупреждениям Kotlin, как к ошибкам

Для этого добавим следующий код в файл build.gradle:

Совет 3: Делегат ViewBinding

Мы очень любим View Binding. Он отлично работает, и мы полностью перешли на него с ButterKnife/Kotlin Synthetics. Однако, синтаксис его создания не идеален, поэтому мы создали собственный делегат, чтобы создавать его в соответствии с жизненным циклом, это выглядит следующим образом:

Здесь можно посмотреть полный код.

Совет 4: fadeTo(visible)

Необходимость скрыть/показать view возникает часто. Для улучшения пользовательского опыта мы создали функцию fadeTo() в качестве замены для View.setVisibility() или View.isVisible = true/false.

Код функции можно найти на GitHub.

Совет 5: mapDistinct()

Это простое сокращение для Flow.map().distinctUntilChanged() .

Совет 6: uniqueObservable()

Delegates.observable в Kotlin очень полезен. Однако:

1. Иногда нам нужно делать что-то только при изменении значения.
2. В таком случае писать лямбда-выражение с тремя параметрами и проверку на равенство чересчур шаблонно.

Поэтому мы написали uniqueObservable(), который будет вызывать лямбду только если значение изменится.

Совет 7: Отладка + Корутины и Broadcast Receivers

В настоящее время Broadcast Receivers (широковещательные приёмники) редко используются в Android. Однако они могут быть крайне полезны для тестов в процессе отладки.

Revolut , Удалённо , По итогам собеседования

Мы используем debug-only широковещательные приемники, которые, по сути, дают нам CLI для установки/обновления параметров в коде без необходимости вызывать меню отладки в UI или пересобирать приложение.

Наш coroutine friendly код будет выглядеть так:

Совет 8: ConflatedJob

Корутины часто используются для отмены выполнения Job, перед запуском нового (например когда пользователь делает pull to refresh). ConflatedJob автоматически отменяет старый Job, перед запуском нового.

Совет 9: Timber Property Delegate

Для логгирования мы используем Timber, однако его синтаксис Timber.tag(TAG).i(…) — слишком громоздкий.

По аналогии с View Binding Delegate, мы написали делегат, который упрощает вызов:

Он автоматически создает TAG на каждое свойство (а не на строку журнала, как Timber.DebugTree), сокращает общие суффиксы, такие как «Impl» и «ViewModel» и обрезает теги до 23 символов.

Совет 10: Number.dp

Так как в макетах обычно используют dp, а в свойствах View пиксели, часто в коде требуется конвертировать dp в пиксели. Именно поэтому вопрос о том как это сделать пользуется популярностью на StackOverflow. Мы используем для этого следующий extension на Kotlin:

С помощью этой функции очень просто обновить padding:

Источник