Develop Reference

What is the ButtonBarLayout and how should we use it?

When I developed, I found a new widget called android.support.v7.widget.ButtonBarLayout unexpectedly. I tried to search it on the internet, but nothing was found, even on the official development documents site.
In the meantime, I found two ButtonBarLayout when I search ButtonBarLayout everywhere in Android Studio, one is android.support.v7.widget.ButtonBarLayout and the other is com.android.internal.widget.ButtonBarLayout. I tried to read source codes of both, I found that they are the same except package name. So I thought maybe android.support.v7.widget.ButtonBarLayout came from com.android.internal.widget.ButtonBarLayout after the internal ButtonBarLayout was through tests and released. At the same time, ButtonBarLayout is inherited from LinearLayout.
But there are some question:
What can we get from ButtonBarLayout literally and how should we use it?
I noticed the variable of private boolean mAllowStacking. When it changes, orientation of this layout would be changed. But I didn't really understand what it is used for.
So does somebody know ButtonBarLayout well?
P.S.: I used Android Studio of 2.0.0 Preview 4 and Gradle Plugin of 2.0.0-alpha3 and Android Support Library of 23.1.1 and Platform-tools of 23.1 and Build-tools of 23.0.2.

As others pointed out, the class description tells exactly what it is: an extension of LinearLayout that automatically switches to vertical orientation when it can't fit its child views horizontally.
I might add that this was clearly done to fit with the material design specifications about dialogs. They make a distinction between side by side buttons and stacked buttons. See for example:
Side-by-side buttons are recommended when the text of each label does
not exceed the maximum button width, such as the commonly used
OK/Cancel buttons.
While you should go for stacked buttons when the single button is too large, or there's not enough room for both:
When text labels exceed the maximum button width, use stacked buttons
to accommodate the text. Affirmative actions are stacked above
dismissive actions.
So, one possible use of this class, is when designing your own dialogs. For example, AlertDialog and AlertDialog.Builder offer internal support for dialogs with buttons, but sometimes you just want to subclass DialogFragment or AppCompatDialogFragment for a better control.
There, it might be useful to setup a bottom button bar that follows the design guidelines, and have full control on the buttons (like enabling and disabling, things you can't do with an AlertDialog AFAIK).

The source code describes ButtonBarLayout as follows:
/**
* An extension of LinearLayout that automatically switches to vertical
* orientation when it can't fit its child views horizontally.
*/
So, in essence, it is nothing but a smart LinearLayout which manages auto-switching orientations based on available space on screen.
The same ButtonBarLayout.java file describes mAllowStacking in comments as follows:
/** Whether the current configuration allows stacking. */
Source Code Here

You are right first of all. ButtonBar layout does not seem to be featured anywhere in the official Android documentation. I tried myself to search about it, but to no avail. However I have found some information which defines what is a ButtonBar layout and when to use it. Hopefully this will help you.
Most tutorials use the Buttonbar layout in a dialogbox or at the bottom of a screen to confirm or decline an option. The image below is a visual representation of how the ButtonBar layout has been used in a screen.
The screenshot above has the following layout xml:
<LinearLayout
style="?android:attr/buttonBarStyle"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:orientation="horizontal" >
<Button
android:id="#+id/Button01"
style="?android:attr/buttonBarButtonStyle"
android:layout_width="0dp"
android:layout_height="wrap_content"
android:layout_weight="1"
android:text="Show" />
<Button
android:id="#+id/Button02"
style="?android:attr/buttonBarButtonStyle"
android:layout_width="0dp"
android:layout_height="wrap_content"
android:layout_weight="1"
android:text="Change" />
</LinearLayout>
<EditText
android:id="#+id/myView"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:ems="10" >
<requestFocus />
</EditText>
So essentially what Android is doing here is simply creating two buttons next to each other in a LinearLayout with each button having the match_parent parameter set to the width. Hence each button takes half the size of the screen. Android have actually taken away the hassle of creating seperate buttons and positioning them correctly to fit different screens, by creating a simple widget handling this altogether.
As with the support library, Android have implemented this for developers using an earlier API. It is normal for them to use the support library for this purpose.
Hope this helps :)

https://android.googlesource.com/platform/frameworks/base/+/master/core/java/com/android/internal/widget/ButtonBarLayout.java
Looking into the code, I think it's a LinearLayout for buttons (duh). You can probably look at it like the Dialog buttons divided by a vertical spacer: | . AllowStacking will change the orientation to vertical and the gravity to the right instead of bottom. I should try it out to give a better answer

