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
Den 22:58 1. mars 2012 skrev Quincey Morris
følgende:
> You can *try* dealloc voodoo, but I think it's crucial to look at the
> observerInfo in the debugger. And, the number of remaining observers may be
> more informative than what they are.
Hi
Sorry it took a little while to get back to you.
On Mar 1, 2012, at 13:23 , Per Bull Holmen wrote:
> OK. I haven't thought of KVO-compliance at the level
> because no values can change at this level. Only the controller's
> parameterInfo property can change, by replacing it. That's what I
> meant by calling the parameterInfo object immutable. N
Den 21:42 1. mars 2012 skrev Quincey Morris
følgende:
> No, it's nothing to do with the mutability of the parameterInfo object.
>
> The problem is likely caused by lack of KVO compliance of your key path
> either at the or the level, or both. I think
> the console message suggests a place to se
On Mar 1, 2012, at 11:26 , Per Bull Holmen wrote:
> parameterInfo..
>
> "parameterInfo" is a literal key name, maps to a
> parameter in a plug-in, and must be resolved at run-time.
> is one of several attribute names, such as "minValue",
> "maxValue" etc. There is a value object that represent
On Mar 1, 2012, at 12:26 PM, Per Bull Holmen wrote:
> In my current project I have a controller object, that the view can
> bind to, with the following key path:
>
> parameterInfo..
>
> "parameterInfo" is a literal key name, maps to a
> parameter in a plug-in, and must be resolved at run-time.
Hi
In my current project I have a controller object, that the view can
bind to, with the following key path:
parameterInfo..
"parameterInfo" is a literal key name, maps to a
parameter in a plug-in, and must be resolved at run-time.
is one of several attribute names, such as "minValue",
"maxVal
On 19/08/2008, at 10:16 AM, Graham Cox wrote:
The point is that observees should not know or care about their
observers. Once you stop trying to let observees control their
observers your problems will ease considerably. Instead, observers
are entirely responsible for their own actions - o
On 19 Aug 2008, at 4:23 am, Ryan Brown wrote:
What is the best way to remove a KVO observer if you aren't sure if
the object already has an observer registered?
The right answer is to avoid this unsureness (is that a word?).
When I first started using KVO I too thought you could unregister
What is the best way to remove a KVO observer if you aren't sure if
the object already has an observer registered? Currently I'm catching
the exception raised for an unregistered observer using something like:
@try { [object removeObserver:observerObject forKeyPath:keyPath]; }
@catch(NSExcept
21 matches
Mail list logo
