I'm obviously pretty new to Android. Does better documentation exist for the set of android.R.* classes somewhere? The API reference is pretty bare bones, many times only containing the resource literal IDs and not explaining how/where they are used. Similarly, it would be nice if additional information (or pictorial examples) existed for the various platform defined layouts and styles.
Or am approaching this the wrong way? Perhaps there's a better method to determine their usage than going straight to the documentation. I'm finding this portion (I'm not even sure what to call it) to be the most confusing aspect of Android programming by far and am open to any suggestions that will better my understanding.
Thanks!
Source code would be the best documentation. At least, it's very helpful when you need to understand how the function does what is briefly described in documentation.
I think you are confused about what R is.. The R file is autogenerated during the compilation process based on the resources you have in your res folders.
So, if you add a strings file: res/values/strings.xml with contents:
<resources>
<string name="string_name">text_string</string>
</resources>
R will now contain an entry for R.string.string_name.
For a details on all of the different types of resources, see resource types.
Edit:
As to "platform defined layouts", have you looked at the developer docs on it? See common layout objects. Also each layout type has a tutorial on it, search for "Hello --layout type--"
Related
I would like to know why we use XML for the creating user interface layouts in Android. I know that it decouples the business logic from the design but what is the significance of the XML other than that?
Also I would like to know the significance of the auto-generated R.java file in this. All I know that it is generated according to the changes in the resources and that it helps us to access the widgets and resources through their IDs.
It would be great if someone could give a clear idea on these two aspects.
Unlike what everyone said about the XML being easy and efficient. Here is what I read in Hello Android by Ed Brunnette (p. 49) which made sense.
Android is optimized for mobile devices with limited memory and
horsepower, so you may find it strange that it uses XML so
pervasively. After all, XML is a verbose, human-readable format not
known for its brevity or efficiency, right?
Although you see XML when writing your program, the Eclipse plug-in
invokes the Android resource compiler, aapt, to preprocess the XML
into a compressed binary format.**It is this format, not the original
XML text, that is stored on the device.
This was the kind of answer that i was looking for.(sorry if my question meant otherwise).
The reason that XML was chosen is mainly because of its familiarity and the number of IDE tools that natively support it. The developers could have chosen JSON for example and still compiled that to binary.The auto-generated R.java file is a helper for the IDE so that you can get the benefit of autocomplete when you want to access a resource.
XML is easy to parse and manipulate programmatically, it's basically a tree structure and most UI creation tools already use it. It really has nothing to do with decoupling business logic because you can define Java code in Android using a Model-View-Controller pattern just as well.
The auto-generated R.java file is a helper for the IDE so that you can get the benefit of autocomplete when you want to access a resource. It also stops you from making stupid mistakes since the compiler will complain if you try to access a resource you haven't defined. If you were using a simple properties file you wouldn't know until runtime that the 'key' you are using is missing.
Same as why is silverlight with xml the answer is simple xml give power by integration and scalability. R.java is for indexing having things organized is never bad.
Sorry my english
One possible reason is that you need not have any working java underneath in order to be able to see the visual layout of the interface you are working on. The xml ui element/page is essentially a document that you can parse and display. If this were a source file you would have to either carefully parse it or compile and run it (all of which are more complex than parsing xml)
Xml as itself is well readable both by human and machine. Also, it is scalable and simple to develop. Also, you have already mentioned the decoupling.
As for R.java - it is just the way of accessing widgets. The solution is rather good, as it is using ints instead of string to use less memory and in the same time provides well readable names for the simplicity of development.
Android Layouts are tree like structures with some enforced rules. XMLs are perfect fit for this purpose.
JSON also have tree like structure but they are data-oriented while XML is document-oriented.** :
Meaning XML is based on the idea that documents have structural and
other semantic elements that can be described without reference to
how such elements should be displayed.
The actual display of such a document may vary, depending on the
output medium and style preferences.
While JSON was designed to
represent JavaScript and their prime purpose is data exchange . They are well suited in data-oriented areas
because of light weight and simplicity & closer in syntactic form to programming data structures.
I'm wondering what some good ways of organizing Android projects are. I'm building a little recipe application and have already made dozens of layouts, drawable resources, menus, etc., not to mention Java source code.
Android does not allow sub-folders for resources, so is there a way to organize them? Right now I'm trying to organize them through naming conventions (e.g. new_list_ingredient_edit) but I'm wondering if there is a better way, as the names will probably get pretty long and cumbersome.
Same thing with resources such as string values. As I understand it, I can create multiple resource files (e.g. strings_new_ingredient.xml, drawables_new_instructions.xml, etc.) but all my resources across files have still have to have unique names, which again is cumbersome.
Although android doesn't allow sub-folders for resources, it does for assets, but this is much more cumbersome to use.
A possible option would be to use a sql database with all of your strings, but this approach is probably too much work and more cumbersome anyway.
Your naming convention method is probably your best option. You could think of some of the seperated words as directories if you want, which should keep it organized enough.
user864684,
I normally try to use heirarchy in my naming. If it is a layout for dialog, i will start with dialog_sharing or something like that.
As for graphics, I will start with btn or bg or txt or ic_menu depending on what they are for. Other than that, you just get used to it as you dev more for Android.
Make sure you also have a support folder on your drive for your local resources. I mimic the android layout so i keep my graphics sorted in res/... on my local drive too. I keep the psd and graphic files there and then just copy the pngs to eclipse.
Hope this kinda of helps. There is no real standard but you will pick up a style.
Specifically with respect to organizing drawable resources, I would advise choosing names that describe the drawables structurally, not functionally.
For example, if you have a gray circle shape resource that you are using as a placeholder for an image, I would avoid naming it *image_placeholder*. Instead, I would call it *gray_circle_1*.
My advice comes from having had the experience on multiple occasions of having given things names like *image_placeholder*, forgetting what they actually contained, and then rewriting the same exact thing in a separate resource file without realizing it.
Don't do what I did.
I have a newbie android question:
Why arent strings and other resources like colors (defined in res/values directory) defined in android namespace by assigning the attribute
xmlns:android="http://schemas......" to the tag?
I don't know if there is a "why" about it, but I imagine the best answer is that these XML files are so simple that a schema adds little value. On the one hand it would help editors find errors automatically; on the other hand it's a little more work for developers and the Android maintainers.
What does the translatable attribute, like translatable="false", mean?
This attribute points out that this attribute will be the same for all locales. Why is it useful?
The localization files are more readable for human and saves time.
It tells the Lint tool that everything is fine and that Android does not need to look for this resource translation.
Full explanation:
http://tools.android.com/recent/non-translatablestrings
So, generally, this means if don't put this attribute, you should always localize this resource, otherwise tell people and compiler that this is unique for all locales by specifying this attribute.
If you are supporting multiple languages, and there are some strings which should not be translated (that means same across all languages) then you can use translatable="false"
For ex: Numbers<string name="account_setup_imap" translatable="false">IMAP</string>
Detailed Description
I've never heard of that attribute, but apparently (now) there's a reason for using it: see this post from ADT-Dev google group.
BTW, I just tried it and it works in fixing those Android Lint errors.
I don't see any reference to that in official docs, however, it probably is just an indicator for humans looking at the file that that particular string entity should not be translated.
If you have an Android app that you wish to internationalize, a common tactic is to just send your strings.xml file to translators. So that attribute would just be a flag for them.
I have done some significant re-coding on one of my Android programs and now I am unsure if certain xml strings are used anymore. In addition I have a few translations which makes the task even more difficult. Is there a tool to test this? This would be useful for drawables also.
I am using the eclipse plugin.
This question has been discussed in the irc channel before. There is no tool to test it, but I agree it would be useful. Note that resources can be referenced in xml, but they can also be referenced from code. Furthermore, resources can also be looked up by their identifier, and such lookup could be determined by runtime.
So actually you cannot determine 100% whether a resource is used or not anymore, but you can probably determine which resources are referenced in a static way (in xml or code). Depending on your code/app which you know best yourself, such approach might be sufficient in many cases.
The approach would be to write a tool that parses xml and java source files and also take the import statements into consideration. With that information you should be able to determine which resources you can get rid of.
The easiest way is to remove them all, attempt to compile, and re-add those the compiler says are lacking. It's a little tiresome, but it's certainly tractable.
Note, as Mathias already pointed out, that it's technically possible to access resources by name with a string at runtime, and the way I suggest here would remove such resources though they are, in fact, needed. However, this pattern should be really rarely seen in any application, and if you are the one who wrote it, you already know if/where you do such treatment.
Use grep to extract a list of resources to a file by way of sort
Use recursive grep through sort and uniq to create a list of those mentioned in any source file (make a copy of project without unused files or dispatch grep on a list of used ones, of course commented out code will be an issue)
Use diff on the two lists