I am testing the Tiktok app.
I am not the owner of this app.
Every app update the resource ID names get updated with new names.
What is the best solution to fetch elements without resource id and keep of stable testing?
The resource id name is changing because the app is obfuscated and every time you obfuscate the app new identifiers are generated for resource ids, class names, field names, variable names, method names, ...
To identify a certain UI element you can try to assume the UI does not change much which means you are trying to specify the element in their order, e.g. the 2nd button. I am not sure if the layout inspector still works this handy tool of Android Studio was able to read out the current shown layout with all the UI elements and their names and types.
Alternatively you can try to parse the layout and/or fragment XML files. If their file name is obfuscated, too you could identify the relevant layout XML file once by hand and next time compare all the layout cml files of the old and the new app versions and order them how close they are to each other on text level. The closest match to the file you have identified by hand is most likely the layout xml file you are searching for.
Use user-facing selectors like text or even content description when available (if the app is well designed it would be what the screen readers see).
If you are not the app owner, you should not rely on stuff you can't control like ids.
I was searching for difference in #id/ and #+id/ in our XML layouts. I got another question in my mind, Should we use different name for every component declared in layout for our application ?
I know that we can not declare two components with same name in a layout,
But if i talk about entire application. I use same name in other layouts.
Is this the correct way of coding ?
This answer quote that when we declare #+id/ there is new entry in R.java file, If i add same name component in other layout, Will it create other entry in R.java file ???
I am confused in this, and what is the right way of declaring names in XML layout.
Any help would be appreciated.
If you use #+id notation in multiple places, it will not create a new ID value each time it's used. The compiler will reuse the same ID for each of the same name in the same app.
You can use the #id notation when you know you are referencing an existing id. This is common when using relative layouts where you want to align some view with another view of some id in the same layout.
You should use the different name for each view in your application. And for difference for #id and #+id read the content in the following link you understand better Difference between "#id/" and "#+id/" in Android
I've come across some android native code where the strings.xml in android would be named strings-global.xml and likewise the styles.xml would instead be called styles-global.xml. how is android identifying this ? what does it mean ?
The naming of files within the values\ folder is arbitrary. What resources the file provides is defined by the contents of the file itself, not the name. Which resources are used in a given configuration is determined by qualifiers on the values\ folder (e.g. values-fr), not the file name.
You could even mix and match resource types in a single file if you really wanted to, though I recommend following convention.
From the Providing Resources documentation for the values\ folder:
Because each resource is defined with its own XML element, you can
name the file whatever you want and place different resource types in
one file. However, for clarity, you might want to place unique
resource types in different files.
In this case, it sounds like the developers discovered that their styles.xml was getting too large and/or they found that they had a few distinct categories of styles that they wanted to separate, and thus put them in different files to keep them more organized.
It is already well established that dimensions, colors, and other resource related values should be stored in their respective XML file. However, is this still appropriate when creating a library? Defining these resources in a library's XML file would perhaps bring confusion to anyone using the library. Are there are recommended practices for defining resources in a library project?
yes one giant one .. prefix the resource name both in the id and the xmlfile name as resources with same names often clash with parent stuff that has the same name
Are there conventions how to name resources in Android? For example, buttons, textViews, menus, etc.
Android SDK will be a good place to start.
For example, I try to scope IDs within the activity.
If I had a ListView it simply would be #android:id/list in all the activities.
If, however, I had two lists then I would use the more specific #id/list_apple and #id/list_orange
So generic (ids, ...) gets reused in the R.java file while the unique ones (sometimes gets reused) get prefixed with generic ones separated by an underscore.
The underscore is one thing, I observed, for example:
Layout width is layout_width in xml and layoutWidth in code, so I try to stick to it as list_apple
So a Login button will be login, but if we have two logins then login_foo and login_bar.
I don't know whether there are any official recommendations.
For ids in my layouts with widgets and containers, I use the convention:
<layout>_<widget/container>_<name>
I do the same strategy for any dimens, strings, numbers, and colors I use in those layouts. However, I do try generalizing. e.g if all buttons have a common textColor, I won't prefix the name with the layout. The resource name would be 'button_textColor'. If all textColors are using the same the resource it will be named 'textColor'. For Styles, this is usually the case as well.
For menu resources i use:
menu_<activity>_<name>
Animations are only different as you cannot use uppercase letters. Same goes for drawable xml resources, i believe.
Taken from Android's documentation. There is more there on the subject.
To answer your question: Yes, there are.
You can find many of them via google search for example. And there is no such thing as the best naming convention. It always depends on your needs and your project attributes (most importantly the scope).
Recently, I've read quite good blog post about naming resources in Android XML from Jeroen Mols. Author mentions the basic principle all resources should follow and then how this convention is applied to each resource type. Both described on Android resource naming cheat sheet:
He then describes each element and each resource type in detail.
I would say you could use this convention from small to medium projects (personal use, few months contract applications). Although, I would not recommend it for long time projects with like 50+ activities or 1000+ strings.
Conventions for resource values in projects of such a large scale requires more investigation on how they will be used. Take strings for example. Might be affected by size of your team, translation center you are using (if any), VCS you are using (to avoid merge conflicts for example), etc. You might even think about splitting strings into multiple files.
I assume you are looking for something to begin with. So I would recommend the blog post I mentioned. It's good for starters and you can definitely use it as inspiration to create good naming conventions of your own.
Also keep in mind that as a project grows, many needs and requirements may change in time. So its completely normal that naming conventions that were suitable in the beginning will not be suitable after 2 years. And it's completely fine. You should not try to predict future. Just choose a convention and follow it. You will find if it is suitable for you and your project. If its not, think about why it is not suitable and start using something else.
There are a few conventions used in resources:
For resources that exist as separate files, they must be lower_case_underscore_separated. The appt tool makes sure that your files are only lower-case, because using mixed case can cause issues on case-insensitive filesystems.
For resources declared only in values/... (attributes, strings, etc) the convention is generally mixedCase.
There is a convention used sometimes to tag names with a "classification" to have simple namespaces. This is for example where you see things like layout_width and layout_alignLeft. In a layout file the attributes for both the View and the parent layout management are mixed together, even though they are different owners. The "layout_*" convention ensures that there are no conflicts between these names and it is easy to understand which entity the name impacts.
This "layout_blah" convention has also been used in a few other places. For example, there are "state_blah" attributes which are the drawable states a view can have.
Also because of these two conventions (underscore_separated for files, mixedCase for declared resources), you will find a number of inconsistencies. For example colors can be declared with either files or as explicit values. Generally we'd like to stick with underscore_separated for all of those, but it doesn't always happen.
Ultimately we don't worry a whole lot about naming conventions for resources. The big one that we keep consistent is "mixedCase" for attributes, and the use of "layout_blah" to identify layout param attributes.
Also browsing through the public resources here should give a good feel for the conventions:
http://developer.android.com/reference/android/R.html
You'll see the attributes are all quite consistent (given you understand the layout_ convention), drawables are all underscore_separated, etc.
This is a common problem to any language or framework, but so long as you avoid reserved words you should be ok assuming you can remember what you have called things.
I did note that Android places a restrction on xml resource file names but underscores seem to be ok. ADT actually states
File-based resource names must contain only lowercase a-z, 0-9, or _.
Something that tripped me up at first was a lack of namespaces with id's, but this can generally be ignored if you have two id's the same Android will just reuse the defined id.
For id's I use a 3 letter qualifier followed by what it refers to in camel notation e.g lblFoo for a static text label (or textview), txtFoo for an editable textbox (edittext in Android). This may seem odd at first but I've been using it since VB6 and those controls were called label and textbox.
Here are some more I commonly use:
btnFoo - button
pwdFoo - password
lstFoo - list
clrFoo - color
tblFoo - table
colFoo - column
rowFoo - row
imgFoo - image
dimFoo - dimension
padFoo - padding
mrgFoo - margin
I use the same in code within the java file too so I don't have to think about it, package scope will allow this quite happily:
Button btnFoo = (Button)findViewById(R.id.btnFoo);
You could if you prefer add a little spacing using underscore i.e btn_foo ... I probably would do this if I could break old habits.
There are those who may argue that abbreviating these may not be ideal and the purists would argue that the full name should be used, but when you are naming dozens of controls and changing between different systems and frameworks, the full names lose their meanings, I have used these for over a decade in VB, C++, ASP.NET, WinForms in C# and VB.NET, Android and Python. I never need to remember if Android calls it a textbox or an edittext. All I need to know is that lblFoo is the static label and txtFoo is what the user types input into.
One final note is that no matter what convention you decide upon the important things is naming controls properly and consistently, so that you don't wrestle with vague default id's e.g TextView5 or a mixture of different conventions
Useful link for designer and developers - here
Dimensions and sizes, naming conventions, styles and themes, nine-patch and so on.
I don't think there is any standard convention promoted by Google. I've seen all kinds of different ways people name stuff, even within different official Google apps.
Whatever helps you the most when trying to make sense of a 100 layout (or drawables, menus, etc.) files in one directory hierarchy.
A short answer: if you would like to learn from Android developers, a good example is the support library v7 (https://dl-ssl.google.com/android/repository/support_r21.zip)
Otherwise, here's what I have considered for naming resources:
1. finding resources easily when writing code
2. understanding resources easily when reading code
3. making names useful for translators (R.string.* resources only)
4. reusing layouts with <include/> (R.id.* resource conflicts)
5. dealing with library projects
Logically, arranging resources should be no different than grouping java classes into packages (or putting files into folders). However, since Android resources have no namespaces, prefixes must be added to the resource name to achieve the same (e.g. com.example.myapp.photo becomes com_example_myapp_photo).
I suggest to divide the app into separate components (activities, fragments, dialogs, etc.) with short unique names that can be used as resource prefixes. In this way we're grouping resources with related functionality together, which makes them easy to find (point 1) and we're at the same time avoiding naming conflicts with both <include/> and library projects (points 4 and 5). Note that resources common to multiple components can still have a prefix (such as R.string.myapp_ok_button).
After the prefix, the name should tell us what the resource is used for (action to be performed, content to be displayed, etc.). Choosing a good name is important for understanding (points 2 and 3).
Sometimes "component_name" will give us enough information, which is especially true if the type is already given by the R class (in R.string.myapp_name_string the 2nd "string" is redundant). However, explicitly adding type can improve understanding (e.g., it can be helpful for translators to distinguish between a toast, or a label). Sometimes the "name" and "type" parts can be swapped to allow type-based filtering (R.string.photo_menu_* will give us only menu-related items for the photo component).
Let's say we're writing an activity for taking pictures, class com.example.myapp.photo .PhotoActivity. Our resources could look like this (grouped by the component "photo"):
R.layout.photo //if only a single layout is used
R.menu.photo
R.string.photo_capture_instructions_label
R.id.photo_capture_instructions_label
R.id.photo_capture_button
R.id.photo_capture_image
R.drawable.photo_capture_placeholder
R.dimen.photo_capture_image_height
If you poke around in Android's documentation, there are various mentions of "best practices", but there are certainly no concrete rules. For example, in Icon Design Guidelines, Google suggests naming icons with a "ic_" prefix.
A good place to start may be Providing Resources.
Also dig around in the SDK source/examples as well as on the Android Developers Blog if you want to see how the Google developers do things.
I found handy next naming convention for strings:
[<action>]_<object>_<purpose>
For example, clear_playlist_text, delete_song_message, update_playlist_positivebutton_text. And "action" here is optional.
I generally followed the java naming conventions for resource ids(not for files for files) except I added "x" in front of the ids for example:
<TextView android:id="#+id/xTvName" android:layout_width="wrap_content" android:layout_height="wrap_content"></TextView>
In java
we can use it simple(we can also rememberin simple)
TextView mTvName=(TextView)findViewById(R.id.xTvName);
Here mTvName(It is in general android suggested naming conventions) and xTvName which was named in layout file as part of android TextView's Id(x meant for XML),I followed this type of naming conventions for view objects such as Buttons and EditText etc.
in XML IDS:xViewTypeSpecificName
in Java:mViewTypeSpeficName
The above conventions makes my life easier when I create complex layouts.
Just try to make your names as much as possible short in length and it is better if they are understandable and meaningful to other co-developers(but it may not possible every time),Hope that my experience will help others,suggestions are welcome.
In our android projects there are lots of components like buttons, labels, textboxes. So simple name like for example "name" this is very confusing to identify "name" is label or textbox. Mainly it happen when you are maintaining projects developed by some other developers.
So to avoid this kind of confusion I used following names for Buttons TextBoxes or Labels
Example :
btnName
labName
txtName
listName
May be this is helpful for you.
you can read the google documentation for code style to get an idea here
There are some restrictions:
Resource name should contains be a-z,0-9,_
Resource name should start with a-z,_
By the way, it is more advisable to follow the guidelines or to learn from standard code.