I have a bunch of Views in a <merge>, and I included that <merge> into a RelativeLayout. I try to refer to the IDs of those included Views to act as anchors for my other Views, but Eclipse complains that the IDs are not resolving. I found a workaround by using #+id rather than #id when I first refer to them rather than when I actually define the objects they refer to. I've already defined the two IDs in a Style and in the included <merge> where they are declared, so it feels a bit inefficient if I keep repeating the definition of the ID.
Is this the correct way of doing it? I'm assuming it's bad cause the '+' is another initialization. My current hypothesis is that you should use #+id when you first use the ID rather than when you initialize the object that the ID is going to represent, a bit like C/C++ and how they require at least a function prototype in the lines prior to the actual code that uses the function.
Another question I have is when you use the GUI-based UI builder of Eclipse, I noticed that they always use #+id rather than #id. Is this acceptable, cause it seems inefficient to me; it's as if the application will be spending more time determining whether or not the ID has been declared in R.id.
Using #+id format tells the Android asset compiler to assign an ID to your element, it isn't actually an id itself. So if I use #+id/myNewId the asset compiler will create a new id named myNewId and provide a number for it. The actual number can be accessed from your code as R.id.myNewId.
If you use an #id, the compiler will look for R.id.id. You can define your own id's in XML files, as explained here: http://developer.android.com/guide/topics/resources/more-resources.html#Id. You could create your own file in res/values/[your_filename].xml:
<?xml version="1.0" encoding="utf-8"?>
<resources>
<item
type="id"
name="id_name" />
</resources>
and then refer to #id_name, for e.g.
You can also use the Id's defined in the Android namespace: #android:id/empty
This is well explained in the Android documentation: http://developer.android.com/guide/topics/ui/declaring-layout.html#id
There's also some further discussion here: android:id what is the plus sign for
Related
I've read (and confirmed with testing) that resource value names (Strings, Drawables, dimensions, etc.) should have a prefix at the beginning (generally the library's name) to avoid name conflicts, because a project that uses the library and declares a resource with a matching name will overwrite the library's resource.
What I'm unclear on is whether the names of attr attributes inside a <declare-styleable> should also be prefixed. Since they are wrapped within the <declare-styleable>, are they protected from over-writing? Within Java code, their resource names are automatically prefixed with the name of the <declare-styleable>, but when used within XML files, they are not.
I'm guessing that their usage is context sensitive. That in my custom Preference's code, when I call context.obtainStyledAttributes() with a specific styleable, it is only at that point that the XML attributes are interpretted as specific types. If I declare a Preference styleable attribute named "min" of type float and use it in my project, it will not matter that there is an attribute named "min" in the v7.preference library's SeekBarPreference styleable of type int, because SeekBar doesn't use my styleable when calling obtainStyledAttributes().
So if my assumption is correct, there's no reason the compiler would be consolidating attributes by name like that. But custom attribute styling is a complex beast in Android, and I'm not sure if I'm missing something in my testing. It would be nice to omit the prefixes in my library's attribute names for ease of use/documentation.
If the <declare-styleable> is defining attributes for a Style, then I think it's still safe from conflicts, because Styles don't merge. They only reference each other from their own attributes. If I understand them correctly--they are somewhat convoluted to me.
On a related note, is there any reason view IDs should be prefixed? I'm thinking yes, because my library view exists within a project's view structure and a user of the library calls findViewById() on an ID that matches one of mine, I could envision scenarios where the search turns up my view first and trips them up. But Google's own appcompat libraries take no such precaution, so I'm unsure.
After studying documentation and AOSP source code, I've come to the conclusion that yes, you should prefix attribute names.
Resource attributes are not <declare-styleable> local. They are all global. When you declare a resource attribute (which can be done inside or outside of a <declare-styleable>), you name it and give it a format type:
<attr name="my_attribute" format="string" /> <!-- This is a declaration -->
When you reference a resource attribute (which is only done from within a <declare-styleable>), you list its name but not its format.
<attr name="my_attribute" /> <!-- This is a reference -->
Lint shows an error if you try to declare two attributes with the same name.
The fact that you can declare an attribute from within a <declare-styleable> is merely a convenience for code conciseness. It does not imply a limited scope. If you are planning to use the same attribute in multiple styleables, it's probably good practice to put its declaration outside of any <declare-styleable>, so it can be found easily.
One oddity I've noticed is that Lint doesn't show an error if two different libraries have overlapping attribute declarations. I suppose it doesn't cause an issue if they both have the same format type. I haven't checked to see what happens if they don't.
As for why Google doesn't prefix attribute names in AppCompat, I figure they want it to be very easy to use, and almost interchangeable with AOSP xml code, so they want the attribute names to match similar attribute names in AOSP. And so they deemed the simplicity of use outweighs the risk. What I suspect they overlook is how disjointed and lacking their documentation is on setting up and using styleables and attributes, so it's not obvious what to watch out for when setting up our own custom views and preferences.
Problem
I want to override a layout file from android namespace, e.g. R.layout.popup_menu_item_layout (which is referenced from code as com.android.internal.R.layout.popup_menu_item_layout). By saying override, I assume declaring an xml file in the project which would be prioritized over the layout that framework owns.
Note, this is just an example layout, so the question concerns to each layout that's present in sdk/platforms/android-XX/data/res/layout directory.
What I've tried
tools:override
There's an undocumented tools:override tag available, which overrides specific resources. See this answer for an example, which overrides values from Design Support Library, not from Android framework.
Applying tools:override="true" to the root tag of the layout won't take effect.
XML layout references - refs.xml
As described in this post, declaring a refs.xml file in /values/ directory with following content:
<?xml version="1.0" encoding="utf-8"?>
<resources>
<item type="layout" name="activity_main">#layout/activity_second</item>
</resources>
will refer to activity_second.xml once activity_main.xml is used. There's an answer that suggests using this technique in order to substitute Snackbar's layout.
This also won't take effect.
Question
Is there any legitimate way to override/substitute a layout file from android package?
I know this is an old question but I also wanted to override a library layout with my own, here's how I did it.
The layout in question was called design_bottom_navigation_item
In refs.xml I added the following:
<resources xmlns:tools="http://schemas.android.com/tools">
<item name="design_bottom_navigation_item" type="layout" tools:override="true">#layout/bottom_navigation_item</item>
</resources>
There are 4 parts to this which I'll explain.
Name: This is the name of the layout you want to override
Type: The type of resource you are trying to override, in this case a layout.
tools:override: This is how you tell Android Studio to override the library layout with your own.
Value: This is where you specify what resource you want to use instead.
You can do this with any resource type this way.
What is that you're trying to do?
If the idea to only replace how the menu-item will look like, you can try the following:
Create a custom MyMenuAdapter extends MenuAdapter
Override the getView method to return the view from your adapter.
You are trying to customise your sdk on the application itself, at runtime.
That's just not how it works.
If you use an SDK on your project(on any technologies), and you need to modify some behavior, you will tweak this SDK and after that, compile your project with this news customized version.
Trying to modify it at runtime is not a good idea.
You will face multiple issues (retro compatibility, security trigger, TREBLE incompatibility , dependency issue, etc)
You have 4 possibilities to do what you want:
Make your own android rom where you will apply your modification
Copy the resources you need to modify on a fake xmlObject with the tag, after the onPostCreate of your application, you will be able to modify the when inflation. You can generalize this behavior and it will simulate an sdk overlay.
Make your own sdk :)
Multi-level reflection, but, no way you succeed with a stable version
Of course, none of this solutions is applicable for a public app.
don't know your issue have fixed or not but simple solution for this is create new layout that is same layout name of framework (in this case is popup_menu_item_layout). Then go to android google source to copy xml content popup_menu_item_layout
So you can custom anything u want. But remember don't change any id of views.
I've been writing some Android apps but I don't really understand when to use app: and when to use android:. When styles are not being applied the way they're supposed to, I use trial and error and sometimes find that using app: instead of android: solves the issue but I don't understand why. It'd be great if someone could point me in the right direction. Thanks!
You can use the app namespace to have app compatibility with older API versions.
For example
app:srcCompat="#drawable/customborder" has the same effects with
android:background="#drawable/customborder"
The difference is that the first will work correctly with older API's and the second will not display what you would like.
You are talking about custom namespace.In android we can create custom views in additional to already available views.
As per in Google developer docs..
To add a built-in View to your user interface, you specify it in an XML element and control its appearance and behavior with element attributes. Well-written custom views can also be added and styled via XML. To enable this behavior in your custom view, you must:
Define custom attributes for your view in a resource element
Specify values for the attributes in your XML layout
Retrieve attribute values at runtime
Apply the retrieved attribute values to your view
Once you define the custom attributes, you can use them in layout XML files just like built-in attributes. The only difference is that your custom attributes belong to a different namespace. Instead of belonging to the http://schemas.android.com/apk/res/android namespace, they belong to http://schemas.android.com/apk/res/[your package name]
So for if you use default views you can use android namespace and if you want to set and use attributes for custom view you can define your own name.
Refer this
If you take a look at the beginning of the your layout xml files (in which you used app:) you will (probably) find lines like this:
<?xml version="1.0" encoding="utf-8"?>
<SOME_LAYOUT xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
in this case app: namespace will be used for custom attributes, specified by you inside attrs.xml file or by someone else in one of used libraries.
Sometime the property with android only available in new Android version like
In this case, you should use app:... to make it work with older version.
moreover you will find two variants
xmlns:app="http://schemas.android.com/apk/res-auto"
xmlns:app="http://schemas.android.com/apk/[packagename]"
the difference between xmlns lines is res-auto take care of resolving our package as sometime we will add .debug or .test in our package and we already provided the packageid of the app Ex:
xmlns:app="http://schemas.android.com/apk/com.test.io.debug"
xmlns:app="http://schemas.android.com/apk/com.test.io.test"
I've seen that all the layout ids are identified by #+id/viewid, but it seems the #+my_group_name/viewid works as well. Is it normal to use this naming convention, or the id must be in the "id" class ? I've checked the forum and found prefix based naming conventions but nothing like this.
In examples: I have a dialog layout called dlgeffect. In this layout:
<CheckedTextView
android:id="#+dlgeffect/text"
android:layout_width="0dip" ... >
I now the id's are reused, but during layout modifications if the ids are unique for the whole project the compiler gives error this way (and not runtime error)
Thanks,
Gzp
EDIT: and of course from java it is referenced as R.dlgeffect.text
I really dont know if you can do this, but always stick to standards, if you want it for reuse porpuse or setting property for more than element at once you can use same id for different element
I don't want to specify hard coded test size values in my layout.xml, hence i am using the following specification :
android:layout_height="#integer/intervalViewHt"
and
#integer/intervalViewHt value is as follows:
<integer name="medium">15</integer>
Now, the while inflating android is creating a problem saying that it cannot inflate the view. I want to actually specify value in dp so the actual value should be like
android:layout_height="15dp"
Can anyone help me here ?
What you're looking for are "dimensions" rather than plain integers.
Declaration:
<dimen name="intervalViewHt">15dp</dimen>
Usage:
android:layout_height="#dimen/intervalViewHt"
Have a look at the given link for more examples in the Android docs.
I use something like this for text size across different devices. It's java based, not xml.
tvOutput.setTextSize(TypedValue.COMPLEX_UNIT_DP, getResource().getInteger(R.integer.medium));
I haven't tested the code so you might have to play with it. I'm sure you could do something like.
button1.setHeight(TypedValue.COMPLEX_UNIT_DP, getResource().getInteger(R.integer.medium));
Though again I haven't tried it and you may need something different then TypedValue
What if you give it a String rather than an int. i.e in strings resource you have a string "15dp" that you reference