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/CocoaEncyclopedia/ObjectMutability/ObjectMutability.html

On 25 November 2013 22:17, Christos Vasilakis <cvasilak@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@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/Xmas.md
> [2] https://github.com/corinnekrych/aerogear-ios-cookbook/blob/master/Xmas/Xmas/Classes/Controller/AGGiftListCollectionViewController.m#L66

> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev