-
Notifications
You must be signed in to change notification settings - Fork 278
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
Implement determinate circular progressbar #51
Conversation
be12a2c
to
f18bf55
Compare
Thanks, I'll look into the code later. Another question remains that whether the circular progress should move its starting point along the circumference. Although the spec presented so, it might be confusing to user (If the progress stalls it looks kind of weird, might seem as if an indeterminate progress just get stuck, and inconsistent compared to the horizontal counterparts) and hard to estimate the progress, plus that the spec has no text specification on this except for that video. Just did a quick research on this:
|
I personally like the effect of the moving starting point, which is an innovative way to visually fill the square element and provide visual symmetry even for early progress values. I don't think a circular progress indicator alone can give the user a precise estimate about the progress value. If that is needed, other UI elements must be used anyway. So I think it is good enough if the user can get a rough idea how far the progress is. Additionally you can see that the length of the coloured arch is linear to the progress, starting from 0°at 0% to 360° at 100%, even if the arch is moving. So if you observed the element a couple of times, you get a good feeling of how far the progress is. Given that, I'd love to keep the effect as it is shown in the video provided by Google. |
I think a circular progress indicator alone can give the user an easy impression of the progress, e.g. if the progress starts at the top, then users can read a quarter, half, three quarters, it's pretty natural, the same as we read clocks. However if the starting point is moving around, the same experience can not apply any more. Users will need extra efforts to read it, or get accustomed to a new way of interaction that is not seen elsewhere. So although I'm somewhat a spec follower and lover, I have my reservation about this particular design, which is also never stated literally but only showcased in a video. |
Other unresolved issues include:
I prefer making a decision upon these design/implementation issues before we merge it into this library. |
Sure, that can be done easily
You mean a background of the circle? Might be possible but I did not see it in a Material example. So I'd rather skip it until there is a good reason to implement it.
I almost finished implementing that but then it was a bit buggy so I discarded it because I did not see it in the Materials documentation and I personally do not need it. But yes, that can be done for consistency.
I have no experience with VectorDrawableCompat and I looked how the current implementations work. Moving to VectorDrawableCompat is going to be an entire rewrite of the core library so I'd leave this as a second step. Having a stable set of features is a good base for evaluating if VectorDrawableCompat can replace Canvas throughout the library. |
Is there anything I can do for the progress of this ticket? |
Still think that the progress should start at top (at least by default), per the two Angular Material versions by Google (see above), and (my own) UX considerations. If this can be an attribute, I'm wondering what its name should be, And about the secondary progress -- I think it should better be implemented, but it would be weird if the starting point is moving according to progress -- where should it start if it has a different progress value compared to the primary one? And I think a track should also be implemented, like the horizontal counterpart. |
Great, thanks. I'll take care of that. What about |
42b29ad
to
e0f6db8
Compare
Thanks for your work! I'll review the code later, due to some personal matters. |
Okay cool, thanks :) |
So you think it is possible to review and release this within this week? I need the determinate circular progress for an upcoming app release. Otherwise I need to somehow build a fork locally but if that could be avoided would be great. |
the PROGRESS_STYLE_CIRCULAR block now works exactly as the PROGRESS_STYLE_HORIZONTAL block
on a 1x device, 16px was larger than the 14dp Small.NoPadding style size
b3c205c
to
f5b8a90
Compare
Alright, thanks. Interesting, I did not know that you get the access rights to push to my fork's branch. Otherwise I am familiar with rebasing et cetera, no problem. |
dcmTintedSecondaryBackground | ||
); | ||
|
||
new Thread() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't kick off threads for animation in Android; In most cases one should use ObjectAnimator
, and it is much more smoother. I'll refactor this later.
dfb4ed5
to
8ea4a61
Compare
Finished reviewing the library module except the 15 degree problem. |
What is the "15 degree problem"? |
@webmaster128 https://github.com/DreaminginCodeZH/MaterialProgressBar/pull/51/files/7b6d3d41ae131315032990f49e0975fef23bd0b9#r110824773 |
@DreaminginCodeZH The link does not point me to any specific line or comment |
Strange, perhaps you need to wait till the page load is finished. Anyway you can C-F the string:
|
I measured the angle from the first frame that I could capture in the video. I am pretty sure it does not start at 0. Thus I took 15 and was happy with the result. 0 was not tested. |
It is not there. Did you write it as a pending review comment? |
mEndAngleMax = 360; | ||
break; | ||
case MaterialProgressBar.DETERMINATE_CIRCULAR_STYLE_MOVINSTART: | ||
// leading and trailing angles start at 15° or 5 minutes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How did you get this 15
? By estimating from the video, or by stepping to find the first frame and measuring in Photoshop etc? Is it precise, or can it be from the fact the at the beginning the progress is thin but quick in motion? Have you done comparison between 0
and 15
, and if so is it that 15
wins? (Yes I forgot to submit this review : (
Merged, thanks! Will be released later. |
Released on Maven Central just now, should be available within hours. |
Cool, thanks! |
This is an implementation of the determinate circular progress bar as shown here: https://storage.googleapis.com/material-design/publish/material_v_10/assets/0B14F_FSUCc01N2kzc1hlaFR5WlU/061101_Circular_Sheet_xhdpi_005.webm
Closes #24
Screenshots of this implementation:
1 2 3 4 5 6 7 8