Status Update
No update yet.
Comments
ar...@google.com
is...@google.com
al...@google.com
I am able to also reproduce issue #1 now; I've committed a change to the sample project that sets enableMultiInstanceInvalidation() on the DB and adjusts the timing a bit more. After running it for 15 minutes or so I am seeing multiple skipped updates.
My production app uses enableMultiInstanceInvalidation() as well, so this may be a significant factor.
al...@google.com
Any thoughts on this one? I mean, it makes JournalMode.TRUNCATE largely useless, unless one has a penchant for random app misbehaviors. I'd like to keep using TRUNCATE, as it avoids certain headaches from WRITE_AHEAD_LOGGING.
am...@google.com
an...@google.com
To be clear, "batching" does not take care of the missed invalidation notifications. Updates for a table may be spaced hours apart, and in my production app about 5% of notifications are lost, meaning that the user does not see the update until the next one comes in, which may be hours later. It's a chatroom feature, where reliable, timely updates are important.
Also, not setting enableMultiInstanceInvalidation() does not fix the issue, it only changes the timing; notifications go missing regardless of whether I include one process or multiple.
Description
In support transitions we also have such bug.
Library com.android.support:transition:26.0.0-beta2
In some cases if you apply more than one animators that animate visibility changes it will show two instances of view.
Example project:
Screencast is attached.
Works fine with the code:
TransitionManager.beginDelayedTransition(container,
new TransitionSet()
.addTransition(new Fade())
.addTransition(new Slide(Gravity.RIGHT)));
icon.setVisibility(View.GONE);
But have two "instances" of animated view in that case:
TransitionManager.beginDelayedTransition(container,
new TransitionSet()
.addTransition(new Fade())
.addTransition(new Slide(Gravity.RIGHT)));
container.removeView(icon);
The reason of it that every Visibility transition add the "screenshot" of view to the overlay separately. I think first Visibility transition should add view to the overlay and the second Visibility transition should reuse the same view from overlay and apply animation to it.
I've already fixed the issue in my backport of transitions framework -