I am developing an application where certain elements will repeat themselves a lot over the whole interface. Googling a bit i found out about the <include /> tag, which is working nicely for what i want.
I was just wondering if there is a way to export certain properties of the included layout: One of them has an image and a string that change according to the use case, and i'd like to set these in the XML file for each case, instead of having to write boilerplate code to set them in the code; Is there any way to do this? Or am i doomed to write that code?
We're all doomed. As explained in the article Creating Reusable Components, the only things that you can override are the layout_* attributes and the id. There's no way (sadly) to parameterize a layout like you describe.
The <include> tag is is useful for separating configuration-dependent parts of your layout from those parts that are invariant across devices. (E.g., you can <include layout="#layout/footer"> and have different footer.xml files for different configurations.)
Related
I know that we can have different layout files for supporting different screen sizes in Android.
Does anyone know if there is an option to change all other layout files when I make changes to the original layout file? For example, say I have a layout file - main.xml under layout, layout-large, layout-sw600dp and layout-sw720dp directories. If I make some changes to the main.xml in the layout directory, is there any setting which would automatically make that change in the other layout directories as well?
For the formatting capabilities I use an answer for this. This refers to the comment above and elaborates on Aleksey's answer.
<include
android:id="#+id/some_id_if_you_nee_one"
layout="#layout/some_other_xml_file"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
/>
You may add any additional (orientation or resolution specific) formatting like below the layout= statment.
Everything that is not specific to the current resolution/orientation and common for all resolutions/oriantations should go into some_other_xml_file.xml
This works for all full views and subclasses of view. If you want something similar only for groups of style attributes then you can start a styles.xml and refer to the styles with style="..." statements.
The answer is no. And i'm not sure there is such tool. Exceptions: naming of params (strings, drawables, etc.).
Some hint: compose layouts from small parts, that inserted using
<include />.
So when you change small parts – all layout changes (not sure with different sw-*** layouts, but in one folder it works).
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"
To support different resolutions, we need to make variations of layout files as described in Supporting Multiple Screens very well. Assuming you don't plan to show different arrangement of your UI but just want to stretch appropriately, your variations would be mostly about different weights. At least that is the case with my app so far.
Now, how do you manage changing the application with this structure? Since it repeats the layout many times, one layout change in your application causes multiple files change.
I thought of two options:
Changing the values dynamically in your code
Downside is your layout related work is spilled over to the code. I really don't like this.
Making child layout to extract common layout elements
Downside is your layout's hierarchy will be deeper and cluttered so it would be harder to figure out what's going on. Still, this is better than option #1 thanks to Hierarchy Viewer. I am not sure if this approach will be always achievable.
If you could share your tricks to get through this, it would be much appreciated.
I think I found a solution. I will accept it as an answer if others give thumbs up.
I found Configuration qualifiers described in Supporting Multiple Screens works not only for res/drawable and res/layout but also for res/values. So on my layout/some_layout.xml, I say like this:
<ImageButton
android:id="#+id/imagePlay"
android:layout_width="#dimen/button_size"
android:layout_height="#dimen/button_size"
android:scaleType="fitCenter"
android:src="#drawable/play" />
Then on values/layout.xml file you define the default button_size:
<resources>
<dimen name="button_size">44dp</dimen>
</resources>
And on values-xlarge/layout.xml file you define the xlarge mode button_size:
<resources>
<dimen name="button_size">66dp</dimen>
</resources>
I didn't try other values resources, but I assume it also works for Styles and Themes so in case your layout customization is a little bit more than a size or weight, you could define a style in the values and use it.
This is probably a trivia question, but why are there package/class names in some people's XML layout files?
(please don't downvote this question if it is something trivial, i don't even know what this is called, so i couldn't look it up).
i was looking at a tutorial, and i saw something like this (in "sample.xml"):
<com.tutorials.foo
android:layout_width="match_parent"
android:layout_height="match_parent" >
<!-- some buttons and views here -->
</com.tutorials.foo>
My questions are:
1) i'm assuming that "foo" is a custom view? say, like you want to extend TextView with your own version of TextView?
2) what is this pattern/technique even called?
3) what would be the advantages of using this method?
Thanks so much in advance!!!
Yes, <com.tutorials.foo .../> is a custom view.
Calling it will be as same as others.ex:
Foo foo=(Foo)findViewById(R.id.foo);
I assume you mean creating layout static(.xml) or dynamically with code. xml layout would be in advantage when you know that you will use this layout in the program and will not change its format. Of course you can add to it or edit it with code later on. It is also in advantage for readabilty.
Let's say i have a layout with style:
<LinearLAyout ... >
<TextView ... style=someStyle />
<ImageView ... style=someImageStyle ... />
</LinearLayout>
the style will be defined in an xml in my project.
How can i override that style with an external xml ? (i'm asking because i've noticed the View does not have applyStyle\setStyle or anything of that sort (best bet, because style need to be parsed, compared against android:attr for validation and then applied on each item of the view).
I do wonder how am i suppose to make downlaodable themes for my app.
After some experience i can share my thoughts about it here in my own question...
So first remark is, even in your own styles, use Dimentions and colors and attributes as much as you can. this way if you ever want to programatically apply a style to a view you can use getResources.getDimen... , getRessources().getColor(), getResrouces.getDrawable() etc...
In addition you can take the code from the aapt or open an existing apk and take the compiled xml from there and then use the same code reading the xml (it's C code mind you!!!) from android source. i would not do it from the simple reason it's an overkill to apply a simple style to a view.
The time it takes to write the method is too short. and if you must do it in xml, you can create an xml file with just your view and then inflate it, you can't replace the style in run time though. for that you have to define your own mechanism to replace colors, sizes, backgrounds etc... and supply the images as well, which is not so easy, reading those images from the local storage, if i'm not mistaken is less productive then readin them from assets or drawable directories.