Develop Reference

Android viewBinding is not binded some views in layout

I have a problem with viewBinding. I use buildTools 28.0.3 and Android Studio 4.1.2
I have a layout with more than 50+ views. The binding class is generated normally but there are around 40 views that has been generated. I cannot figure out why the rest views are not generated. They are the same view's type as the generated views.
Anybody face this issue before?

I found the cause of this issue. It's because I include "&" in layout file (even I put them in comment secion). I remove that character and re-build then everything is good.

Are there any cons when using view binding rather than findViewById?

Since I discovered the use of view binding by enabling
buildFeatures {
viewBinding true
}
in my gradle file, I never used findviewById in my code again. I wonder now if there is a cons to doing things this way.
If this is the best method, why does android studio not enable this option by default when creating a new project? If not, when should I avoid using view binding? thank you.

Once you enable it for a project, view binding will generate a binding class for all of your layouts. That's the only "con" I see, it just generates more code, so it would increase the size of the project, compile time, etc. While it won't be a huge difference for projects with very little layouts, it could change significantly for larger projects.
Here's a very interesting read about ViewBinding performance : https://blog.stylingandroid.com/view-binding-performance/

Why ToolbarPlacement doesn't work anymore in xaml

I'm new in xamarin and I wanted to put my TabbedPage in the bottom in Xaml by using this tutorial:
https://learn.microsoft.com/fr-fr/xamarin/xamarin-forms/platform/android/tabbedpage-toolbar-placement-color
Then, when it didn't work, I tried to rebuild the project like suggested in this stackoverflow question:
Where can I find ToolbarPlacement attribute of TabbedPage?
I saw some people using a old nugget package, but I don't really want to use it, especially if there is a native way of doing it.
Xamarin forms version : 4.1.0.555618
Android version : 9
I hope there is someone that have the same problem as me,
Thank you in advance,
halonico,

Setting the placement and color of the toolbar on a TabbedPage, you just add the following code:
xmlns:android="clr-namespace:Xamarin.Forms.PlatformConfiguration.AndroidSpecific;assembly=Xamarin.Forms.Core"
android:TabbedPage.BarItemColor="#666666"
android:TabbedPage.BarSelectedItemColor="Red"
android:TabbedPage.ToolbarPlacement="Bottom"
Although there are still many mistakes, you don't meed to worry about these, you try to clean your project, then build your project directly, you will see it works fine.

Performance in XML layout vs layout in code?

Is there any performance difference between layouts done in code vs XML layouts in android?

Yes. XML layouts need to be loaded, parsed and inflated to generate the View. Behind the scenes the LayoutInflater does exactly what you would do when writing layouts through code, but with the overhead mentioned before.
Here is an interesting article on this topic, which covers View generation through code, also it is about a library written in Kotlin: https://nethergrim.github.io/performance/2016/04/16/anko.html
But even though there is a performance win, I would not recommend to write layout in code for the following reasons.
You couple your layout and your business logic. That's always bad.
You can't use the features of the AppCompatDelegate (loading Views for the latest Androind version. E.g. an AppCompatButton instead of a normal Button.

As far as i know, i can make one difference. Please correct/enhance my answer if possible.
For XML based, In compile time, the ID generated and stored in R file which we use to refer to that any particular layout(like TextView, Button etc.) inside our code. As the reference ID is getting generated at compile time, so at run time this overhead is not there and it is faster.
In code based, all things done at run time which makes the app slow. It is not that much visible if small number of layouts are there. But if you are creating a lot of Layouts pro-grammatically, then you may realise the slowness in your app.

Its hard to imagine that using XML would ever be faster.
Android SDK has a lot of performance tweaks to make loading and parsing XML fast. in recent times, if you use data binding to replace findViewById this dramatically improves performance as well as each call to findViewById parses the XML tree. Where as databasing will only parse the tree once.
Also, using include in XML allows for reuse of Views which improves performance especially in cases where you would have large object churn. There is all sorts of I eternal caching and pooling of objects as well so it's possible that inflated objects are cached/pooled and cloned for subsequent use reducing the overhead on using XML. I know this is definitely the case for Drawable assets hence the need to call mutate if you ever plan on modifying one.
There are scenarios where code would be slower, with every View you create and add to your layout, you will trigger a measure and layout pass, so if you try to build a complex, deep nested layout using code at runtime, this would take a lot longer to load.
There are other factors to consider, like:
styling is hard if not impossible to apply at runtime.
code with views created complete runtime mY be complex, hard to maintain and bug prone.
You can use ConstraintsLayout to flatten your views hence avoid writing custom ViewGroups if performance is an issue.
XML allows use of the editor to preview and debug your layouts.
If the ViewGroup you want to create is simple, or simply want to create a single View and insert it into a ViewGroup, doing it in code is probably hard to beat by any criteria.
If you want to do something a lot more complex, using XML and all its features like ViewStub, includes, DataBinding is probably the way to go. I have noticed that inflating Views can be visibly slow, if you do it a lot, hence the ViewHolder pattern, but if you're careful, it's hard to justify ever building Views and ViewGroups in code for any thing but simple layout additions.

Customizing a project library in Android

I'm using this library project in my Android application. But I need to make some customization for it.
For example, if I need a EditText instead of the provided TextView, what is the best practice to customize the library for my needs without writing code in the Project Library?
I made this customization by defining in the library's actionbar.xml layout a EditText instead of TextView, but I don't like this approach.
Do you have any guidelines, tutorials that could help me out?

In your special case I would suggest to use original compatibility's-package actionBar.
But to answer your question: you could always extend classes from the Library, which I think is the best practice if the library should kept untouched. Overriding Methods which you want to change their behavior keeps anything clean. You do the exact same every time you extend android-sdk classes, which you cannot change like you want.
In the case of changing layouts I'm not quite shure. I think I can remember that if the lib has an actionbar.xml and you have an actionbar.xml inside your project, too, yours will win. just like an "overriding layouts" feature