I have a simple xml which I want to inflate as a java view object.
I know how to inflate a view:
view = LayoutInflater.from(context).inflate(R.layout.alarm_handling, this);
But then I have a view which is a child of the parent (this). And then the messy problem starts with setting layoutparameters and having an extra layout which I do not need. These are much easier to do in xml.
With an Activity one can just call: setContentView() but with a View that is not possible.
In the end I would like to have a Java class (extends ViewSomething) which I can refer to in an other xml. I have looked at ViewStub, which almost is the answer, except that it is final :(
public class AlarmView extends ViewStub{ //could work if ViewStub wasn't final
public AlarmView (Context context, AttributeSet attrs) {
super(context);
//using methods from ViewStub:
setLayoutResource(R.layout.alarm_handling);
inflate();
}
}
So how to to this? What to extend to be able to just call setContentView() or setLayoutResource()?
I looked at many SO answers but none of them fit my question.
as far as I understood the trick that you want to apply it's a bit different than what you trying to.
No ViewStub are not the solution as ViewStub have a very different way of handling everything.
Let's say for the sake of the example your XML layout is something like this (incomplete, just to show the idea):
<FrameLayout match_parent, match_parent>
<ImageView src="Myimage", wrap_content, Gravity.LEFT/>
<TextView text="hello world", wrap_content, Gravity.CENTER_HORIZONTAL/>
</FrameLayout>
then you don't want to extend FrameLayout and inflate this XML inside it, because then you'll have two FrameLayouts (one inside the other) and that's just a stupid waste of memory and processing time. I agree, it is.
But then the trick is to use the merge on your XML.
<merge match_parent, match_parent>
<ImageView src="Myimage", wrap_content, Gravity.LEFT/>
<TextView text="hello world", wrap_content, Gravity.CENTER_HORIZONTAL/>
</merge>
and inflate as normal on your widget that extends FrameLayout
public class MyWidget extends FrameLayout
// and then on your initialisation / construction
LayoutInflater.from(context).inflate(R.layout.alarm_handling, this);
and your final layout on screen will only have 1 FrameLayout.
happy coding!
Related
I'm new to Android and have recently started adopting the pattern to create an auto-layout-loading custom view based on a layout file. In the layout you use the 'merge' tag as the root, then in the constructor of your view, you inflate that layout into yourself so you are essentially the root of the merged-in controls. Right after you inflate, still in the constructor, you can find the child controls from the layout and assign them to private fields in the custom class so they will always be available, even when using recycler views.
Contrast that with including a layout. In that case, the layout has to define a root element (which can be your custom control, but in that case, you would not inflate the layout into yourself and would have to move the control lookup to onFinishInflate) but otherwise it ends up with the same view hierarchy.
In short, instead of this...
<include layout="#layout/layout_myCustomControl" />
You can now do this...
<com.mydomain.MyCustomControl />
However I find the auto-loading custom control version to be much more flexible and maintainable. The advantages of the second one are not only that you can use custom attributes in the referencing XML layouts (which you can't with the 'include' version) but it also gives you a central place to manage the code as well as layout management/control lookup.
So now I can do this...
<com.mydomain.MyCustomControl
app:myCustomAttribute="Foo" />
And if the control has to have code backing up its behavior, it's nicely encapsulated in the custom view.
Here's an example layout for the auto-loading version...
<?xml version="1.0" encoding="utf-8"?>
<merge xmlns:android="http://schemas.android.com/apk/res/android">
<TextView
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="This is static text in the header" />
<TextView android:id="#+id/dateTextView"
android:layout_width="wrap_content"
android:layout_height="wrap_content" />
</merge>
And here's the class that uses it...
public class MainHeader extends LinearLayout
{
TextView dateTextView;
public MainHeader(Context context, #Nullable AttributeSet attrs)
{
super(context, attrs);
setOrientation(VERTICAL);
LayoutInflater.from(context).inflate(R.layout.header_main, this);
dateTextView = (TextView)findViewById(R.id.dateTextView);
dateTextView.setText(<<Code for setting date goes here>>);
}
}
But what I'm wondering is if the layout is purely static in nature--say holding a static image and fixed text--is it still considered good practice to use a custom view to represent it? I'd say yes for consistency, plus should I want to extend it in the future, you're already prepared for it and have to do so in just one place regardless of how many places it's used. In contrast, if you included the layout directly in say 20 places, you may have to update all 20 (depending on what's actually changed/needed.)
Pros for the Custom View approach:
Central location for managing layout loading and control lookup
Can support backing code implicitly/internally for updating the view.
Can use attributes when being referenced in other layout files
Better encapsulation (you can hide the layout itself from the outside world exposing behaviors via direct methods)
Can simply be 'new'd' up in code and the layout will automatically load. No inflating or casting needed.
Cons for Custom View approach
When used in Layout files, you now have to also specify width and height making usage a little more verbose.
May add extra classes to your project (not always, but sometimes.)
Again, it seems to me like a no-brainer, but I'm wondering if there's a preferred 'Androidy' way, or is it just a preference up to each developer?
Such approach will add additional level in your view trees. So you only made the UI tree more complex for no good reason. From other side, you can follow next steps to get rid of that side-effect:
<merge /> can only be used as the root tag of an XML layout
when inflating a layout starting with a <merge />, you must specify a parent
ViewGroup and you must set attachToRoot to true (see the
documentation of the inflate() method)
That's it.
Well apparently what I came up with wasn't that unique after all! Here's an article explaining in detail this exact scenario, along with the pros and cons of each. Looks like they too came to the same conclusion.
TrickyAndroid: Protip. Inflating layout for your custom view
I want to extend a View to create a custom View, and automatically force some layout parameters, this way:
public class myView extends View {
public myView(Context context) {
this.setLayoutParameters(LayoutParameters(LayoutParameters.MATCH_PARENT, LayoutParameters.MATCH_PARENT));
}
}
My problem is, how can I set the LayoutParameters if I don't know if the view will be set inside a LinearLayout, a RelativeLayout or somewhere else?
How can I detect which Layout type is the view in?
The layout parameters you're talking about all come from android.view.ViewGroup.LayoutParams which is common to all the ViewGroup classes (LinearLayout, RelativeLayout, etc.)
So you shouldn't need to distinguish between the parent view types; just use the LayoutParams directly.
I just found an easy solution by myself. The question anyway remains valid as soon as there may be a easier and more complete way to do the same thing.
if (this.getParent() instanceof LinearLayout)
this.setLayoutParams(new LinearLayout.LayoutParams(LinearLayout.LayoutParams.MATCH_PARENT, LinearLayout.LayoutParams.MATCH_PARENT));
Im kind of new to Android.
I am playing around with the Android FingerPaint API Sample. I have figured out how to add buttons and functions to the Menu, but how do I get buttons on the actual screen?
Is it possible to place buttons over the drawing surface? Or would I need a linear (Vertical) layout on the left, and place buttons in there. Either would be fine.
Help? Thanks.
The Android FingerPaint sample code does not use a layout; it instead just has a subclass of View called MyView, and then the Activity sets its content view to be an instance of MyView.
If you want to have more than one View on the screen, you'll need to use some sort of layout. You could use a LinearLayout if you want the MyView for painting to be above, below, or to the side of the buttons; if you want the buttons to be on top of the MyView, take a look at using a FrameLayout or RelativeLayout.
You can either then define the layout in XML or create it manually in code. The former is more flexible and maintainable, but there will be a few hiccups.
First, create a layout XML showing how you want your components to be laid out. For this example, we'll call it finger_paint.xml. Make sure you have a MyView in there somewhere, something like:
<view class="com.example.android.apis.graphics.FingerPaint$MyView"
android:layout_width="fill_parent"
android:layout_height="fill_parent">
Then, replace the line that looks like
setContentView(new MyView(this));
with
setContentView(R.layout.finger_paint);
Note that because MyView does not (yet) have the proper constructor for being instantiated by the LayoutInflater, this will not work yet, so let's fix that. Add an additional import near the top of the file:
import android.util.AttributeSet;
and then add an AttributeSet parameter to the constructor of MyView:
public MyView(Context c, AttributeSet as) {
super(c, as);
// rest of constructor is same as in the sample
}
You will also have to change MyView to be a static inner class of FingerPaint.
You may find the Building Custom Components document and the NotePad sample useful as you figure this out.
Good luck!
Are you trying to dynamically position your buttons?
If so, you can use setLayoutParams to set the layout properties of the button.
I have a small project where I want to reuse a certain UI component a few time so I created a widget by expanding a ViewGroup. In that ViewGroup I inflated a view that contained a TextView inside a LinearLayout and added that inflated view to the ViewGroup trough addView.
The outer LinearLayout expands itself perfectly but the inner TextView have getHeight() = 0 and getWith() = 0 when I view it through Hierarchy Viewer. The strange thing is that layout_height and layout_width is the values I gave them in my xml.
I don't have the code here but it looked something like this:
xml:
<LinearLayout
android:layout_width="fill_parent"
android:layout_height="fill_parent">
<TextView
android:text="random text.."
android:layout_with="200px"
android:layout_height="50px" />
</LinearLayout>
Java:
class MyWidget extends ViewGroup {
...
//In constructor
myView = View.inflate(context, R.layout.xml, null);
addView(myView);
//In layout
myView.layout(l, t, r, b);
I have tried to give my text view fill_parent values for size but it didn't help.
Remember:getHeight() and getWidth()return 0 if components are not drawn yet.
To find the width And height of a View before it being drawn:
First call measure
view.measure(MeasureSpec.UNSPECIFIED,MeasureSpec.UNSPECIFIED)
Now you can get width using getMeasuredWidth and height using getMeasuredHeight
int width = view.getMeasuredWidth();
int height = view.getMeasuredHeight();
I have posted some more ideas here: How to get width/height of a View
1) Here is some links to use Hierarchy Viewer on your dev phone.
http://developer.android.com/guide/developing/debugging/debugging-ui.html
and the class you'll need:
http://github.com/romainguy/ViewServer
2) You can also reuse layout like a component with the include tag:
<include android:id="#+id/your_id" layout="#layout/layout_name" />
So, I put a bounty on this one, and here is what I've found.
Inflating with a null reference is A Bad Idea(TM). Essentially, that View won't get the proper layout parameters it needs (its parent sets a whole bunch of them, with a whole bunch of magic/logic involved). So inflating into null means no parents, and no inherited layout parameters. One can manually set a number of these parameters, but due to the magic involved it might not solve your problem.
The "solution(s)" that I've come up with involve; using include (when you know how many you need) and pulling them into code, or inflating to a parent (when you need true dynamic, N things). And of course, the XML you inflate will have ID collisions, so I go about it by grabbing the last child (e.g. getChildAt(getChildCount()-1) ) of whatever I'm looking for, etc.
Did you try passing yourself as the root:
View.inflate(context, R.layout.xml, this);
Since you will be the parent of this View that complies with the javadoc spec.
I'm trying to make some Android view classes (which are just wrappers around layouts defined in an XML file). Is this correct:
public class MyViewWrapper extends LinearLayout {
private TextView mTextView;
public MyViewWrapper(Context context) {
super(context);
}
public constructUI() {
LayoutInflater inflater = (LayoutInflater)getContext().getSystemService(Context.LAYOUT_INFLATER_SERVICE);
inflater.inflate(R.layout.myview, this);
mTextView = (TextView)findViewById(R.id.myview_textview);
}
}
so the idea is just that I can construct my views like that, and they have logic inside for modifying their child views etc. The layout looks like:
<LinearLayout>
<TextView />
</LinearLayout>
It just looks like I'm going to get an extra unnecessary LinearLayout. The wrapper class is itself a LinearLayout, and then it will attach the inner LinearLayout from the xml file.
Is that ok?
Thanks
You can try replacing the <LinearLayout> in your layout file with <merge>. I have not tried that recently, and I think I ran into problems when I last tried it, but in theory it should serve the purpose. <merge> basically means "take all my children and put them directly into whatever container I'm being inflated into".