ButtonBarlayout is not featured anywhere in the official Android documentation.
it is used for auto-switching orientations according to the space.

Regarding your question:
How should we use it?
I guess it is undocumented because it is not stable yet.
It just popped up because this long lasting complaint originate from poor ROM modification by device vendor.
https://code.google.com/p/android/issues/detail?id=78377
See #270 for the resolution regarding classpath and why all classes inside .internal. were made public.
And nope even that fix a lot of bugs from poor ROM modification are still out there (in lots of device of well known brands). The issue is soon declined by project member.
I don't think we should use it just yet until the document show up.
Just my $.02 though.

Just to add to the other answers, if you guys want to check the orientation of a ButtonBarLayout you should check the orienation AFTER the value has called on measure.
In other words (Kotlin):
buttonBarLayout.post {
val orientation = buttonBarLayout.orientation
val height = buttonBarLayout.measuredHeight
}

ViewPager preview layout in Android Studio

Is it possible to show a preview layout for ViewPager in AndroidStudio like in ListView/RecyclerView/etc.?

Short answer: No.
I think you're talking about ViewPager from ViewPager 2. My answer will be assuming ViewPager 2. Pls update the question to clarify that.
- Workaround: a hidden include
<include
android:visibility="gone"
tools:visibility="visible"
layout="#layout/item_that_shows_inside_viewholder"/>
And I agree that's a very poor way to do it.
If in constraint layout you can loosely match the same constraints to make this show on top. And yes, you will inflate this in production code so you may incurr in performance slow down depending on what you have there.
It's very unfortunate that tools:layout doesn't exist or work properly (yes, I got inconsistent results while trying it).
- 2nd less worst way is using isInEditMode on code on the parent class
something in the fashion of
class CustomView ....
init {
// inflate layout that contains ViewPager
if ( isInEditMode() ) {
//do something that replaces ViewPager with its inflated view holder
}
}
which has served me well when I can use that. However that's unsuitable for most places.
- If at least ViewPager were not final we could extend and do some tricks there using isInEditMode like above.
- You can make a custom class wrapper with internal field ViewPager
One way that does certainly work is making your custom class extend FrameLayout and having an internal view that is your actual ViewPager. But then you have to re-implement and delegate all its methods, which is a big pain. Maybe kotlin has a way to do that, but so far I don't know how. Or maybe using reflection or kotlin poet could be a way to do that. It's too risky for my taste.
- If we could make a databinding adapter to do the isInEditMode like above it would work. But databinding adapters don't run in preview.
- I tend to think these tools attributes get processed by Android Studio, so it would take probably an android studio plugin to work around it.
This is the current full list of tools attributes: https://developer.android.com/studio/write/tool-attributes.html#toolslistitem_toolslistheader_toolslistfooter
It may be useful reading this Android XML Is there a way to use the tool namespace with custom attributes?
where a library to read custom attributes with tools gets mentioned. There may be an alternative with this library, but I have never used it and not sure how it works:
https://github.com/giljulio/sneakpeek
I'd love to be proved wrong, but in my opinion all of the options are dead ends or too much effort.

In Andriod studio some views are shown in run time but not in compile time. Think about Frame Layout as a container for fragment transaction. We may place any kind of views on that container in run time. So, it's not possible to show a view while coding. The viewpager is playing same kind of role here. So, we can't show a view there before running and actually placing a fragment/other view there.
I hope you are clear now. :)

This is possible, when putting the ViewPager into it's own XML layout resource.
Alike this one can show the desired Fragment instead of the ViewPager:
<fragment
android:id="#+id/fragment_viewpager"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:layout="#layout/fragment_viewpager"
tools:layout="#layout/fragment_preview" />
This also provides the XML preview for the navigation graph design view.
tools:layout only works with fragment, but not with include.

i think it's not...some of the layouts have no preview while coding or designing ...like TabLayout

