Re: Best practice with NSProgressIndicator
Re: Best practice with NSProgressIndicator
- Subject: Re: Best practice with NSProgressIndicator
- From: Quincey Morris <email@hidden>
- Date: Fri, 28 Jul 2017 10:57:45 -0700
On Jul 28, 2017, at 08:57 , Mark Allan <email@hidden> wrote:
>
> I have an app with a helper tool that performs some lengthy process in a loop
> and reports progress to the user. It works out how many iterations of the
> loop will be needed, sets the progressbar.maxValue, and then increments the
> progress bar's value on each iteration.
Can you clarify this description? Is the helper tool running in a separate
process, in which case how (and how often) is it reporting progress back to the
app? Is it the helper tool that’s looping progressbar.maxValue times? What is
the app doing while the helper tool is running?
Also, it seems like a “code smell” if the code that’s iterating millions of
times is updating a progress bar directly. Actually, two issues:
1. In a MVC design, code that’s calculating like this is generally part of the
model, and shouldn’t be aware of what UI element is reporting progress, even
though the model may provide some progress information.
2. The iteration is presumably on a background thread, and it’s not clear how
you transfer the progress information safely to the main thread.
The normal solution to #1 is some kind of observation (of the progress
information), and to #2 is some kind of trampoline. Both of those techniques
lend themselves to thinning the frequency of UI updates, so you have choices
about how to do that.
I’m agnostic on timer vs. elapsed-time update thinning. Both are easy enough to
do, once you figure out *where* to do them.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden