iOS Edit Detail View Question

[ArtOfWarfare]

I have a mutable array of detail objects and a UICollectionView populated with cells representing them. When you tap on a cell, it bring up a detail view on that object with a few options you can change about the object. It also includes three buttons, each of which should dismiss the detail view:

- Cancel
- Done
- Delete

If the cancel button is pressed, any changes the user made to the object should be discarded and it'll be if the user never brought up the detail view.
If the done button is pressed, any changes the user made to the object should be made permanent.
If the delete button is pressed, the object should be removed from the array.

Here's my actual question: should the detail view edit the object itself, or a duplicate of the object… or something else? If it's working on a duplicate of the object, that would require the main view to keep track of the index of the selected object, so that it can remove the object if it's deleted, or it can replace the object if the done button is pressed. If it's working on the actual object, that means somewhere the original state of the object will need to be preserved so that any edits can be rolled back.

Neither of the options seem right to me. I feel like there's some better option that hasn't come to me. Which option would you use? I'm reluctant to use Core Data just because it seems like it tends to make things much more complicated than necessary… I'm not dealing with many objects… I expect the array will have perhaps a dozen objects in it at most… most users will probably only have 4 or so.

 

[MattInOz]

What about an Undo Manager?

Start a new pool of undo events with your detailView, if the user hits cancel then the undo manager reverts your object to the state it arrived in. Bonus being your user could undo part edits in while in the detailView.

 

[ArtOfWarfare]

What about an Undo Manager?

Start a new pool of undo events with your detailView, if the user hits cancel then the undo manager reverts your object to the state it arrived in. Bonus being your user could undo part edits in while in the detailView.

Hmm... okay. I've never used an undo manager before but there's no time like the present to learn, right? I looked at this tutorial and I think I get the idea for how this works:

http://mobileorchard.com/new-in-iphone-30-tutorial-series-part-1-shake-to-undoredo-nsundomanager/

So rather than a shake to undo, I'll just have it it undo everything on the undo stack when the cancel button is pressed.

 

[Duncan C]

You could use the undo manager as the other poster suggested, but this seems overly complex for this simple case.

I recently implemented an editor screen similar to what you described.

Here's what I would do:

Pass a pointer to the original array to the detail view controller, along with the index of the object to edit.

Make a copy of the object. If the user presses cancel, simply discard the changed object.

If the user presses save, replace the object in the array with the edited object and send a message to the list view controller to update that object.

If the user presses delete, send a delete message to the list controller with the index to delete. Let the list controller handle the delete.

I have a mutable array of detail objects and a UICollectionView populated with cells representing them. When you tap on a cell, it bring up a detail view on that object with a few options you can change about the object. It also includes three buttons, each of which should dismiss the detail view:

- Cancel
- Done
- Delete

If the cancel button is pressed, any changes the user made to the object should be discarded and it'll be if the user never brought up the detail view.
If the done button is pressed, any changes the user made to the object should be made permanent.
If the delete button is pressed, the object should be removed from the array.

Here's my actual question: should the detail view edit the object itself, or a duplicate of the object… or something else? If it's working on a duplicate of the object, that would require the main view to keep track of the index of the selected object, so that it can remove the object if it's deleted, or it can replace the object if the done button is pressed. If it's working on the actual object, that means somewhere the original state of the object will need to be preserved so that any edits can be rolled back.

Neither of the options seem right to me. I feel like there's some better option that hasn't come to me. Which option would you use? I'm reluctant to use Core Data just because it seems like it tends to make things much more complicated than necessary… I'm not dealing with many objects… I expect the array will have perhaps a dozen objects in it at most… most users will probably only have 4 or so.

 

[TheWatchfulOne]

I'm reluctant to use Core Data just because it seems like it tends to make things much more complicated than necessary… I'm not dealing with many objects… I expect the array will have perhaps a dozen objects in it at most… most users will probably only have 4 or so.

If you are not using Core Data, then may I ask what you are using?

In my current app project, I'm using SQLite. I do like Core Data, but right now I'm perfectly comfortable writing SQL statements and so far I've been able to make it do everything I want. In the future I still want to get "into" Core Data.

And here is how I would make my data entry/editing view work:

All controls on the view would be "unbound". That is, if you have a bunch of text boxes where the user enters text, then as you move the focus from text box to text box, changes don't get written to the database yet. You could store the new data in a temporary object that gets written to NSUserDefaults so that if you receive a memory warning and/or your app crashes than when the user returns to the view they don't have to enter their data all over again.

When the user presses "Cancel" simply dismiss the view. There shouldn't be anything to undo because there shouldn't have been any changes written to the database.

When the user presses "Done" that's when changes are written to the database.

When you push the view, check for that temporary object and populate your view with that data. When you pop the view by pressing "Done" or "Cancel" then remove the temp object from NSUserDefaults.

And that's my two cents.

 

[ArtOfWarfare]

If you are not using Core Data, then may I ask what you are using?

In my current app project, I'm using SQLite. I do like Core Data, but right now I'm perfectly comfortable writing SQL statements and so far I've been able to make it do everything I want. In the future I still want to get "into" Core Data.

Just plain old objects with properties. I don't have many objects and they don't have many properties, so it'd be overkill to use anything like SQL or Core Data.