Although I don't think there is such a functionality out of the box, I used the following workaround to achieve design time preview for the ViewPager:
Add an <include> with the view that you will use in your ViewPager as a layout,just after the ViewPager itself
Set tools:visibility="visible" and android:visibility="gone" to this <include> view so that it will be visible at design time but not at runtime. Also set tools:visibility="gone" to the ViewPager so that it will be invisible at design time.
The idea is to hide ViewPager at design time and show its contents instead while doing the opposite at runtime. This should work for other controls as well.
To show an example:
<androidx.viewpager.widget.ViewPager
android:layout_width="match_parent"
android:layout_height="wrap_content"
app:layout_constraintTop_toBottomOf="#id/tabl1"
tools:visibility="gone">
</androidx.viewpager.widget.ViewPager>
<include
layout="#layout/fragment_example1"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:visibility="gone"
tools:visibility="visible"
app:layout_constraintTop_toBottomOf="#id/tabl1" />
I hope this helps you

Android: Change src alpha and keep background (blend src with color)

I've been looking for this for a while but can't really figure out any clean way to do it.
I'm developing an app with some buttons, mostly defined like this:
<ImageButton
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:background="#000000"
android:contentDescription="#null"
android:src="#drawable/btn1" />
There's a onTouchListener that changes the button alpha with setAlpha(0.5f), but it also changes the background alpha, which is not what I need. I'd like to make it look darker, not trasparent.
I've seen this question: Android Graphics: Changing the alpha of just an image (not the background), and the solution actually works, but it doesn't sound good for me to create a FrameLayout for every button in my app.
Given the fact that the background is a flat color I thought there would be a simpler solution such as color blending or something like that, but really couldn't find it anywhere.
SOLUTION
Just found out this post: http://tech.chitgoks.com/2011/04/17/android-change-imagebutton-tint-to-simulate-button-pressed/
The solution is as simple as:
button.setColorFilter(Color.argb(150,0,0,0));

You can get image drawable using getDrawable() method and try to change its alpha.

Missing or Incorrect images and backgrounds randomly throughout app lifecycle

I was hoping someone here might have an idea what causes this sort of behaviour:
Throughout my application, in seemingly random places and in random conditions I'm observing this strange UI issue. Images are on occasion being loaded black (with the correct bounds) or with the incorrect image source (again, with the correct bounds). This effects ImageViews and has effected android:background tags with references to colour resources.
My application relies on 6 library projects, it runs Native Code via a Service and Activities in the App use GlSurfaceViews (although, not all Activities which display the problem contain OpenGL components). The problem could I suppose be from any of these places or a combination of them through using large amounts of memory.
You can see this behaviour in the following screen shots:
This is actually a 6 or so pixel wide column separator image which has been incorrectly drawn into my ImageView (the ImageView seems to have correctly sized itself).
When going out of the Application and then back in again (repeatedly) it instead appeared (and remained) like so:
After a Force Clear and a Clear App Data it returned to the correct format:
As you can also see the Magnifying Glass image next to it is displaying fine in each of these. The problems with these missing/incorrect images and backgrounds seems to happen randomly, throughout the application lifecycle, and I've been unable to find a way of reproducing it.
The layouts for these images are nothing special, I'm not doing anything funny during the rendering lifecycle (i'm not overriding onDraw() or onMeasure() or the like). The source of these images aren't being set dynamically but via the XML.
As you can see from the above example, it's not a build issue as it occurs between app lifecycles not between installs. It's also happening on different devices, Samsung 8.9, Acer Iconia Tab, Motarola XOOM,
It seems to me to be some sort of error with the reference table, could it perhaps have been nudged by my native code? Or is it an effect of me in some stages of the application using too much memory?
Here's the XML source for the above example:
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:id="#+id/browseProgressWrapper"
android:layout_width="match_parent"
android:layout_height="#dimen/actionbar_compat_height"
android:orientation="horizontal">
<RelativeLayout android:layout_width="#dimen/search_bar_width"
android:layout_height="match_parent">
<EditText android:id="#+id/browseFilter"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:layout_marginTop="4dp"
android:layout_marginLeft="5dp"
android:imeOptions="actionSearch"
android:background="#drawable/edit_text_blue"
android:maxLength="30"/>
<ImageView android:id="#+id/clearSearch"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_alignParentRight="true"
android:layout_centerVertical="true"
android:src="#drawable/ic_input_delete"
android:layout_marginRight="5dp"/>
</RelativeLayout>
<ImageView android:id="#+id/browseFilterButton"
android:src="#drawable/ic_menu_search"
android:scaleType="center"
android:layout_width="#dimen/actionbar_compat_height"
android:layout_height="#dimen/actionbar_compat_height"
android:layout_gravity="center_vertical"
android:minWidth="#dimen/actionbar_compat_height"/>
</LinearLayout>
A more full description of the code / layout surrounding another such occurrence I happened to get the screenshot for:
I have a "Settings" Activity which restarts my app after saving new settings details. It does this by stopping a Service, calling a new Activity (the Splash Activity) and finishing itself:
mConfiguration.save();
mConfiguration = new Configuration(Configuration.getInstance());
getActivity().stopService(new Intent(getActivity(), NativeService.class));
getActivity().finish();
startActivity(new Intent(getActivity(), SplashActivity.class));
Most of the time (and on most devices) this works fine, the Splash Activity contains an image which loads correctly. Sometimes though on some devices the Splash Activity loads either an incorrect resource (what my testers refer as "an upside down Nike tick") or just a blank box (as seen below). Does anyone know why?
Here is the Layout for the Splash page, as you can see it's pretty simple, no surprises:
<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:background="#color/ContentBackgroundColor"
android:orientation="vertical" >
<View
android:layout_width="0dp"
android:layout_height="0dp"
android:layout_weight="2" />
<ImageView
android:id="#+id/image"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_gravity="center_horizontal"
android:src="#drawable/manager_android_400" />
<View
android:layout_width="0dp"
android:layout_height="0dp"
android:layout_weight="1" />
<ProgressBar
style="#android:style/Widget.ProgressBar.Large"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_gravity="center_horizontal" />
<View
android:layout_width="0dp"
android:layout_height="0dp"
android:layout_weight="2" />
</LinearLayout>
Theory tested and debunct:
I've theorised that this could be a processor/memory issue where the Layout isn't being drawn fully before the Splash screen exits and moves onto the next Activity so I put in this piece of code:
image = (ImageView) findViewById(R.id.image);
image.getViewTreeObserver().addOnGlobalLayoutListener(new OnGlobalLayoutListener() {
#Override
public void onGlobalLayout() {
image.getViewTreeObserver().removeGlobalOnLayoutListener(this);
moveToStartScreen.start();
}
});
The hope was the code above would make sure the Image is definitely loaded before moving onto the Start page but seems to have had no observable effect.
Another Theory
I was also wondering if this could be being caused by the R.id / R.colour / R.drawable resources some how being currupted in program execution? Does anyone know why that might happen.
Could my native code be running rampant on some memory addresses that Android isn't correctly allocating?
Has anybody noticed this before - or perhaps know why this behaviour occurs?

