Hi Rocky.
In this blog post you mention:
"The most resource-intensive feature is the ability to undo changes to
an object graph, because that triggers a snapshot of the object graph
– obviously consuming memory. Fortunately this feature is entirely
optional, and on the phone it is not clear you’d implement the type of
Cancel button this feature is designed to support. Fortunately, if you
don’t use this feature then it doesn’t consume resources."
I just want to get some clarity here on how to "not use" this feature.
Your statement gives the impression that the undo operation
(CancelEdit) is what triggers the consumption of memory. I've always
been under the impression that it's actually the call to "BeginEdit"
that triggers the consumption of memory (because that's what takes the
snapshot of the objectgraph), and then if I call CancelEdit, that
snapshot is used to restore the object state, or if I happen to call
EndEdit then that snapshot is discarded.
So in my understanding, for me to "not use" this undo feature, the
action I would have to (not) take is to never call "BeginEdit". (If
my understanding is wrong, I'd appreciate your input on this.)
This brings me to databinding though. I understand that with proper
CSLA databinding in a Windows App, the BeginEdit is called
automatically. Am I right in saying then that when using proper CSLA
databinding in a windows app you can't "not use" the undo feature in
an attempt to save memory usage?
How does this translate to using databinding in a XAML(specifically
WP7) environment? Does the same logic hold true, that you can't have
Databinding without BeginEdit being called?
It is true that the cost comes mostly with BeginEdit, but CancelEdit is far from free. ApplyEdit is basically free, since it just discards the state off the stack.
It is also true that Windows Forms data binding uses this by default, and it is difficult to avoid using it with that technology.
WPF and Silverlight (and therefore WP7) generally don't use it by default, though CslaDataProvider and ViewModelBase do use it by default. Of course you can tell those controls not to manage the object's lifetime (ManageObjectLifetime = false in the constructor or as a property value) and they won't use it either.
The only place where WPF/SL will use this by default is with datagrid controls that use IEditableObject when you do in-place editing in a row. That's really unavoidable, since it is necessary for proper datagrid behavior.
I'm not aware of any datagrid controls for WP7 though, so that scenario shouldn't occur :)
I must say that I am considering making some changes to 4.1 for WP7, including:
I've received very little feedback on the 4.1 beta thus far, so I haven't revved it to Beta 2 - I'll probably do that at the end of next week when I get back from VS Live Orlando.
Thanks Rocky.
I think it does affirm my point that a developer should know that thinking "I'll save memory in my SL/WP7 app by making sure I never use the undo feature", is NOT just a case of making sure to not call the BeginEdit/CancelEdit in code, but is a case of properly thinking about the GUI/Databinding, to ensure those calls don't happen automatically.
Thanks for a great framework.
--S
Copyright (c) Marimer LLC