On 25/01/16 20:05, Markus Spoettl wrote:
By the way, you should consider implementing the observationInfo property on
your observed class. This avoids KVO storing observation info in a side
table. Note that the property is a void pointer, not an object pointer, and
therefore does no memory mana
On Jan 25, 2016, at 3:22 PM, Markus Spoettl wrote:
>
> Thanks for the suggestion and explanation, I would never have thought of
> using this.
You're welcome. I'm glad I could help.
> I wonder if there's a downside to implementing this in all my model objects
> other than adding an additional
On 25/01/16 17:31, Gary L. Wade wrote:
You should look more at your design. Having that many objects being
unobserved and reobserved (your word although in the context of new objects)
reminds me of what I've called a genocidal refresh, an antipattern that can
be fixed by only refreshing (or in yo
On 25/01/16 18:34, Quincey Morris wrote:
On Jan 25, 2016, at 01:10 , Markus Spoettl mailto:ms_li...@shiftoption.com>> wrote:
Has anyone any idea how the removing of observers can cause this kind of death
spiral?
Genocidal refreshes aside, are you absolutely sure that you’re always
removing/ad
On 25/01/16 20:23, Ken Thomases wrote:
This is interesting. When I implement this property in the proxy object,
the problem goes away (at least I wasn't able to duplicate it so far). Turn
off the implementation, it comes back. Not really sure what this tells me,
though.
Implementing the propert
On Jan 25, 2016, at 1:05 PM, Markus Spoettl wrote:
>
> When I break in the debugger I end up in various different library functions
> concerned with hash tables and the like, such as
>
> #00x7fff9ddc6d03 in weak_entry_for_referent(weak_table_t*,
> objc_object*) ()
> #10x7fff9dd
On 25/01/16 18:47, Ken Thomases wrote:
When the array changes, I remove all observers from these objects before
re-observing the new objects.
If at all possible, you should do this in a more targeted fashion. Add and
remove observers only from the objects which were actually added or removed
f
On Jan 25, 2016, at 3:10 AM, Markus Spoettl wrote:
>
> I have a view controller with a table view that is bound to an array
> containing around 1000-1 model objects. The same view controller
> registers itself as observer of all the objects' properties. These objects
> are actually proxie
On Jan 25, 2016, at 01:10 , Markus Spoettl wrote:
>
> Has anyone any idea how the removing of observers can cause this kind of
> death spiral?
Genocidal refreshes aside, are you absolutely sure that you’re always
removing/adding observers on an appropriate thread? There are two dangers here:
> On Jan 25, 2016, at 2:10 AM, Markus Spoettl wrote:
>
> Sometimes (on El Capitan) this removing of observers causes my app to freeze
> and eat memory at an alarming rate. Sometimes this spirals completely out of
> control until all memory is exhausted, sometimes it stops after a few
> gigaby
You should look more at your design. Having that many objects being unobserved
and reobserved (your word although in the context of new objects) reminds me of
what I've called a genocidal refresh, an antipattern that can be fixed by only
refreshing (or in your case observing) the things actually
Hi,
I have a view controller with a table view that is bound to an array
containing around 1000-1 model objects. The same view controller registers
itself as observer of all the objects' properties. These objects are actually
proxies for other model objects and are created by my view con
12 matches
Mail list logo