Graeme, I had almost the same problem and found out that it was a reported bug of the android plattform. It was corrected in the 3.0 version I think. Which API are you compiling with? Try to build with the last available api and be sure to compile with JDK 1.6
If your problem is related to this bug, this should fix the problem.

This is a simple problem of refresh, clean, and rebuild.
Images in your various drawable folders or resource id indices are out of sequence because they were either changed outside of the eclipse IDE (via external source control such as GIT, SVN or other edits) and not refreshed in the eclipse navigator. Or, the files may have been updated in a library project upon which your UI Activity depends.
I have found that although .java file dependencies are propagated throughout the system, this is not always the case for resources such as images and .xml files.
The solution is fairly simple, clean everything, refresh all of your projects, and rebuild. The stretched or black edges should be gone.
Note: The predominant manifestation of this problem occurs when 9-patch images become treated like standard .png images. This means that they get stretched in a linear manner across the image instead of just at the edges. To me, this explains your 'Torn/Stretched' example. I have seen similar often. Another common manifestation is that text strings occasionally get displayed with the wrong resources!

How to keep background image size when software keyboard show

When the software keyboard shows, it resizes my layout and thus squeezes the background image together. My question is basically a duplicate of this question, which is explained in a very good way:
Software keyboard resizes background image on Android
However, that question was closed when they found a hack to solve it. I cannot use this hack. My entire layout is inside a ScrollView, and I need to be able to use this scrollview properly at all times. By using android:windowSoftInputMode="stateVisible|adjustPan" the user will not be able to scroll down and see the bottom of the screen while the keyboard is showing, since the layout will partly exist behind the keyboard. Thus the solution is unacceptable to me. Are there any better solutions out there?
Cheers,

