Skip to content
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

Set the fill level manually #4

Closed
dasheck0 opened this issue Sep 2, 2015 · 24 comments
Closed

Set the fill level manually #4

dasheck0 opened this issue Sep 2, 2015 · 24 comments

Comments

@dasheck0
Copy link

dasheck0 commented Sep 2, 2015

Hi,

as far as I see there is no possibility to set the fill level by hand. This would be nice in order to turn it into an actual loader. Currently you specify a time value for the loader, which is not quite the intention of a loader. Consider a process like a call against an API or database or whatever. Depending on the current status of the request one could set the fill level as a percentage scale. Another possibility would be to restart the loader once he is done (aka repeat mode). I think this is even easier to implement and usually more appropriate for loaders since one does not always have a way to get the current requests state.

Let me know if my explanation was helpful or if you need more information.

Best regards
dasheck

@JorgeCastilloPrz
Copy link
Owner

I will keep this is mind for the next release. Thanks for the advice ;)
El 2/9/2015 9:01 a. m., "dasheck0" notifications@github.com escribió:

Hi,

as far as I see there is no possibility to set the fill level by hand.
This would be nice in order to turn it into an actual loader. Currently you
specify a time value for the loader, which is not quite the intention of a
loader. Consider a process like a call against an API or database or
whatever. Depending on the current status of the request one could set the
fill level as a percentage scale. Another possibility would be to restart
the loader once he is done (aka repeat mode). I think this is even easier
to implement and usually more appropriate for loaders since one does not
always have a way to get the current requests state.

Let me know if my explanation was helpful or if you need more information.

Best regards
dasheck


Reply to this email directly or view it on GitHub
#4.

@danvass
Copy link

danvass commented Sep 4, 2015

@JorgeCastilloPrz This would be an invaluable feature in order to be able to use this a loader. How difficult would it be to implement such a function?

@JorgeCastilloPrz
Copy link
Owner

Not really much. Just a little bit of time. I will do it next week if i can.
El 4/9/2015 9:49 a. m., "DVassilev" notifications@github.com escribió:

@JorgeCastilloPrz https://github.com/JorgeCastilloPrz This would be an
invaluable feature in order to be able to use this a loader. How difficult
would it be to implement such a function?


Reply to this email directly or view it on GitHub
#4 (comment)
.

@danvass
Copy link

danvass commented Sep 10, 2015

@JorgeCastilloPrz Had a chance to look at it yet?

@athkalia
Copy link
Contributor

This is indeed a must have for a loader, as there's a good chance that one can't predetermine that amount of time a task takes. If possible, can you provide us with an ETA on this?

cheers,
Sakis

@JorgeCastilloPrz
Copy link
Owner

I want to work on this, but i am totally busy this month and the next one
too because plenty of personal reasons.

I will totally review any PRs providing this feature if you want to work on
it. If you don't, i think you will have to wait a little bit.

I am so sorry.
El 19/9/2015 5:40 p. m., "athkalia" notifications@github.com escribió:

This is indeed a must have for a loader, as there's a good chance that one
can't predetermine that amount of time a task takes. If possible, can you
provide us with an ETA on this?

cheers,
Sakis


Reply to this email directly or view it on GitHub
#4 (comment)
.

@athkalia
Copy link
Contributor

No bother, I totally understand.

I may actually provide you with a PR within the next couple of weeks as this loader seems amazing and we want to use it

Cheers,

Sakis

From: Jorge Castillo [mailto:notifications@github.com]
Sent: Saturday, September 19, 2015 9:09 PM
To: JorgeCastilloPrz/AndroidFillableLoaders AndroidFillableLoaders@noreply.github.com
Cc: athkalia sendmeamini@hotmail.com
Subject: Re: [AndroidFillableLoaders] Set the fill level manually (#4)

I want to work on this, but i am totally busy this month and the next one
too because plenty of personal reasons.

I will totally review any PRs providing this feature if you want to work on
it. If you don't, i think you will have to wait a little bit.

I am so sorry.
El 19/9/2015 5:40 p. m., "athkalia" notifications@github.com escribió:

This is indeed a must have for a loader, as there's a good chance that one
can't predetermine that amount of time a task takes. If possible, can you
provide us with an ETA on this?

cheers,
Sakis


Reply to this email directly or view it on GitHub
#4 (comment)
.


Reply to this email directly or view it on GitHub #4 (comment) .


No virus found in this message.
Checked by AVG - www.avg.com http://www.avg.com
Version: 2015.0.6140 / Virus Database: 4419/10658 - Release Date: 09/17/15

@JorgeCastilloPrz
Copy link
Owner

Thanks ;)
El 19/9/2015 8:10 p. m., "athkalia" notifications@github.com escribió:

No bother, I totally understand.

I may actually provide you with a PR within the next couple of weeks as
this loader seems amazing and we want to use it

Cheers,

Sakis

