-
Notifications
You must be signed in to change notification settings - Fork 80
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Seekbar preference cleanup #70
Comments
Thanks for the detailed thoughts!
Could you explain how/when the preview flickers? Because I can't replicate any flickering on my device.
I noticed this too. Seek bars in Android indeed only update their value when they are dragged or released. However, this is actually a 'feature' and not a bug. The seek bar doesn't update, because the touch event hasn't been determined yet if you tap and hold still on the seek bar. If you slide down or up, the touch event is interpreted as an scroll and thus the seek bar shouldn't be updated. It only updates if the user slides horizontally or releases in the same place. I think it is possible to only show the preview if the touch event has been confirmed as a seek bar event (if the seek bar has been changed), do you think this would be an improvement?
Yeah, I think they should probably be refactored as all extending a single class, like
I think the separate moon icons can be useful to users, because they make it more clear what is being changed by modifying a seek bar.
I particularly like the idea of putting the moon icons in the profile spinner, to illustrate the colour of the profile, but I'm not sure how much work it would be to implement. |
Maybe "flash" would have been a better word than "flicker" On my Samsung Galaxy S4, the preview takes just under a quarter second to turn on when I tap and hold. So if I tap and hold for just over a quarter second, the filter is only on for a fraction of a second. It's a bug in the design, not the code.
I think so.
Option 1 is safe. Option 2 is better but has a number of possible pitfalls:
There's no way to know without trying it, though; you can decide whether it's worth the time to develop something you might just throw away.
That's fair. I don't feel strongly about this anyway.
Might be quite a bit; I think the hardest thing here is that you'd want them to stay at their true color regardless of whether the filter is active. I also read recently that Android N may include a built-in red filter, which means that the use cases for Red Moon may be fewer (but still exist, I think) in the future, unfortunately (or fortunately, depending on how you look at it). |
For reference, there is now a generic SeekBarPreference that will eventually replace the others (or at least, they will all inherit from it). It is not currently used anywhere. |
Here's a bunch of thoughts about filtering. I couldn't decide where to draw lines so I'm just going to dump them all here.
I looked at this a little bit, and it seems like 'OnSeekBarChangeListener` isn't getting called until I lift my finger. If so, that's a bug in android's seekbar, not red moon.
It seems like the biggest barrier to refactoring would be the moon icons. You could still keep the three separate classes, but make them extend a new class that contains all the duplicate logic... but I also wonder if we could just remove the icons. The only unique things are:
The text was updated successfully, but these errors were encountered: