Status Update
Comments
op...@gmail.com <op...@gmail.com> #2
Thank you for posting.
Kindly provide a sample app with screen recording and steps to reproduce for further checking.
jo...@gmail.com <jo...@gmail.com> #3
The issue is easily reproduced with the Stroke and Width settings for Buildings (3d and Footprint) within the latest Maps JavaScript API and both the old web-based Map Styles editor and the new cloud-based Map Styles editor. You can reproduce the issue by attempting to add an outline (stroke) of any width under Landscape-Human-made(man_made)-Buildings. The expected changes do not show in the rendered map within the Styles editor(s) or when loading the map via saved Map ID elsewhere.
I don't have time this week to author a screen recording that redacts my proprietary intellectual property, and I certainly won't be providing a copy of my software or authoring a sample app for you when you can already easily duplicate the bug in your own Map Styles editors.
I may have time to provide a marked-up screenshot from the Map Styles editor later tonight or tomorrow when I am back at my computer.
[Deleted User] <[Deleted User]> #4
To follow-up on this in an effort to assist you in bringing this bug to a resolution, please see the attached screenshot from the (old) Map Styles editor showing the issue and how you can duplicate it on your own. Similarly, the issue can also be duplicated in the (new) preview of the cloud-based Map Styles editor. Stroke color and width are not working as expected, for both the 3d and footprint style of buildings on the map. To assist you in locating the Map Styles editor, here is the link to Map Styles:
[Deleted User] <[Deleted User]> #5
Thank you for the information.
We have verified and logged this issue internally. Please note that we cannot give you any timelines, but you can star the issue to get notifications.
th...@gmail.com <th...@gmail.com> #6
pa...@gmail.com <pa...@gmail.com> #7
[Deleted User] <[Deleted User]> #8
ma...@mobconverge.com <ma...@mobconverge.com> #9
ma...@mobconverge.com <ma...@mobconverge.com> #10
I did notice a recent change to the (new) cloud-based Map Styles editor which added the ability to edit the stroke color and width for the footprint style of buildings. That seems to be some positive progress.
ma...@mobconverge.com <ma...@mobconverge.com> #11
<codes><312220318></codes>
jc...@gmail.com <jc...@gmail.com> #12
jc...@gmail.com <jc...@gmail.com> #13
jc...@gmail.com <jc...@gmail.com> #14
Please add this to the list of bugs/issues that I have reported above: Building Fill color is missing the Transparency option.
as...@dismoiou.fr <as...@dismoiou.fr> #15
jc...@gmail.com <jc...@gmail.com> #16
Thank you for your message.
As per checking,
Our Engineering team is actively working on fixing the mentioned issues. We apologize for the delay and sincerely appreciate your understanding.
Rest assured that once we have receive any shareable updates, we'll let you know.
Thanks again.
ni...@gmail.com <ni...@gmail.com> #17
[Deleted User] <[Deleted User]> #18
There has been an update in our documentation related to the stroke color and weight. The following pages have been updated. In short "Stroke color and stroke weight customizations are not available for 3D style buildings."
-
-
Well, I guess that is one way to fix an annoying bug... just rewrite the documentation to make it look like the bug was intentional. I have to say, that is the funniest and most annoying thing I have heard in a long time. What a joke Google Maps API has become. If the goal is to force developers to seek alternative mapping solutions, you all are succeeding.
It is also worth mentioning, I am not privileged enough to actually have access rights to view either of the documentation links that were provided (internal to Google maybe?), but I will assume that they are just trying to cover up their mistake instead of actually fixing the issues. How utterly disappointing and frustrating!
ne...@gmail.com <ne...@gmail.com> #19
I assume they will update the doc to include fill/transparency on 3D buildings too
te...@gmail.com <te...@gmail.com> #20
mw...@gmail.com <mw...@gmail.com> #21
[Deleted User] <[Deleted User]> #22
ed...@gmail.com <ed...@gmail.com> #23
We really apologize for this experience.
The internal issue that we filed is still open as our engineers are still actively working on it.
Once again, apologies and thank you very much for your understanding. Once we are able to receive updates, we will surely let you know.
iv...@gmail.com <iv...@gmail.com> #24
"The refresh indicator appears only in conjunction with a refresh gesture or action. Syncing does not display a refresh indicator."
pa...@gmail.com <pa...@gmail.com> #25
I couldn't find any recommended way to display initial loading. Empty view is for empty list, having a separate loading indicator and a swipe-to-refresh indicator is problematic to code and may confuse the user. In Google's world everything shows up immediately.
Note that even the GMail app shows two indicators sometimes. In the morning when I turn WiFi on, it starts syncing, but it takes a while, and if in the middle of that I swipe to refresh it shows me two spinners, going in opposite directions.
al...@gmail.com <al...@gmail.com> #26
am...@google.com <am...@google.com> #27
az...@gmail.com <az...@gmail.com> #28
Still not fixed
[Deleted User] <[Deleted User]> #29
jh...@gmail.com <jh...@gmail.com> #30
[Deleted User] <[Deleted User]> #31
I propose removing setRefreshing(boolean) entirely, or deprecating it.
[Deleted User] <[Deleted User]> #32
Anyways, it probably shouldn't be deprecated, because apps are already using it.
pa...@gmail.com <pa...@gmail.com> #33
ra...@gmail.com <ra...@gmail.com> #34
A more robust workaround would be to use a Global Layout Listener to ensure that the view is properly placed in the hierarchy and sized appropriately, something like this:
private class OnLayoutReadyListener implements OnGlobalLayoutListener {
@SuppressWarnings("deprecation")
@Override
public void onGlobalLayout() {
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.JELLY_BEAN) {
getViewTreeObserver().removeOnGlobalLayoutListener(this);
} else {
getViewTreeObserver().removeGlobalOnLayoutListener(this);
}
if (!mLayoutReady) {
mLayoutReady = true;
setRefreshing(mPreLayoutReadyRefreshing);
}
}
}
Hope this helps.
ad...@gmail.com <ad...@gmail.com> #35
ad...@gmail.com <ad...@gmail.com> #36
ad...@gmail.com <ad...@gmail.com> #37
I want to keep the spinner on after activity recreation or programatically start it on the first startup.
It is bad UX to have two different loading spinners, one for the gesture and one for initial load/activity recreation.
lb...@gmail.com <lb...@gmail.com> #38
ca...@gmail.com <ca...@gmail.com> #39
pa...@gmail.com <pa...@gmail.com> #40
am...@google.com <am...@google.com> #41
We have passed this defect on to the development team and will update this issue with more information as it becomes available.
Thanks
ro...@gmail.com <ro...@gmail.com> #42
pa...@gmail.com <pa...@gmail.com> #43
nk...@gmail.com <nk...@gmail.com> #44
to...@gmail.com <to...@gmail.com> #45
Here's my fragment's layout xml, how it works for me.
<android.support.v4.widget.SwipeRefreshLayout
xmlns:android="
xmlns:app="
xmlns:tools="
android:id="@+id/pull_to_refresh"
android:layout_width="match_parent"
android:layout_height="wrap_content">
<ScrollView
android:layout_width="match_parent"
android:layout_height="match_parent"
android:background="#567123">
<TextView
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="Hello World!"
android:textColor="@android:color/black"/>
</ScrollView>
</android.support.v4.widget.SwipeRefreshLayout>
I hope I could help.
lb...@gmail.com <lb...@gmail.com> #46
au...@google.com <au...@google.com> #47
al...@android.com <al...@android.com> #48
ch...@gmail.com <ch...@gmail.com> #49
lb...@gmail.com <lb...@gmail.com> #50
ch...@gmail.com <ch...@gmail.com> #51
[Deleted User] <[Deleted User]> #52
[Deleted User] <[Deleted User]> #53
au...@google.com <au...@google.com> #54
ja...@gmail.com <ja...@gmail.com> #55
au...@google.com <au...@google.com> #56
lb...@gmail.com <lb...@gmail.com> #57
ch...@gmail.com <ch...@gmail.com> #58
au...@google.com <au...@google.com> #59
final SwipeRefreshLayout srl = (SwipeRefreshLayout) findViewById(R.id.srl);
srl.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) {
srl.removeOnLayoutChangeListener(this);
srl.setRefreshing(true);
}
});
ch...@gmail.com <ch...@gmail.com> #60
do...@gmail.com <do...@gmail.com> #61
Just create a new class which inherit from SwipeRefreshLayout and add the following code. Use it in your layout files (com.example.view.CustomSwipeRefreshLayout for example) but reference it in your code like the classic SwipeRefreshLayout.
When the new lib version is out, just replace all occurrences of your custom class in your project by the original one.
private boolean mMeasured = false;
private boolean mPreMeasureRefreshing = false;
@Override
public void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
super.onMeasure(widthMeasureSpec, heightMeasureSpec);
if (!mMeasured) {
mMeasured = true;
setRefreshing(mPreMeasureRefreshing);
}
}
@Override
public void setRefreshing(boolean refreshing) {
if (mMeasured) {
super.setRefreshing(refreshing);
} else {
mPreMeasureRefreshing = refreshing;
}
}
au...@google.com <au...@google.com> #62
tu...@gmail.com <tu...@gmail.com> #64
al...@gmail.com <al...@gmail.com> #65
tu...@gmail.com <tu...@gmail.com> #66
vl...@trimexa.de <vl...@trimexa.de> #67
vl...@gmail.com <vl...@gmail.com> #68
au...@google.com <au...@google.com> #69
[Deleted User] <[Deleted User]> #70
<android.support.v4.widget.SwipeRefreshLayout
android:layout_width="match_parent"
android:layout_height="match_parent"
bind:refreshing="@{showLoader}">...<...>
where showLoader is observableBoolean, setted in binding class in onViewCreated method.
Fragment appears with animation if it is important.
ni...@gmail.com <ni...@gmail.com> #71
ni...@gmail.com <ni...@gmail.com> #72
he...@gmail.com <he...@gmail.com> #73
su...@gmail.com <su...@gmail.com> #74
If you can make a video of what you're doing, it will help other (and dev team) to reproduce this bug easily.
Android Studio allows you to capture video from the connected device/AVD.
pa...@gmail.com <pa...@gmail.com> #75
I think a fully working/easy to compile demo project would also be helpful to gather attention from the dev team.
Description
SwipeRefreshLayout indicator does not appear when the `setRefreshing(true)` is called before the `SwipeRefreshLayout#onMeasure()`.
Sample:
{{{
public class MainActivity extends Activity implements SwipeRefreshLayout.OnRefreshListener {
private SwipeRefreshLayout mSwipeRefreshLayout;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
mSwipeRefreshLayout = (SwipeRefreshLayout) findViewById(R.id.swiperefresh);
mSwipeRefreshLayout.setOnRefreshListener(this);
// Indicator will not appear
mSwipeRefreshLayout.setRefreshing(true);
stopRefreshingDelayed();
}
@Override
public void onRefresh() {
stopRefreshingDelayed();
}
void stopRefreshingDelayed() {
new Handler().postDelayed(new Runnable() {
@Override
public void run() {
mSwipeRefreshLayout.setRefreshing(false);
}
}, 10000);
}
}
}}}
Workaround:
{{{
mSwipeRefreshLayout.setProgressViewOffset(false, 0,
(int) TypedValue.applyDimension(TypedValue.COMPLEX_UNIT_DIP, 24, getResources().getDisplayMetrics()));
}}}