Background
I have a layout that has some special states (like being checked/pressed), and I wish to set its children to apply their own drawables based on this layout.
i'm searching for an alternative of setting duplicateParentState to true for each of its children (and maybe even all of its descendants).
What I've tried
I've tried to make the custom view have an attribute of setting it to each of its children, but i couldn't find in which method call to apply this attribute to all of its children. in each method i've tried, it either returns 0 for getChildCount() or it just doesn't do anything to the child itself ( using setDuplicateParentStateEnabled() ) .
The problem
as the documentation says , using setDuplicateParentStateEnabled won't do anything on the cases i need it from :
Note: in the current implementation, setting this property to true
after the view was added to a ViewGroup might have no effect at all.
This property should always be used from XML or set to true before
adding this view to a ViewGroup.
so it seems i use it too late, but i need to call it late since the children don't exist yet in the parent...
The question
How can I achieve this functionality of avoiding setting duplicateParentState for each child, and just set it to the parent view?
How about extending the widget -like you said- and overriding onLayout()? This way you ensure to modify the children state also the first time the widget is drawn. When onLayout() is called, getChildCount() will always return the actual number of children. For example:
public class LinearLayout extends android.widget.LinearLayout {
private static final int[] VIEW_GROUP_ATTRS = new int[]{ android.R.attr.enabled };
private static final boolean DEFAULT_IS_ENABLED = true;
private boolean isEnabled = DEFAULT_IS_ENABLED;
public LinearLayout(Context context) {
super(context);
}
public LinearLayout(Context context, AttributeSet attrs) {
super(context, attrs);
isEnabled = context.obtainStyledAttributes(attrs, VIEW_GROUP_ATTRS).getBoolean(0, DEFAULT_IS_ENABLED);
}
#Override
public void setEnabled(boolean enabled) {
super.setEnabled(enabled);
this.isEnabled = enabled;
for (int i = 0; i < getChildCount(); ++i) {
getChildAt(i).setEnabled(enabled);
}
}
#Override
protected void onLayout(boolean changed, int left, int top, int right, int bottom) {
super.onLayout(changed, left, top, right, bottom);
setEnabled(isEnabled);
}
}
Note that you are actually extending the widget (calling super on any method being overridden).
Related
When using the translucent status and navigation bars from the new Android 4.4 KitKat APIs, setting fitsSystemWindows="true" and clipToPadding="false" to a ListView works initially. fitsSystemWindows="true" keeps the list under the action bar and above the navigation bar, clipToPadding="false" allows the list to scroll under the transparent navigation bar and makes the last item in the list scroll up just far enough to pass the navigation bar.
However, when you replace the content with another Fragment through a FragmentTransaction the effect of fitsSystemWindows goes away and the fragment goes under the action bar and navigation bar.
I have a codebase of demo source code here along with a downloadable APK as an example: https://github.com/afollestad/kitkat-transparency-demo. To see what I'm talking about, open the demo app from a device running KitKat, tap an item in the list (which will open another activity), and tap an item in the new activity that opens. The fragment that replaces the content goes under the action bar and clipToPadding doesn't work correctly (the navigation bar covers the last item in the list when you scroll all the way down).
Any ideas? Any clarification needed? I posted the before and after screenshots of my personal app being developed for my employer.
I struggled with the same problem yesterday. After thinking a lot, I found an elegant solution to this problem.
First, I saw the method requestFitSystemWindows() on ViewParent and I tried to call it in the fragment's onActivityCreated() (after the Fragment is attached to the view hierarchy) but sadly it had no effect. I would like to see a concrete example of how to use that method.
Then I found a neat workaround: I created a custom FitsSystemWindowsFrameLayout that I use as a fragment container in my layouts, as a drop-in replacement for a classic FrameLayout. What it does is memorizing the window insets when fitSystemWindows() is called by the system, then it propagates the call again to its child layout (the fragment layout) as soon as the fragment is added/attached.
Here's the full code:
public class FitsSystemWindowsFrameLayout extends FrameLayout {
private Rect windowInsets = new Rect();
private Rect tempInsets = new Rect();
public FitsSystemWindowsFrameLayout(Context context) {
super(context);
}
public FitsSystemWindowsFrameLayout(Context context, AttributeSet attrs) {
super(context, attrs);
}
public FitsSystemWindowsFrameLayout(Context context, AttributeSet attrs, int defStyle) {
super(context, attrs, defStyle);
}
#Override
protected boolean fitSystemWindows(Rect insets) {
windowInsets.set(insets);
super.fitSystemWindows(insets);
return false;
}
#Override
public void addView(View child, int index, ViewGroup.LayoutParams params) {
super.addView(child, index, params);
tempInsets.set(windowInsets);
super.fitSystemWindows(tempInsets);
}
}
I think this is much simpler and more robust than hacks that try to determine the UI elements sizes by accessing hidden system properties which may vary over time and then manually apply padding to the elements.
I solved the issue by using the library I use the set the color of my translucent status bar.
The SystemBarConfig class of SystemBarTint (as seen here https://github.com/jgilfelt/SystemBarTint#systembarconfig) lets you get insets which I set as the padding to the list in every fragment, along with the use of clipToPadding="false" on the list.
I have details of what I've done on this post: http://mindofaandroiddev.wordpress.com/2013/12/28/making-the-status-bar-and-navigation-bar-transparent-with-a-listview-on-android-4-4-kitkat/
Okay, so this is incredibly weird. I just recently ran into this same issue except mine involves soft keyboard. It initially works but if I add fragment transaction, the android:fitsSystemWindows="true" no longer works. I tried all the solution here, none of them worked for me.
Here is my problem:
Instead of re-sizing my view, it pushes up my view and that is the problem.
However, I was lucky and accidentally stumbled into an answer that worked for me!
So here it is:
First of all, my app theme is: Theme.AppCompat.Light.NoActionBar (if that is relevant, maybe it is, android is weird).
Maurycy pointed something very interesting here, so I wanted to test what he said was true or not. What he said was true in my case as well...UNLESS you add this attribute to your activity in the android manifest of your app:
Once you add:
android:windowSoftInputMode="adjustResize"
to your activity, android:fitsSystemWindows="true" is no longer ignored after the fragment transaction!
However, I prefer you calling android:fitsSystemWindows="true" NOT on the root layout of your Fragment. One of the biggest places where this problem will occur is where if you have EditText or a ListView. If you are stuck in this predicament like I did, set android:fitsSystemWindows="true" in the child of the root layout like this:
YES, this solution works on all Lollipop and pre-lollipop devices.
And here is the proof:
It re-sizes instead of pushing the layout upwards.
So hopefully, I have helped someone who is on the same boat as me.
Thank you all very much!
A heads up for some people running into this problem.
A key piece of information with fitSystemWindows method which does a lot of the work:
This function's traversal down the hierarchy is depth-first. The same
content insets object is propagated down the hierarchy, so any changes
made to it will be seen by all following views (including potentially
ones above in the hierarchy since this is a depth-first traversal).
The first view that returns true will abort the entire traversal.
So if you have any other fragments with content views which have fitsSystemWindows set to true the flag will potentially be ignored. I would consider making your fragment container contain the fitsSystemWindows flag if possible. Otherwise manually add padding.
I've been struggling quite a bit with this as well.
I've seen all the responses here. Unfortunately none of them was fixing my problem 100% of the time.
The SystemBarConfig is not working always since it fails to detect the bar on some devices.
I gave a look at the source code and found where the insets are stored inside the window.
Rect insets = new Rect();
Window window = getActivity().getWindow();
try {
Class clazz = Class.forName("com.android.internal.policy.impl.PhoneWindow");
Field field = clazz.getDeclaredField("mDecor");
field.setAccessible(true);
Object decorView = field.get(window);
Field insetsField = decorView.getClass().getDeclaredField("mFrameOffsets");
insetsField.setAccessible(true);
insets = (Rect) insetsField.get(decorView);
} catch (ClassNotFoundException e) {
e.printStackTrace();
} catch (NoSuchFieldException e) {
e.printStackTrace();
} catch (IllegalAccessException e) {
e.printStackTrace();
}
This is how to get them.
Apparently in Android L there'll be a nice method to get those insets but in the meantime this might be a good solution.
I encountered the same problem. When I replace Fragment.
The 'fitsSystemWindows' doesn't work.
I fixed by code add to your fragment
#Override
public void onViewCreated(final View view, Bundle savedInstanceState) {
super.onViewCreated(view, savedInstanceState);
AndroidUtil.runOnUIThread(new Runnable() {
#Override
public void run() {
((ViewGroup) getView().getParent()).setFitsSystemWindows(true);
}
});
}
Combined with #BladeCoder answer i've created FittedFrameLayout class which does two things:
it doesn't add padding for itself
it scan through all views inside its container and add padding for them, but stops on the lowest layer (if fitssystemwindows flag is found it won't scan child deeper, but still on same depth or below).
public class FittedFrameLayout extends FrameLayout {
private Rect insets = new Rect();
public FittedFrameLayout(Context context) {
super(context);
}
public FittedFrameLayout(Context context, AttributeSet attrs) {
super(context, attrs);
}
public FittedFrameLayout(Context context, AttributeSet attrs, int defStyleAttr) {
super(context, attrs, defStyleAttr);
}
#TargetApi(Build.VERSION_CODES.LOLLIPOP)
public FittedFrameLayout(Context context, AttributeSet attrs, int defStyleAttr, int defStyleRes) {
super(context, attrs, defStyleAttr, defStyleRes);
}
protected void setChildPadding(View view, Rect insets){
if(!(view instanceof ViewGroup))
return;
ViewGroup parent = (ViewGroup) view;
if (parent instanceof FittedFrameLayout)
((FittedFrameLayout)parent).fitSystemWindows(insets);
else{
if( ViewCompat.getFitsSystemWindows(parent))
parent.setPadding(insets.left,insets.top,insets.right,insets.bottom);
else{
for (int i = 0, z = parent.getChildCount(); i < z; i++)
setChildPadding(parent.getChildAt(i), insets);
}
}
}
#Override
protected boolean fitSystemWindows(Rect insets) {
this.insets = insets;
for (int i = 0, z = getChildCount(); i < z; i++)
setChildPadding(getChildAt(i), insets);
return true;
}
#Override
public void addView(View child, int index, ViewGroup.LayoutParams params) {
super.addView(child, index, params);
setChildPadding(child, insets);
}
}
I have resolve this question in 4.4
if(test){
Log.d(TAG, "fit true ");
relativeLayout.setFitsSystemWindows(true);
relativeLayout.requestFitSystemWindows();
getWindow().clearFlags(WindowManager.LayoutParams.FLAG_TRANSLUCENT_STATUS);
}else {
Log.d(TAG, "fit false");
relativeLayout.setFitsSystemWindows(false);
relativeLayout.requestFitSystemWindows();
getWindow().addFlags(WindowManager.LayoutParams.FLAG_TRANSLUCENT_STATUS);
}
I have a simple Custom TextView that sets custom font in its constructor like the code below
public class MyTextView extends TextView {
#Inject CustomTypeface customTypeface;
public MyTextView(Context context, AttributeSet attrs) {
super(context, attrs);
RoboGuice.injectMembers(context, this);
setTypeface(customTypeface.getTypeface(context, attrs));
setPaintFlags(getPaintFlags() | Paint.SUBPIXEL_TEXT_FLAG);
}
}
It works fine from Gingerbread through JB 4.2. But the adb logcat is flooded with the following messages when I show my custom textview on Android 4.3 phone.
10-05 16:09:15.225: WARN/View(9864): requestLayout() improperly called by com.cmp.views.MyTextView{42441b00 V.ED.... ......ID 18,218-456,270 #7f060085 app:id/summary} during layout: running second layout pass
10-05 16:09:15.225: WARN/View(9864): requestLayout() improperly called by com.cmp.views.MyTextView{423753d0 V.ED.... ......ID 26,176-742,278 #7f060085 app:id/summary} during layout: running second layout pass
I notice, it does slow down UI a bit. Any ideas why it's happening on 4.3?
Appreciate your help.
I found where this bug occurs in my app. Although occurrence of this is not found in the code you provided (it may help if you have done this elsewhere in your code), it will hopefully help others fix this impossible-to-trace problem.
I had a line (not added by me, of course):
myView.addOnLayoutChangeListener(new View.OnLayoutChangeListener() {
#Override
public void onLayoutChange(View v, int left, int top, int right, int bottom, int oldLeft, int oldTop, int oldRight, int oldBottom) {
//this would then make a call to update another view's layout.
}
});
In my app, I did not need any listener, so removing this entire block fixed this problem. For those that need something like this, remember to remove the listener after the layout has changed (inside of this callback).
Looking into the Android source, this problem is described in a little more detail:
requestLayout() was called during layout. If no layout-request flags are set on the requesting views, there is no problem. If some requests are still pending, then we need to clear those flags and do a full request/measure/layout pass to handle this situation.
It appears that the problem may be related to Roboguice; see issue #88. The suggested solution there is to use #InjectView:
You can now use #InjectView from inside a view class. Just call Injector.injectMembers() after you've populated your view, ala:
public class InjectedView extends FrameLayout {
#InjectView(R.id.view1) View v;
public InjectedView(Context context) {
super(context);
final View child = new View(context);
child.setId(R.id.view1);
addView(child);
RoboGuice.getInjector(context).injectMembers(this);
}
}
Perhaps you should consider migrating RoboGuice.injectMembers(context, this) to the declaration of your View object using the #InjectView annotation.
I fixed these warnings in my custom ListView item (LinearLayout subclass). This class implements Checkable, and has a setChecked(boolean checked) method that is called to indicate whether the item is checked:
#Override
public void setChecked(boolean checked) {
mChecked = checked;
TextView textView = (TextView)this.findViewById(R.id.drawer_list_item_title_text_view);
if(mChecked) {
textView.setTypeface(Typeface.createFromAsset(getContext().getAssets(), "font/Andada-Bold.ttf"));
}
else {
textView.setTypeface(Typeface.createFromAsset(getContext().getAssets(), "font/Andada-Regular.ttf"));
}
}
I visually indicate the checked state by calling setTypeFace() on a textView in my view, toggling between regular and bold typefaces. These setTypeFace() calls were causing the warnings.
To fix the problem, I created instance variables for the Typefaces in the class constructor and used them later, when changing the typeface, rather than calling Typeface.createFromAsset(...) every time:
private Typeface mBoldTypeface;
private Typeface mRegularTypeface;
public DrawerView(Context context, AttributeSet attrs) {
super(context, attrs);
initTypefaces();
}
private void initTypefaces() {
this.mBoldTypeface = Typeface.createFromAsset(getContext().getAssets(), "font/Andada-Bold.ttf");
this.mRegularTypeface = Typeface.createFromAsset(getContext().getAssets(), "font/Andada-Regular.ttf");
}
#Override
public void setChecked(boolean checked) {
mChecked = checked;
TextView textView = (TextView)this.findViewById(R.id.drawer_list_item_title_text_view);
if(mChecked) {
textView.setTypeface(mBoldTypeface);
}
else {
textView.setTypeface(mRegularTypeface);
}
}
This is a pretty specific scenario, but I was pleasantly surprised to find a fix and maybe someone else is in the same situation.
Please check weather the Id of any view is repeating inside the same activity context. I was also getting the same warning, I was using a TextView repeatedly a loop with same id. I resolved the problem by using different ids each time.
I met the same problem. That's because I was trying to set a view's position in the iOS way. You know in iOS set a view's position by set the view's left top value and width, height. But in Android, it should be (left, top, right, bottom). I did pay much attention on this. When I jump into the layout() definition, I read the method's comment, then I find out why the warning happened.
I am trying to create a custom ViewGroup, and I want to use it with a full screen application. I am using the "requestWindowFeature(Window.FEATURE_NO_TITLE)" to hide the title bar. The title bar is not showing, but it still consuming space on top of the window.
The image above was generated with the following code:
public class CustomLayoutTestActivity extends Activity {
#Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
requestWindowFeature(Window.FEATURE_NO_TITLE);
Button b = new Button(this);
b.setText("Hello");
CustomLayout layout = new CustomLayout(this);
layout.addView(b);
setContentView(layout);
}
}
public class CustomLayout extends ViewGroup {
public CustomLayout(Context context) {
super(context);
}
public CustomLayout(Context context, AttributeSet attrs) {
super(context, attrs);
}
public CustomLayout(Context context, AttributeSet attrs, int defStyle) {
super(context, attrs, defStyle);
}
#Override
protected void onLayout(boolean changed, int l, int t, int r, int b) {
Log.i("CustomLayout", "changed="+changed+" l="+l+" t="+t+" r="+r+" b="+b);
final int childCount = getChildCount();
for (int i = 0; i < childCount; ++i) {
final View v = getChildAt(i);
v.layout(l, t, r, b);
}
}
}
(The full Eclipse project is here)
It is interesting to see that it is the Android that is given this space for my custom layout. I am setting the CustomLayout as the root layout of my Activity. In the Log in the "onLayout" is receiving "t=25", and that is what is pushing my layout down. What I don't know is what I am doing wrong that makes Android the "t=25" (which is exactly the height of the title bar).
I am running this code in the Android SDK 2.1, but I also happens in Android 2.2.
EDIT: If I change the CustomLayout class for some default layout (such as LinearLayout), the space disappears. Of course, the default layouts of Android SDK don't create the layout I am trying to create, so that is why I am creating one.
Although the layout I am creating is somewhat complex, this is the smallest code I could create reproducing the problem I have with my layout.
It's not a full answer, but in the meantime you can work around the problem by wrapping your custom layout in a <FrameLayout />
Also, it's worth noting that your layout extends beyond the bottom of the screen. It's shifted down by the title bar height (38 pixels in my emulator)
Edit: Got it. onLayout() (and the corresponding layout() method) specify that the coordinate are not relative to the screen origin, they're relative to the parent ( http://developer.android.com/reference/android/view/View.html#layout%28int,%20int,%20int,%20int%29 ). So the system is telling you that you're at relative coordinates (0, 38), and you're adding it when passing that down to your child, which means that you're saying that your child is at screen coordinates (0, 76), causing the gap.
What you actually want to do is:
v.layout(0, 0, r - l, b - t);
That will put your child Views aligned with the top left corner of your View, with the same width and height as your view.
I had the same issue with a FrameLayout in 2.2
I fixed it by adding android:layout_gravity="top" to the FrameLayout
I've put a WebView loading an image inside a ViewPager. When I try to scroll the image horizontally I move over to the next view instead of scrolling the image.
Is it possible to make it scroll to the end of the image before moving over to the next view?
#Override
public Object instantiateItem(View view, int i) {
WebView webview = new WebView(view.getContext());
webview.setHorizontalScrollBarEnabled(true);
webview.loadUrl("http://www.site.with.an/image.gif");
((ViewPager) view).addView(webview, 0);
return webview;
}
The following is a real working solution which will scroll the WebView on a horizontal swipe as long as it can scroll. If the WebView cannot further scroll, the next horizontal swipe will be consumed by the ViewPager to switch the page.
Extending the WebView
With API-Level 14 (ICS) the View method canScrollHorizontally() has been introduced, which we need to solve the problem. If you develop only for ICS or above you can directly use this method and skip to the next section. Otherwise we need to implement this method on our own, to make the solution work also on pre-ICS.
To do so simply derive your own class from WebView:
public class ExtendedWebView extends WebView {
public ExtendedWebView(Context context) {
super(context);
}
public ExtendedWebView(Context context, AttributeSet attrs) {
super(context, attrs);
}
public boolean canScrollHor(int direction) {
final int offset = computeHorizontalScrollOffset();
final int range = computeHorizontalScrollRange() - computeHorizontalScrollExtent();
if (range == 0) return false;
if (direction < 0) {
return offset > 0;
} else {
return offset < range - 1;
}
}
}
Important: Remember to reference your ExtendedWebView inside your layout file instead of the standard WebView.
Extending the ViewPager
Now you need to extend the ViewPager to handle horizontal swipes correctly. This needs to be done in any case -- no matter whether you are using ICS or not:
public class WebViewPager extends ViewPager {
public WebViewPager(Context context, AttributeSet attrs) {
super(context, attrs);
}
#Override
protected boolean canScroll(View v, boolean checkV, int dx, int x, int y) {
if (v instanceof ExtendedWebView) {
return ((ExtendedWebView) v).canScrollHor(-dx);
} else {
return super.canScroll(v, checkV, dx, x, y);
}
}
}
Important: Remember to reference your WebViewPager inside your layout file instead of the standard ViewPager.
That's it!
Update 2012/07/08: I've recently noticed that the stuff shown above seems to be no longer required when using the "current" implementation of the ViewPager. The "current" implementation seems to check the sub views correctly before capturing the scroll event on it's own (see canScroll method of ViewPager here). Don't know exactly, when the implementation has been changed to handle this correctly -- I still need the code above on Android Gingerbread (2.3.x) and before.
Although Sven mentioned for layout file I want to add detail. After you extend Webview and ViewPager classes,
Inside your activity you will cast to your extended class like this:
web = (MyWebView) findViewById(R.id.webview);
Inside your layout file like this:
<your.package.name.MyWebView
android:id="#+id/webview"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
/>
I'm not sure if this is possible, and I couldn't find a topic based on it, but if it's been answered before drop me a link and that will be that.
What I'm looking to do right now is resize some of the default Android widgets, specifically DatePicker and TimePicker, to use in an Activity. But as far as I can see the only result of modifying the width or height of either Picker (in a negative direction) results in a cropped view, rather than a scaled/stretched view of the widget.
I am open to my own custom widgets of my own, but I would really prefer to keep this project as simple and clean as possible, matching the Android OS UI as much as possible, so using the native DatePicker and TimePicker seems like a logical choice to me. If anyone knows how to scale these widgets down rather than cropping them, I'd really appreciate it.
Thanks.
It is a very bad hack, but it should work:
Create a new view extending LinearLayout, overwrite method getChildStaticTransformation and setStaticTransformationsEnabled explicit to true.
In the method getChildStaticTransformation you can manipulate the tranformation parameter to scale down all the content of your extended LinearLayout.
And then add the DatePicker or something else as a child of this view.
EG:
public class ZoomView
extends LinearLayout
{
private float sf = 1f;
public ZoomView(final Context context, final AttributeSet attrs)
{
super(context, attrs);
setStaticTransformationsEnabled(true);
}
public ZoomView(final Context context)
{
super(context);
setStaticTransformationsEnabled(true);
}
public void setScaling(final float sf)
{
this.sf = sf;
}
#Override
protected boolean getChildStaticTransformation(final View child, final Transformation t)
{
t.clear();
t.setTransformationType(Transformation.TYPE_MATRIX);
final Matrix m = t.getMatrix();
m.setScale(this.sf, this.sf);
return true;
}
}