Hello all,
Time to bring back the topic, on the immutability vs mutable issue for
memory (an especially plist) storage.
read method should return an immutable object. Make it all immutable will
help consistency.
thoughts?
++
Corinne
On 25 Nov 2013, at 23:41, Corinne Krych <corinnekrych(a)gmail.com> wrote:
I see actually 2 correlated problems in the described use case:
1. Immutability. [store readAll] return a mutable object I can then modify
without using 'save' method. In Objective-C, mutability is a strong concept
[1].
But then immutability is not well supported in all languages...
unmodifedCollection in Java not quite the same than immutable.
I see 2 options:
a) make slight API changes to cater both way like:
void save(T item)
could be replaced by
T save(T item)
b) change only iOS implementation and accept slight differences as each
language idiomatic
2. PList Storage dump the whole content of memory storage in one file
whether you go for save one element or save all element. But if we have
immutability then it wouldn't be such a problem.
++
Corinne
[1]
https://developer.apple.com/library/mac/documentation/general/conceptual/...
On 25 November 2013 22:17, Christos Vasilakis <cvasilak(a)gmail.com> wrote:
This effect is most visible in the Memory storage implementations, since
the mutable objects returned can be modified without the user asks for an
explicitly 'save' operation. In the scenario described, regardless if you
did save or not, a later 'read' operation on the store, would have returned
a possible modified object (done outside the store periphery).
Other store types (aka SQL) don't suffer from this, since all read
operations request the last state from permanent store.
It all comes to this:
a 'read' operation on a store _must_ guarantee to return the state of an
object previously 'saved'. If the memory storage implementation fails on
it, then 'read' should be fixed using each platform mutability semantics.
If not mistaken, I believe this effect of mem storage is exhibited on our
other platforms too.
-
Christos
On Nov 25, 2013, at 3:24 PM, Corinne Krych
<corinnekrych(a)gmail.com> wrote:
Hello Guys,
Using AGPropertyListStorage in Xmas app [1], I run into this interesting
issue:
In the app I retrieve a NSArray of NSMutableDictionary, I get a mutable
copy of the
NSArray and I save encrypted data in it
I decrypt some of the data in memory BUT I actually don't want
those to
be saved decrypted into permanent storage.
And then let's say I add some more data with encrypted value then
I save
this dato to my AGProperListStorage. Just this one.
But surprise, if I look in my permenet storage, I see my newly data
encrypted but the other data I ecrypted in memory were saved decrypted
What happened?
In one word: shallow mutable copy of NSArray.
My mutable array still point to original MSMutableDictionary and when
saving one
data to permanent storage the all memory is dumped into plist
resulting in decrypted value to be stored.
How did I fixed it?
Using deep mutable copy see in [2].
In AGMemoryStorage (and its inherited AGPropertyListStorage) we use
NSMutableDictionary because you can save item (represented as Key/Value
with NSMutableDictionary) without id, the store will take care of
generating this id and assign it back into the item.
Even the AGMemoryStorage which returns a NSArray of NSMutableDictionary
is
misleading because you can actually do
NSArray myArray = [store reallAll]
and then modify the contain of the memory storage without using save.
That experience brings the topic whether it's a good pratice to use
mutable
object
Options
- option1: stick to immutable objects whithin the AGStore and let the
save method
return an immutable NSDictinary containing the item
- option2: leave it as it is, responsability of user to do deep copy
- others ?
Personal Preference go for option1 which I found less confusing.
++
Corinne
[1]
https://github.com/corinnekrych/aerogear-ios-cookbook/blob/master/Xmas/Xm...
[2]
https://github.com/corinnekrych/aerogear-ios-cookbook/blob/master/Xmas/Xm...
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev