I'm not sure if this has already been suggested:
What if you don't update the UI unless the change is at least 1 sec or
1% or certain amount of bytes (whatever suits your needs better)?
Leo
On 1/15/12 12:33:31 AM, Andrew wrote:
Thank you all for the opinions. I left the code as-is in terms of
binding, but changed my rate calculations to use a weighted running
average. After doing so, the estimated seconds tick by one at a time
for the most part, and the rate is more constant. This is a tool for
me and some co-workers, so at this point, it is good enough. But the
ideas are sound and if it bothers me enough, I may decouple the UI
from the model by not using bindings at some point and use a timer
based approach.
On Sat, Jan 14, 2012 at 10:37 AM, Kyle Sluder<kyle.slu...@gmail.com> wrote:
On Jan 14, 2012, at 2:53 AM, Marcel Weiher<marcel.wei...@gmail.com> wrote:
Hi Andrew,
On Jan 13, 2012, at 6:57 , Andrew wrote:
The result of this is that the UI updates really frequently and the
estimated time to complete and the download rate jump around a lot. I
would love it if I could tell cocoa to only update the UI once per
second instead of immediately when the property key changes.
You shouldn't push updates to the UI, the UI should query the model, and it should do it
at "human speed", not at whatever speed the machine can manage to change the
state. There are a bunch of reasons for this, not least is that UI updating is fairly
heavyweight and you can actually impact your performance (significantly, in some cases).
Be careful here. This is good advice in this particular circumstance, but in
general pushing values to the UI is good and common design. The UI will
register as a KVO observer, or as an NSNotification observer, or perhaps the
controller will just call -setObjectValue: directly.
Breaking this pattern should be a conscious decision. For example, you don't
push a value to cell-based NSTableViews; you tell the table view it needs to
ask you for the values at certain indexes. This is because cell-based table
views are an optimization that avoids keeping tons of view objects around.
But view-based table views behave just like any other view: you push updates
directly to the controls contained within your table cell view.
In Andrew's case, it's clear that he should deviate from the norm, and the UI
should be in charge of asking for the latest value at a rate that makes sense,
probably controlled by an NSTimer.
--Kyle Sluder
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/leo.r%40rogers.com
This email sent to le...@rogers.com
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
