OK, I understand. That was an exemple. The 100+ variables are spread on four 
Instruments. So I call 4 updateUI functions sequentially. There is no 
difference with having everything in a single function.

Since I chose to use bindings directly on the instruments properties for this 
project (not very elegant), I have indeed a strong coupling between the view 
and the instruments. Initially, the UI was designed for the instruments (the 
model isn’t flexible and the App will run for two years before being thrown 
away…). So I tied the UI directly to the instrument’s properties. That was a 
little to fast to be good and updates did occur from background threads. Having 
intermediary variables and updating the UI in one shot from the main thread 
every second was the quickest option to get everything up and running again… 
but then the app started eating memory like crazy.

I could spend time decoupling the view from the instruments, but at some point 
I would still have to update the UI and I get back the memory issues.
These, which were qualified by others as “long standing bug in appkit” are now 
solved by the hack described before.

I am still interested in understanding what happens with CA Layers in the 
kernel.



> On 17 sept. 2015, at 16:34, Gary L. Wade <garyw...@desisoftsystems.com> wrote:
> 
> Yes, I saw that code, but it only set a single variable and appeared to only 
> be associated with a single instrument. If you have 100+ instruments, that 
> would be 100+ separate updates. You know your code better than I and may be 
> simplifying things for us, but I've seen cases sounding very much like yours 
> where bindings is not the right solution. From how I read this, you are 
> tightly coupling your view to your model. Consider decoupling your 
> view-updating code like I suggested and you should see a significant change 
> without a hack.
> --
> Gary L. Wade (Sent from my iPad)
> http://www.garywade.com/
> 
>> On Sep 17, 2015, at 7:00 AM, Jean Suisse <jean.li...@gmail.com> wrote:
>> 
>> Thanks. But I already have one single timer dispatch source that updates all 
>> the UI only by transferring double / int values from instance variables to 
>> bound properties. The timer fires every second and causes the whole 100+ 
>> fields to be updated. This, however, does not prevent KVO to operate for 
>> each setter being called.
>> More information in my first post where you can see the implementation of 
>> the timer dispatch source and of the updateUI functions and in a previous 
>> e-mail I sent today. Data format varies based on the data being displayed (I 
>> use the formatters to display the correct physical unit for each 
>> measurement).


_______________________________________________

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to