Which naming convention works well for Kotlin Android extensions

Question

Using Extensions for android extensions Kotin I can avoid using findViewById , but I'm not sure how to name identifiers for proper use.

I found two options:

• Use simple names for ids , but then I can get into the problem with espresso if I use it with slices :

android.support.test.espresso.AmbiguousViewMatcherException: 'with id: ... / mainLayout' corresponds to several views in the hierarchy.

This is because I have two fragments inside a TabLayout with the same identifiers:

 <LinearLayout android:id="@+id/mainLayout" 

2. Owner name: "@+id/loginMainLayout" and "@+id/signUpMainLayout"

But then I have to use variables like signUpMainLayout.doSomething() .

Note. I do not like the use of _ in this case, since this is not a good style.

What other options are there?

Answer 1

I cannot understand why not using "@+id/loginMainLayout" and "@+id/signUpMainLayout" when the name is in lowerCamelCase , which is common in kotlin and java. the use case will be signUpMainLayout.doSomething() , as you said.

In any case, it is good practice to use unique names for id in the whole application. this is not due to Espresso, but mainly to find out where the view is associated with the identifier when you see the ID name. it is not difficult if you use this style. Example:

in fragment_contacts :

 <TextView id="+id/contactNameText android:text="John Smith" .../> <ImageView id="+id/contactUserImage .../> 

assert: there is an Image in contactUserImage , because it is ImageView.

in fragment_settings :

 <TextView id="+id/settingsNotificationText android:text="Turn notifications on/off" .../> <checkBox id="+id/settingsNotificationCheck .../> 

Answer 2

in my case, I worked using this agreement https://jeroenmols.com/blog/2016/03/07/resourcenaming/ , but without underlining in the case of the camel case.

If you notice when you drag the control into the view, in android studio, it calls the identifier using the camel case convention.

And while variable names may be slightly larger, you can always use val or var in a variable declaration.

considers