From: Jorge Castillo [mailto:notifications@github.com]
Sent: Saturday, September 19, 2015 9:09 PM
To: JorgeCastilloPrz/AndroidFillableLoaders <
AndroidFillableLoaders@noreply.github.com>
Cc: athkalia sendmeamini@hotmail.com
Subject: Re: [AndroidFillableLoaders] Set the fill level manually (#4)

I want to work on this, but i am totally busy this month and the next one
too because plenty of personal reasons.

I will totally review any PRs providing this feature if you want to work on
it. If you don't, i think you will have to wait a little bit.

I am so sorry.
El 19/9/2015 5:40 p. m., "athkalia" notifications@github.com escribió:

This is indeed a must have for a loader, as there's a good chance that
one
can't predetermine that amount of time a task takes. If possible, can you
provide us with an ETA on this?

cheers,
Sakis


Reply to this email directly or view it on GitHub
<
#4 (comment)

.


Reply to this email directly or view it on GitHub <
https://github.com/JorgeCastilloPrz/AndroidFillableLoaders/issues/4#issuecomment-141694406>
.


No virus found in this message.
Checked by AVG - www.avg.com http://www.avg.com
Version: 2015.0.6140 / Virus Database: 4419/10658 - Release Date: 09/17/15


Reply to this email directly or view it on GitHub
#4 (comment)
.

@dasheck0
Copy link
Author

Hey Jorge. We will release an app in the next couple of weeks with your loader included. You might want to check it out once it's published. Maybe you'll get a decent list of using apps over time.

Cheers
dasheck

@JorgeCastilloPrz
Copy link
Owner

Sounds good ;). Just get in contact again with a link to the app so I can
check it out and begin with that app list.
El 19/9/2015 8:16 p. m., "dasheck0" notifications@github.com escribió:

Hey Jorge. We will release an app in the next couple of weeks with your
loader included. You might want to check it out once it's published. Maybe
you'll get a decent list of using apps over time.

Cheers
dasheck


Reply to this email directly or view it on GitHub
#4 (comment)
.

@athkalia
Copy link
Contributor

Hello,

turns out I will be adding this feature right away!
Just want to confirm the functionality with you before I go ahead

Are you happy with the following:

When the user selects a percentage then the stroke will first be drawn for the selected amount of strokeDrawingDuration, and then the fill will be added all the way up to the percentage selected, with the specified animation. The animation will slowly fill the shape for a duration relative to the fillDuration. E.g. for a fillDuration of 10 seconds, a 50% percentage will take 5 seconds. When the percentage value defined is reached then the loading freezes. If we then move to 60% that will be another 10% loading out of 10 seconds which is 1 second, so loading will continue from 50% to 60% and will take 1 second. The view will keep drawing itself until we've reached the 100%. When that's done the shape will be filled with the same pace and finish all actions. For our example when we mark the loading bar as 100% it will slowly start filling from 60% to 100% for 4 seconds then finish.

What do you think ?

@danvass
Copy link

danvass commented Sep 20, 2015

@athkalia If you're setting the percentage of fill what is the point of having duration? Wouldn't the whole point of setting the fill manually be to avoid setting any durations. You could perhaps make the first 10% for the stroke and the other 90% for the fill and whenever you setPercentage it will go from current percentage to the stated percentage in under a second that way keeping it somewhat smooth whilst quick. I think that if there is an option to set the fill manually it should not rely on any durations.

@JorgeCastilloPrz
Copy link
Owner

I think the most interesting thing to do here would be doing the stroke anim with the duration stated by the user at first, but just one time. then use the percent setter to fill from the current already filled percent to the new one. Always do it using onDraw() logic , and not using animations.

That would generate an interesting effect, I think. The user always has the power of setting the stroke drawing time to 0 if he do not want to animate stroke when using it as a loader. But let's not remove that possibility.

@athkalia
Copy link
Contributor

Exactly. If the user wants to make it 100% accurate, then they can set the strokeDuration and the fillDuration to 0. Then it just follows the percentage. (First doing the whole stroke instantly, then doing the fill according to the percentage). But I doubt this will be any good on the eye. I think that the most eye catching result will be a "relaxed" loading bar that has small values for strokeDuration and the fillDuration.

I'll try to make a pr today, and you guys can give it a shot and tell me what you think !

@JorgeCastilloPrz
Copy link
Owner

Ok. Keep an eye on code style. Travis Build is using it and it must pass. Use Java Square Code Styles if you want it to be easier.

@danvass
Copy link

danvass commented Sep 20, 2015

Yes ok setting the duration to 0 would be ideal as it gives flexibility. As soon as you make a PR I'll test right away and give you feedback.

@athkalia
Copy link
Contributor

Hey,

the commit is ready, but when I try to push it to a new branch it gets rejected. Are there some kind of permissions that you need to grant me with so that I can create a remote branch in your repo ?

@danvass
Copy link

danvass commented Sep 22, 2015

@athkalia Maybe try forking it and sending a PR from your repo?

@JorgeCastilloPrz
Copy link
Owner

That's it. Try forking it before applying the changes and opening the PR to compare your feature branch extracted from your fork, with my master branch.

@athkalia
Copy link
Contributor

Hey,

thanks. That's what I did Made a Pull request here:
#5

@danvass
Copy link

danvass commented Sep 28, 2015

Has the pull request been implemented?

@Letme
Copy link
Contributor

Letme commented May 13, 2016

PR #5 was merged in so we can close this.

@JorgeCastilloPrz
Copy link
Owner

Sure!
El 13 may. 2016 9:15 p. m., "Crt Mori" notifications@github.com escribió:

PR #5 #5
was merged in so we can close this.


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#4 (comment)

@JorgeCastilloPrz
Copy link
Owner

Already merged and working for version 1.03. Check It out and thanks for the PRs to everybody !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants