Android custom view attributes kotlin

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.

Источник

Binding Adapters with Kotlin: Part 1

Mar 13, 2018 · 8 min read

Binding adapters are often a point of confusion for those new to data binding, and it’s easy to see why. They are pretty easy for simple cases, but tricky to get right when doing something slightly more complex. Once you throw two-way binding into the mix, things can become overwhelming fast.

But don’t worry, in this series I will cover the f undamentals of writing good binding adapters. By the end of this article, you will see that writing basic binding adapters in Kotlin is quite straightforward — as long as you follow some guidelines. By the end of the series, you’ll be writing binding adapters like a boss.

Wait, do I even need a Binding Adapter?

It depends. There are 3 ways in which a data bound variable can be bound to a view attribute.

Automatic Setters

To borrow an example of automatic setters from the documentation, an expression such as:

Assuming viewModel.textString is a String , data binding will look for a method on TextView with the signature:

It won’t find that as it doesn’t exist, but since String is a CharSequence , it will also look for a method with the signature:

Similarly, with the example:

Assuming viewModel.textResId is an Int , data binding will look for a method on TextView with the signature:

It’s less code to manage if you can get away with using automatic setters, but these are only for the simplest of cases.

Renamed Setters

Renamed setters allow you to associate some custom attribute name with a setter on the view type that it targets. They are useful when a setter on a view has a particularly long method signature, or when you want the renamed attribute to match the real view attribute name. To borrow another example from the documentation:

This is using an automatic setter for setImageTintList , but to shorten it we can create a renamed setter such as:

Then the view attribute becomes slightly leaner:

Personally, I avoid renamed setters as they contain method names as string literals. Also, the BindingMethods annotation needs to be associated with a class, which may or may not be completely empty such as ImageViewBindingAdapters above. In the end it’s a matter of taste, the same can be achieved with super simple binding adapters.

Custom Setters

Custom setters, aka binding adapters should be used when you need to do something slightly more complicated, such as fetching an image then setting it on an ImageView when it’s ready. Or simply when you need a middle man between data binding and the view to do some translation from the type passed to the binding adapter to a different type that is passed to the view. Also if you simply want to avoid using renamed setters, you will need to use binding adapters. They can also be used when you need to update multiple attributes on a view at the same time, or if you want to get feedback from the view back to the view-model.

Slow down! What is a Binding Adapter exactly!?

A binding adapter is simply a static or instance method that is used to manipulate how some user defined attributes map data bound variables to views.

Again, to elaborate on an example from the documentation, say we want to set the left padding on a view. The problem is that the method View.setPadding takes 4 parameters, so automatic setters won’t work here.

We could write a binding adapter for a single padding, for example:

Or we could write a binding adapter to facilitate setting all padding attributes:

Extension Methods?

You may be wondering why they are written as extension methods, there are two reasons for this. It makes it clearer the type of view that the binding adapter targets, and in most cases it makes the method body leaner.

The reason they work as extension methods is because top level extension methods are translated to static methods, where the receiver type (the type to the left of the . ) becomes the first parameter in the underlying JVM method signature. This results in a valid binding adapter that the generated Java code can call.

If you are writing binding adapters as extension methods as part of a library, it may be desirable to mark them as internal to hide them from Kotlin code in modules that consume the library. Since they are still callable from Java code in consuming modules, the generated data binding classes can call them without issue.

Parameters and Attributes

A binding adapter must have at least 1 attribute. The amount of attributes must match the amount of parameters that the binding adapter accepts plus one, as the first parameter is the view in which it operates on, aka the receiver of the extension method. The attribute «android:paddingLeft» is associated with the paddingLeft parameter and so on.

By default, requireAll is true, by setting it as false simply allows us to omit the attributes in the xml layouts that we don’t care about.

Binding adapters with reference types

We’ll return to the padding example later, for now let’s say we have a custom view called UserView , it will be responsible for displaying the first and last name of a UserViewModel .

UserViewModel will look something like:

If you read my last article, you’ll know how I feel about properties like this, but lets keep it simple as the focus is on binding adapters.

UserView will look something like:

Disclaimer: I wouldn’t normally write such a trivial custom view, it’s just easier to explain from scratch as TextView and EditText already have a lot of out the box binding adapters from the framework.

You can see the UserViewModel and UserView have almost matching properties, i.e. they both have firstName and lastName properties. On both the UserView and UserViewModel these properties are reference types, i.e. they are not primitive types.

What do you mean by this?

In Kotlin, the basic types such as Double , Float , Long , Int , Short and Byte are represented as JVM primitive types, where all other types are reference types (non primitive). If any of these basic types are marked as nullable, their JVM representation will be their boxed primitive equivalent, allowing them to be null.

We’ll get to why this is important soon.

The naive approach with automatic setters

The layout xml would look something like:

We haven’t written a single binding adapter yet, but this will still compile as it will use automatic setters. However there is a flaw with this that can cause it to crash at runtime. If the generated binding class evaluates the bindings before a UserViewModel is given to it, a NPE will be thrown.

Data Binding doesn’t respect non-null reference type parameters

That’s right, so when combined with Kotlin, things can get ugly. Both the firstName and lastName properties of UserView are non-null reference types, meaning that if data binding decides to pass null, it will crash. Right down at the bottom of this section of the data binding documentation, it states:

If the expression cannot be evaluated due to null objects, Data Binding returns the default Java value for that type. For example, null for reference types, 0 for int , false for boolean , etc.

Now matching that up with the Java to Kotlin interop documentation which states:

When calling Kotlin functions from Java, nobody prevents us from passing null as a non-null parameter. That’s why Kotlin generates runtime checks for all public functions that expect non-nulls. This way we get a NullPointerException in the Java code immediately.

Unfortunately the data binding compiler doesn’t check the nullability of reference type parameters in our code, be it through automatic setters or binding adapters. This means the underlying JVM setters for our Kotlin properties will throw a NPE when the generated data binding class passes a null to them. Ideally it would detect this and fail during compilation.

This could be solved by changing the UserView , but lets assume we can’t change it for now. It can be tempting to create custom views to make our lives easier with data binding, but we often find ourselves in situations where we would rather use view classes from the SDK, or those from the support libraries directly without subclassing them. In most cases we should try to keep any data binding related peculiarities away from the view directly, and deal with them inside binding adapters.

How do we solve the null problem without touching the View?

By using binding adapters with nullable parameters, for example:

Here we simply guard against null by interpreting null as an empty string, it’s as simple as that!

Wrapping up

It is important that parameters of binding adapters written in Kotlin are nullable when those types are reference types such as CharSequence . Basic types in Kotlin can safely be non-null parameters of binding adapters. This is because they are represented as JVM primitives which cannot be null, in which case data binding will pass the JVM defaults for those primitive types. That said, you should take care when doing this as the default values may be undesirable. To avoid this you can simply make the parameter type nullable which will translate to the equivalent boxed primitive reference type. This will cause data binding to pass null instead of the default value for the primitive equivalent.

Returning finally to the padding example, this is one such case where nullable boxed primitives may be desirable over the defaults for the JVM primitive types.

Lets say the view in the xml layout looks like this:

Only android:paddingLeft will be set via the binding adapter as it is the only padding attribute that uses a binding expression, aka:

Where the others will be set in the traditional way. However when this binding adapter is called, the default value 0 will be passed for the missing padding attributes, wiping out their current value. This can be fixed by making the parameters nullable boxed primitives such as:

Now null will be passed for paddingTop , paddingRight and paddingBottom , where the binding adapter will ignore them, so the existing values will not be wiped.

Where to next?

Many view types have event listeners for listening to changes in the view, for example from user input. A classic example of this is by adding a TextWatcher to an EditText . In part 2 we will look at how to add similar functionality to our somewhat contrived UserView — without all the bells and whistles of actually handling user interaction like EditText does.

Источник