I actually ran into a similar problem not too long ago. I stumbled upon the correct answer with a bit of work, though.
In your android manifest for this project, attached to the specific activity that you are using, use the line android:windowSoftInputMode="adjustPan|stateVisible" in the activity tag.
adjustPan basically means that your activity will not resize itself to fit the soft keyboard, and stateVisible means that the soft keyboard will show when requested (this can be stateAlwaysVisible, etc if necessary)
source :
Android Dev for Activity tags

After days of hardcore hacking I finally managed to construct a solution so advanced it might actually hurt to read it. I place an ImageView with the background behind the scrollview, and set scaleType="matrix" so it does not shrink when the keyboard is shown.
<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
android:background="#color/black"
>
<ImageView
android:layout_width="fill_parent"
android:layout_height="fill_parent"
android:src="#drawable/mah_kewl_background"
android:scaleType="matrix"
/>
<ScrollView
android:layout_width="fill_parent"
android:layout_height="fill_parent"
android:fillViewport="true"
>
<RelativeLayout
android:id="#+id/smsLayout"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
>
<TextView
android:layout_width="fill_parent"
android:layout_height="wrap_content"
android:text="PLUNX"
/>
</RelativeLayout>
</ScrollView>
</RelativeLayout>

You can use the windowBackground property, which makes the drawable fit the whole screen.
To do that you need to:
1- Create a style:
<style name="Background" parent="#android:style/Theme.NoTitleBar">
<item name="android:windowBackground">#drawable/you_bg_drawable</item>
</style>
2- Set your activity style in the AndroidManifest.xml
<activity
android:name=".ui.your_activity"
android:theme="#style/Background"/>

I was googling for a solution to this exact problem when I came across this, and after doing some research I found a solution I think is slightly better. Instead of hacking with a ImageView you can use this from your activity:
getWindow().setBackgroundDrawableResource(R.drawable.bg_my_background);
Hope it helps anyone else searching for a solution for this.

I can't comment on your answer but I'd like to add something.
I understand your dilemma and why the solution you linked to isn't a complete solution for your situation (since you can't scroll to the bottom of the view). I have a similar situation with a large scrollable EditText box. When the soft keyboard pops up I don't like my background getting squished.
I have tried your solution and while at first glance it appears to work, there are some situations where it might not be ideal:
If you allow your app the have a landscape mode, the background will not resize/stretch
If you run your app on a device with a larger screen or dpi, your background may not fill the screen
Basically it seems that when you set the scaleType to matrix you're telling Android to draw the background 1:1 and not to scale. So what's happening when you open the soft keyboard using your solution is, your scrollView and imageView are all getting resized as usual, but the image src you set remains 1:1 thus continues showing the same area.
So if for example your background image was set to a specific size (e.g. 480 x 800) and it perfectly fills your Nexus One, the moment you rotate to landscape you will have a black area along the right.
This is moot, of course, if your background is simply a repeating pattern, in which case you can make it extremely large and hopefully compensate for various screens (maybe even tablets).
Or you can also supply different backgrounds for different screen sizes/densities/orientations, but this still doesn't account for scaling.
In a vain effort to try and solve this, I stumbled upon a View attribute called android:isScrollContainer. This attribute tells certain views whether or not they are allowed to resize upon display of the soft keyboard. This is also mentioned by someone in your linked solution. I have tried setting this (to false) on the ViewGroup containing my background, but any child element that scrolls seems override it causing the squishing again.
As of right now I don't think there is a complete solution for our situation. Your's definitely works in some instances and I thank you for the effort. Hopefully Google will offer a solution in the future, but I don't think they would consider this a problem/priority.

Maybe there's another (really simple!) solution:
In styles.xml:
create a new style like this:
<style name="Yourstyle" parent="AppBaseTheme">
<item name="android:windowBackground">#drawable/mybackground</item>
</style>
AppBaseTheme is your normally used theme for your app.
Then you add in Manifest.xml:
<activity
android:name="com.your.app.name.Activity"
android:theme="#style/Yourstyle">
</activity>
So you have the same style but with a background.
Important: don't set any backgrounds in your normal .xml file!
It's my first post and I hope it helps and sorry for my English.

in Androidmanifest in activity tag use:
<activity ... android:windowSoftInputMode="adjustPan" ></activity>
check Android Developer reference

How about a solution where the 'background' is a Layout. Can we inflate a layout, make it the entire window size, then insert it as a window background?

After a lot of time searching...
Put android:windowSoftInputMode="adjustPan|stateVisible" in each Activitys