Android hierarchyviewer shows a ID for each view in the tree view.
The ID is a # sign followed by a number, e.g #4051d698
In android documentation the purpose of this number is explained as "pointer to view object".
Assuming one has the sources of a very big android project like AOSP.
How can one figure out what is the java source code behind the view by using this ID?
Is there a method I can invoke that tells me what is the R.java entry that is bound to this pointer?
How can one figure out what is the java source code behind the view by using this ID?
You can't, at least without a debugger. If you are used to C/C++ development, that hexadecimal value is roughly analogous to a pointer. Just because you have a pointer to a hunk of RAM in C/C++ does not mean that you can determine the source code behind the object resident at that pointer.
Now, it is possible that there is a way in a debugger to supply this hex value and the debugger will match that up to an object and source code. I am not an Eclipse expert, or an expert on another other IDE debuggers, to know whether or not there is a means to do this. However, even if can do this, it will probably only give you the source of the class of the object (e.g., if the View is a ListView, it might send you to the ListView source code), not the source code of what created the object.
Is there a method I can invoke that tells me what is the R.java entry that is bound to this pointer?
First, R.java is not "bound" to any pointers.
Second, the View in question may not have come from an inflated layout. It might have been created directly in Java code instead.
If the View has an "View object ID" (e.g., id/content), that can better help you find where it came from, as that will be an android:id value, possibly from your layout resources.
Related
Whenever we want to inflate a view or get a resource we have to cast it in run-time. views, for example, are used like so:
In the past, we would have needed to cast it locally
(RelativeLayout) findViewById(R.id.my_relative_layout_view)
Now, we use generics
findViewById<RelativeLayout>(R.id.my_relative_layout_view)
my question is why doesn't the compiler(or whoever generates the R class) doesn't also keep some kind of a reference to the type of the element(doesn't matter if it's a string or an int or any other type) that way casting problems should not occur
We cannot really speculate on that, that would be a design choice.
It might be that they wanted to avoid bloating the APK. Every ID would need a full package name to the class. So would each ID in android.R too. Since R is packaged in every APK.
Solutions
However, if you are using Kotlin, you can even do away with the generics check. Kotlin will determine it automatically.
val view = findViewById(R.id.my_relative_layout_view)
view.method()
Or event simpler, if you use synthetics:
my_relative_layout_view.method()
Also, if you are using data bindings, you can just access it like this:
binding.my_relative_layout_view.method()
I have been working on a simple android tutorial and while browsing through the project folders I found this R.java file in gen folder...
When I opened it seemed to me as a mess...
first R itself is a class.
it had multiple Inner classes defined within eg drawable,id,layout,etc.
and that inner classes had lots of variables declared as below which were assigned with hex values
public static final int addr=0x7f080003;
...
...
and much more
R is auto generated and acts as some pointer for other files
Questions for R.java
what it is basically for
how it works
why
values are in hex
what role did it performs while the actual application is running
"Acts as some pointer to other files" is actually absolutely correct, now the question is which files it points to how it is done.
What does it contain?
R file contains IDs for all the resources in the res folder of your project and also some additional IDs that you define on your own (in the layouts, for example). The IDs are needed for the Android resource management system to retrieve the files from the APK. Each ID is basically a number which corresponds to some resource in the resource management system.
The file itself is needed so you can access or reference the resource from code by giving the ID of the resource to the resource manager. Say, if you want to set the view in the activity, you call
setContentView(R.layout.main);
main in the R file contains the number which is understood by the Android resource management system as the layout file which is called main.
Why is it better than just plain file names?
It's harder to make a mistake with the generated fields. If you write the field name incorrectly, your program won't compile and you will know that there's an error immediately. If you write an incorrect string, however, the application won't fail until it is launched.
If you want to read more on this topic, you should check the Android documentation, especially the Accessing Resources part.
This holds your resource ids. So when you do something like
TextView tv = (TextView) findViewById(R.id.mytextview);
it looks up your id here for that View, layout, etc... This way the app has an easy way to look up your ids while you can use easy to remember names. Anytime you create a resource it automatically creates an id for it and stores it here. That's why you never want to try and edit this file yourself.
One way to think about how valuable R.java is, imagine a world without it. Its amazing how android brings the xml and java world together to help avoid coding the UI manually completely. With legacy java building UI using the java language was a pain. Invaluable.
With Android you can not only build your UI using only xml, but also see it while you build it. Invaluable.
Every element in the xml can be referenced in the java code WITHOUT writing a single line of code to parse the xml :). Just R.id.nameOfElement. Invaluable.
Rapid development is beautifully done in android. Imagine if iPhone would have 5000 screens to fit that one piece of code, they would crumble on their XCode. Google has done a wonderful job with just R.java. Invaluable.
I had read the .dex format document on Google, but I still got some confuses with some layer.
link_size & link_off : Google said it left unspecified and then said it's hook for runtime, so what it is? The static hook for global or local? or the hook to native library?
map_off : Why it need this redundancy IDs list? is it some kinda like the file address table?
proto_size & proto_off : Not quite sure what it actually is. I had de-assembled an randomly picked dex and look on this section, this section contained some short sign like DD/LL/JLJJ/...brabrabra, that made me more confused about this section. What exactly this section doing for?
Can anyone enlighten me?
The link section has never been specified or used. You might run across some dex files that have a garbage value for these fields, as an attempt to prevent baksmali from being able to be run on them (due to an old bug, that has been fixed for a while).
For the map item, Yes, there is redundancy for the locations of the indexed item sections - the location for these are specified in both the header item and the map item. But the map item is the only place the locations of the offset item sections are specified (the variable size items in the data section)
The prototype section defines the prototype for a method, i.e. the parameters and return type. If you look in the method_id_item, you'll see that it has a reference to a prototype item.
I've been working on the 'Tip Calculator' app for Android and I have a couple of questions.
I'm supposed to (in the process of creating the GUI) use some EditTexts to allow the user to enter the bill amount and read the calculated total bill. In the version I have, there is no EditText anywhere in the Visual Layout Editor, only CheckText. Are these the same?
Whenever I try to edit the Java code for the app, as per the book I have, I keep getting the message:
Thus and such is never used
For example, with
private static final String BILL_TOTAL = "BILL_TOTAL';
or anything from the import Android list, other than the one referring to a bundle. I'm Not sure how to resolve this. I have some experience with C and C++, but Java is new to me.
The warning that tells you that a variable or method or import is not used can be ignored, especially if you just haven't gotten to using it yet. It's a warning and not an error, so your app should compile regardless.
I don't know what you're using to build your layout (eclipse? I use Intellij Idea), but to add an EditText, you can edit the layout file by hand. Add a line similar to:
<EditText android:id="#+id/myEditText android:width="FILL_PARENT" android:height="WRAP_CONTENT"/>
As a general rule, I like to edit these things by hand. Then, when something breaks or doesn't work as I expect it to, I have some grasp of what's in there, and so I can usually fix it. The value gained by learning how to create a layout by hand easily offsets the value of the time that you'll save.
Good luck.
As you probably know, Mozilla aims to do the mobile UI on fennec as native Java/Android UI.
That includes using the layout XML files, which by default use stuff like
<TextView
android:layout_width="fill_parent"
android:layout_height="wrap_content"
android:gravity="center_horizontal"
android:text="#string/text_a"
/>
with #string/text_a being resolved to text_a in a strings.xml file, doing l10n.
We'd like to use something else, and I wonder if/how we can hook that up in the XML files.
So, I'd love to get pointers to android source code that actually does the string lookup, for one.
And I have three ideas on how to hook up something custom, which are not fact-checked, basically because I haven't managed to find the code that does stuff yet:
#moz-l10n/text_a, with a java-implemented service giving back values for that resource type
moz:l10n="text_a" custom attribute that would get hooked up to post process the generated widgets
subclass the widgets we want to localize with our scheme, adding (2)
I hope that there are folks out here that have a good idea to point me to good paths or shoot some down.
PS: I'd appreciate a lack of bike-shed about whether android l10n scheme is good or not.
So, I'd love to get pointers to android source code that actually does the string lookup, for one.
android.content.res.Resources delegates to android.content.res.AssetManager and the getResourceText() method. That in turn dives into a native loadResourceValue() method. And you're on your own from there... :-)
1) #moz-l10n/text_a, with a java-implemented service giving back values for that resource type
Unless you are going to pre-process your faux resource files with your own build tools, generating valid Android resource files into the res/ directory, you cannot invent new resource types (e.g., #moz-10n). That would require modifications to the build tools and the firmware.
2) moz:l10n="text_a" custom attribute that would get hooked up to post process the generated widgets
3) subclass the widgets we want to localize with our scheme, adding 2)
Your option #3 is definitely possible and is fairly typical when creating custom widgets. It's conceivable that the techniques for it (usually involving a res/values/attrs.xml file with a declare-styleable resource) could somehow be applied to a standard widget class, but I've never seen that done. Of course, you could always do the pre-processing as in how you'd accomplish option #1.