Is it possible to open a SlidingDrawer when viewed inside the Eclipse graphical layout preview? By default it's closed when viewed so I cannot see what is happening with the layouts inside the SlidingDrawer.
If this isn't possible, what would be the best way to handle this problem? A separate layout file I guess?
I am not sure if there is a standard way to do this.
I currently use the following method: override SlidingDrawer.onFinishInflate() to force it open when in Eclipse layout preview.
import android.widget.SlidingDrawer;
public class MySlidingDrawer extends SlidingDrawer {
public MySlidingDrawer(Context context, AttributeSet attrs, int defStyle) {
super(context, attrs, defStyle);
}
public MySlidingDrawer(Context context, AttributeSet attrs) {
super(context, attrs);
}
#Override
protected void onFinishInflate() {
super.onFinishInflate();
if (isInEditMode()) {
open();
}
}
}
Then, of course, replace SlidingDrawer by my.package.MySlidingDrawer in layout.xml.
Related
My layout has a lot of elements and I want to divide them using "divider":
<View
android:id="#+id/divider"
android:layout_width="match_parent"
android:layout_height="2dp"
android:background="#android:color/black"/>
But I don't want to add the same divider 10 times in layout. Can I do something to help me to add divider only one time? With button I have the same question. I have 3 button in different places in my layout, but this button doing the same. How can i bind one action for three button and add only one time in layout?
If you have a lot of Items that use the same layout, ie. they look a lot like each other, ListView with an ArrayAdapter is very, very useful.
You can done this type of job by creating custom button. Custom button extends the Button class. Something like this e.g:
public class MyButton extends Button {
public MyButton(Context context, AttributeSet attrs, int defStyle) {
super(context, attrs, defStyle);
init(attrs);
}
public MyButton(Context context, AttributeSet attrs) {
super(context, attrs);
LayoutInflater inflater = (LayoutInflater) context.getSystemService(Context.LAYOUT_INFLATER_SERVICE);
inflater.inflate(R.layout.your_custom_button_layout, this, true);
}
public MyButton(Context context) {
super(context);
}
}
I created a custom slider that was working fine, but suddenly it started showing visual issues and i have no idea where to look to solve this problem.
the issue is the appearance of black borders/gradients around it. i tested on android 6 and android 4.0.3 as well. both are showing the same problem. on android 4.0.3, i can also see this problem around the actions in the toolbar when i press on them, it makes like a black gradient shadow.
any idea?
the code of my slider is:
public class StyledSeekBar extends SeekBar {
public StyledSeekBar(Context context) {
super(context);
this.init();
}
public StyledSeekBar(Context context, AttributeSet attrs) {
super(context, attrs);
this.init();
}
public StyledSeekBar(Context context, AttributeSet attrs, int defStyleAttr) {
super(context, attrs, defStyleAttr);
this.init();
}
#TargetApi(Build.VERSION_CODES.LOLLIPOP)
public StyledSeekBar(Context context, AttributeSet attrs, int defStyleAttr, int defStyleRes) {
super(context, attrs, defStyleAttr, defStyleRes);
this.init();
}
/**
* Initializes the instance of this class.
*/
private void init(){
setThumb(getResources().getDrawable(R.drawable.apptheme_scrubber_control_selector_holo_light));
setIndeterminateDrawable(getResources().getDrawable(R.drawable.apptheme_scrubber_progress_horizontal_holo_light));
setProgressDrawable(getResources().getDrawable(R.drawable.apptheme_scrubber_progress_horizontal_holo_light));
}
}
it's no shadow. Looks like .png stretched. Try 9png
I found the solution! To fix this kind of issue, it is necessary to verify the 9-patch images and resolve all the bad patches. This can be done by using the draw9patch tool.
I'm having trouble understanding why my extended layout isn't working. I made a class which goes
public class MyLayout extends RelativeLayout {
public MyLayout(Context context) {
super(context);
}
}
I wrote the XML as
<package.MyLayout
. . .
</package.MyLayout>
The method where I get the error is in the activity where I have called setContentView(R.layout.layout_relative).
I don't understand what I'm doing wrong because surely you inflate in the activity from the XML layout which is building on the custom class where I can make my overrides?
you need the other constructor, the one that takes two parameters:
public MyLayout(Context context, AttributeSet attrs) {
super(context, attrs);
}
which is used when the layout is inflated from the layout
You have specified the wrong constructors!
Android xml inflation uses
public RelativeLayout (Context context, AttributeSet attrs, int
defStyleAttr)
public RelativeLayout (Context context, AttributeSet
attrs, int defStyleAttr, int defStyleRes) since api 21
I have developed a very huge application and now i have a requirement of having custom font for all controls in the application. so I want to know the better way to change the font in one shot. The application has more than a hundred XML layout. and i cant change all controls to a custom component with custom font. Please provide a solution to Change the font without altering all the controls in XML.
Do something like this
pacage com.prac;
class MyFontedTextView extends TextView {
public FontedTextView(Context context) {
super(context);
init();
}
public FontedTextView(Context context, AttributeSet attrs) {
super(context, attrs);
init();
}
public FontedTextView(Context context, AttributeSet attrs, int defStyle) {
super(context, attrs, defStyle);
init();
}
private void init() {
String otfName = "MyCustomOtfFileWhichIPutInAssetsFolder.otf";
Typeface font = Typeface.createFromAsset(context.getAssets(), otfName);
this.setTypeface(font);
}
}
Now replace this all over in xml file from your TextViews
<com.prac.MyFontedTextView .... instead of <TextView
This change you have to do all over for it to apply
also for the case of button text . Button is also subclass of TextView
So the same can work for button's too
Hope this help or can lead you to the solution you are looking
When creating a custom view, I have noticed that many people seem to do it like this:
public MyView(Context context) {
super(context);
// this constructor used when programmatically creating view
doAdditionalConstructorWork();
}
public MyView(Context context, AttributeSet attrs) {
super(context, attrs);
// this constructor used when creating view through XML
doAdditionalConstructorWork();
}
private void doAdditionalConstructorWork() {
// init variables etc.
}
My problem with this is that it stops me from making my variables final. Any reason not to do the following?
public MyView(Context context) {
this(context, null);
// this constructor used when programmatically creating view
}
public MyView(Context context, AttributeSet attrs) {
this(context, attrs, 0);
// this constructor used when creating view through XML
}
public MyView(Context context, AttributeSet attrs, int defStyle) {
super(context, attrs, defStyle);
// this constructor used where?
// init variables
}
I've been able to create the view just fine through XML and through code, but I'm not sure if there are any drawbacks to this approach. Will this work in all cases?
There is another part to this question
The only drawback I can see (that no one seems to have mentioned) is that your second constructor loses the defStyle of the superclass, because you set it to zero. Look at the source code for any of Android's View classes, and you'll notice that the second constructor always has a specific defStyle defined.
For example, this is the second constructor of ListView:
public ListView(Context context, AttributeSet attrs) {
this(context, attrs, com.android.internal.R.attr.listViewStyle);
}
If you were to extend ListView using the second approach that you describe, com.android.internal.R.attr.listViewStyle would no longer be the defStyle, because you'd be bypassing that second super constructor and making it zero instead. I suppose you could resolve this by using the same defstyle as ListView, like so:
public MyView(Context context, AttributeSet attrs) {
this(context, attrs, android.R.attr.listViewStyle);
}
But it's not exactly the "purist" way, because you're artificially forcing it to have the same defStyle as ListView.
So, contrary to what the others said, I actually think you're better off using the first doAdditionalConstructorWork() approach outlined in your post, because that at least makes sure that the defStyle is set correctly.
Copied this from my answer for a similar question.
If you override all three constructors, please DO NOT CASCADE this(...) CALLS. You should instead be doing this:
public MyView(Context context) {
super(context);
init(context, null, 0);
}
public MyView(Context context, AttributeSet attrs) {
super(context,attrs);
init(context, attrs, 0);
}
public MyView(Context context, AttributeSet attrs, int defStyle) {
super(context, attrs, defStyle);
init(context, attrs, defStyle);
}
private void init(Context context, AttributeSet attrs, int defStyle) {
// do additional work
}
The reason is that the parent class might include default attributes in its own constructors that you might be accidentally overriding. For example, this is the constructor for TextView:
public TextView(Context context) {
this(context, null);
}
public TextView(Context context, #Nullable AttributeSet attrs) {
this(context, attrs, com.android.internal.R.attr.textViewStyle);
}
public TextView(Context context, #Nullable AttributeSet attrs, int defStyleAttr) {
this(context, attrs, defStyleAttr, 0);
}
If you did not call super(context), you would not have properly set R.attr.textViewStyle as the style attr.
Yup, that's a reasonable pattern to use so you don't have to repeat the custom work in every one of your constructors. And no, there don't appear to be any drawbacks to the method.
It purely depends on your requirement. Let us say if you want to use any methods in parent class without overriding their functionality in your custom view, then you need to use super() and instantiate parent class. If you dont need to invoke any methods in parent class all implementations are overridden in your custom view, then you don't need. Read A custom View Example section in this link.
Edit:
This is not Okay. See other answers to this question for reasons.
Original Answer:
It is Ok.
When we look at the source of TextView.java.
They have used the same hierarchy.
So you are Okay with this approach.