Assigned
Status Update
Comments
ja...@gmail.com <ja...@gmail.com> #2
Thanks for the report. I was puzzled.
mi...@gmail.com <mi...@gmail.com> #3
The same for me. Android 4.0.4.
pa...@gmail.com <pa...@gmail.com> #4
This is intentional to reduce complexity of Spinner's API and implementation. Consider using a full-blown ListView in a dialog instead.
ja...@gmail.com <ja...@gmail.com> #6
I just spent 3 hours on this issue and I disagree that it is "working as intended". If you want to make developers happy, fail fast.
Spinner$DropDownAdapter wraps the client's adapter and shadows getItemViewType() and getViewTypeCount() and simply returns constants. This will never work as intended if the inner adapter has more view types.
I suggest the DropDownAdapter constructor asserts if adapter.getViewTypeCount() != 1.
Spinner$DropDownAdapter wraps the client's adapter and shadows getItemViewType() and getViewTypeCount() and simply returns constants. This will never work as intended if the inner adapter has more view types.
I suggest the DropDownAdapter constructor asserts if adapter.getViewTypeCount() != 1.
ra...@gmail.com <ra...@gmail.com> #7
THIS NEEDS TO BE FIXED.
al...@android.com <al...@android.com>
ma...@gmail.com <ma...@gmail.com> #8
What's going on with this issue?
[Deleted User] <[Deleted User]> #9
Implementation of Spinner.setAdapter() has changed in API 21 to enforce this, and now throws an exception.
From setAdapter's documentation:
On API LOLLIPOP and above, attempting to set an adapter with more than one view type will throw an IllegalArgumentException.
From setAdapter's documentation:
On API LOLLIPOP and above, attempting to set an adapter with more than one view type will throw an IllegalArgumentException.
mi...@gmail.com <mi...@gmail.com> #10
Voting +1 for this feature.
[Deleted User] <[Deleted User]> #11
It has been more than a year. Please add this!
[Deleted User] <[Deleted User]> #12
[Comment deleted]
[Deleted User] <[Deleted User]> #13
It will certainly be a nice feature and have a nice title for the chrome tab. Please fix this.
bo...@gmail.com <bo...@gmail.com> #14
Customize the status bar color is a real need. Voting +1
[Deleted User] <[Deleted User]> #15
Yes, it's needed definitely. Please!! Voting+1.
ma...@gmail.com <ma...@gmail.com> #16
Any date to the release of this feature? Working with VectorDrawables is awesome and let us have an IconKit but this little impediment make it not perfect
ja...@gmail.com <ja...@gmail.com> #17
Voting +1 for this feature.
mo...@gmail.com <mo...@gmail.com> #18
Voting +1 for this feature.
m....@gmail.com <m....@gmail.com> #19
voting +1 for this feature
de...@gmail.com <de...@gmail.com> #20
Voting +1 for this feature.
me...@gmail.com <me...@gmail.com> #21
Voting +1 for this feature.
kr...@gmail.com <kr...@gmail.com> #22
+1 from me. I really need this feature.
su...@gmail.com <su...@gmail.com> #23
+1 from me. I've to fallback my implementation to webview because of this graphic inconsistency.
ar...@connectmedica.com <ar...@connectmedica.com> #24
Voting +1 for this feature.
ia...@gmail.com <ia...@gmail.com> #25
Voting +1 for this feature.
ke...@pinxterapp.com <ke...@pinxterapp.com> #26
Voting +1 for this feature.
ni...@google.com <ni...@google.com>
[Deleted User] <[Deleted User]> #27
Not being able to set a proper dark or light statusbar/toolbar icon color is breaking our app color design very bad.
+1 for this feature.
+1 for this feature.
ja...@gmail.com <ja...@gmail.com> #28
Voting +1 for this feature.
[Deleted User] <[Deleted User]> #29
Estoy de acuerdo con este comentario, es molesto cuando el diseñador te levanta la mano porque no le convence el contraste de los colores y te es imposible responder con fundamento y suplir los criterios. Sería genial poder personalizar más esta sección.
ru...@gmail.com <ru...@gmail.com> #30
This has been an issue for 6 years now. Why isn't Google dealing with it? If I'm to use Custom Tabs, I need to be able to change the toolbar text and color at will.
sa...@gmail.com <sa...@gmail.com> #31
ช่วยแก้ไข browser ให้ผมหน่อยครับ
Description
However, for my app, the derived colors for both are noticeably different than the rest of my application. While the functionality of custom tabs is winning over the designer, they are not happy with the visual result.
Therefore, I'd like to be able to specify the status bar color to use with the custom tab (ie the primaryColorDark from my application). Seems reasonable if the developer doesn't specify a status bar color it uses the derived color as it does today.
As well I'd like to control the icon tint in the tool bar for the default "close" and "overflow" icons. While, specifying my own bitmap works around the "close" icon, the overflow icon tint is still controlled by the custom tab and may not match the overall theme.