Re: Best practice with NSProgressIndicator
Re: Best practice with NSProgressIndicator
- Subject: Re: Best practice with NSProgressIndicator
- From: Mark Allan <email@hidden>
- Date: Fri, 28 Jul 2017 22:16:59 +0100
Many thanks for all the responses. In terms of what I'm doing, the NSTimer
with 0.1 second granularity sounds like the best fit.
> On 28 Jul 2017, at 7:26 pm, Charles Srstka <email@hidden> wrote:
>
> If you’re using Swift <snip>
Still on Objective-C. Thanks though, I'll keep that bookmarked for when I
venture into Swift!
> On 28 Jul 2017, at 6:57 pm, Quincey Morris
> <email@hidden> wrote:
>
> On Jul 28, 2017, at 08:57 , Mark Allan <email@hidden
> <mailto: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.
Apologies for the lack of detail/clarity - I simplified things for the sake of
keeping the email short.
The loop most definitely is not updating the progress bar directly. In fact,
the helper tool is a separate process, communicating via NSXPCConnection, so it
couldn't update it directly even if I wanted it to! Reducing the frequency of
NSXPC messages was a secondary goal to figuring out how often the main app
ought to be updating the UI.
Mark
_______________________________________________
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