For example, there is a ViewModel that has
a collection of objects requested from a Service
an Add command to create and add new objects
a Delete command to delete selected objects
The User creates, adds and deletes objects by using corresponding commands.
How should ViewModel react on User's actions?
Should ViewModel immediately make a corresponding Service method call when the User invokes a command?
OR
Should ViewModel add / remove items from local collection, mark items as added / deleted and wait to make a Service method call only when the User invokes some Save / Apply changes button?
The second variant seems more complicated.
Does it give any performance / user experience benefit or enable any features that are not possible with the first variant?
In other words, is it better to keep ViewModel state as close to the Service / Database state as possible?
Related
In my app the problem is that user can edit an object, but if user pressed "Cancel" I need to discard changes, if there any method to make local copy of realm object without adding it to RealmBase, or I should do all the copies manually?
If your model doesn't have references to any other models or collection of objects, you can use this method to initialise new instance with values stored in Realm.
I have read a lot about the patterns of sharing data between views .
I know how to use delegates,and segues to pass data(iOS), but i want to share a more deep question.
Lets say i have some tasks app, and each new task the user create, is an instance of a class called Task, that holds all the data on that task(date,text,etc) .
Now when in viewA, that shows the tasks list in a table, a user push a button to create a new task, hence has to create an object of Task class.
Than i take the user to viewB to edit the task, and maybe later to viewC .
A few options are possible, but for each i find some inconvenience.
viewA's controller is creating the Task new object,and pass it to b, than b to c, etc.
viewB's controller is creating the Task new object,than post a delegate to A,with task
It seems that the right option is 1 , but it has some problems such as that after view controller B edit the task, viewA's controller needs to reload the table with that new task- anyway, than, option 2, posting a delegate from b, seems more simple,so b is creating a Task object, than post delegate to the table in A to save it and also to reload the table with it .
Here the data is less capsulated .
Maybe i am completely wrong ,but i really try to understand how things should be done right .
Any thought will be helpful to me.
Or you could create a data model.
Consider having a TaskManager class that manages the list of tasks, creates them, and knows which one is currently selected (or most newly created). Either your TaskManager can be a singleton or can be accessed via your app delegate. Anything that needs to be done with a Task, the TaskManager handles.
That way, you make your view controllers more independent because they don't talk to each other but read and update the current state of the data model from the object that's responsible for it.
I have a core data 'ShoppingList' which contains 'Item' objects. I store a display order as an attribute of each item.
I would like to update the display order of all other items in the shopping list whenever an item is deleted. The code to do this is working fine when I use it in my view controller (from where the item is deleted), but since it is really related to the business objects and not the view, it would be better placed in either ShoppingList or Item.
Ideally, I would like it incorporated into the deletion of the item. So far I have tried the following:
1) Customize the standard Core Data generated ShoppingList.RemoveItemsObject (making sure to observe KVO before.after). What's strange about this way is that the item passed is stripped of its relationships to other core data entities before it gets to my code, which I need to process display orders correctly.
2) Customize Item.didTurnIntoFault. Same applies - but even attributes of the item are gone by this stage.
One answer would be to simply define a new method on ShoppingList that does my processing and then calls the original removeItemsObject. But I would prefer to know that whenever an item is removed, from anywhere, this is taken care of. This works nicely when I customize awakeFromInsert, for example - I know that whenever an item is created certain things are setup for me. But I'm surprised there's no equivalent for deletion.
Did you try to implement prepareForDeletion? Sounds like it's exactly what you're looking for.
The doc says:
You can implement this method to perform any operations required before the object is deleted, such as custom propagation before relationships are torn down, or reconfiguration of objects using key-value observing.
I'm using a sheet to ask the user some information for an operation that the application performs. The sheet has some 10 to 15 options (split into 4 tabs, so its a relatively clean UI) that the rest of the program needs to know before proceeding.
Right now, I have a separate window controller class for the sheet called SheetController. SheetController has a delegate property and the main controller, AppController, is set as the delegate.
When the user clicks OK in the sheet the delegate is notified and a method called didClickDone:(id)sender withParameters:(id)parameters is executed. parameter is a object that contains various properties from the sheet. My question is, is this a good approach to handling Sheets and returning data from them?
Secondly, one thing that bothers me is that the parameter is just a dead object - it only has accessor methods. It doesn't do any manipulation on them as its entire purpose is to 'carry' the data to the main controller, which in turn passes the information to the Model of the program. And, unless I'm missing something, shouldn't I just declare parameter to be a normal C struct? Or is there an advantage of using an object for this sort of purpose?
EDIT: Would a passing an NSDictionary be a good compromise? I could save the returned information with their keys in the dictionary and simply pass it.
Maybe I would not notify directly the controller from the push button event handler but
call another routine that encapsualates the logic on how the data have to be commited to the model.
Don't worry about the empty object. Is a common pattern to use it and is called DataTransferObject
a datacontext defined in a module(domain services ado.net ria)
a page having add/delete methods
whenever any method is executed, it is found that all the previous actions (NEW RECORD ADDITION and DELETION OF RECORDS) are carried out before the new action is carried out
normally
this behaviour is not prominent but
"when using break points and inspecting the values of the variables and table object to be added to context, it is clear that all the previous actions take place again.
edit
even when the datacotext. savechanges is called, even after that still all actions carried out on the datacontext repeat themseleves, when any new action is to be carried out
got the problem
was creating a new instance of the usercontrol every time, therefore all the instances did there work when asked to add record to context....
solution
just declare the instance of the usercontrol once in the constructor of the main page.
then use that declaration where ever needed.