I have a workflow in my app where the user will build a compound filter and then press a button to view the results of the filter.
In the screen that builds the filter they get to select from a list of fields and set what the value should be. There is also a UILabel that shows how many results match the currently selected filter.
I use an NSFetchedResultsController to make it easier to get the count and change the predicates etc...
When the user presses "Next" (or whatever the button is labelled) they will then view a TableView with those results in it.
Is it bad practise to pass the NSFetchedResultsController in to the tableViewController?
Or should I just pass the information required to build a new NSFetchedResultsController (i.e. the NSPredicate).
I can do either just not sure if there are any pros/cons of either method?
NSFetchedResultsController has a delegate on it. You will have to assign a new delegate when passing the NSFetchedResultsController, and you will have to assign the delegate again when removing the view controller you presented base on the pressing of that button. Keep also in mind that when you are changing the predicate of the NSFetchedResultsController's fetch request, you are performing another fetch. Basically, you are complicating your architecture while gaining basically nothing. Create a new NSFetchedResultsController object.
NSFetchedResultsController is really what u need for tableView.
Related
I'm a little confused as to how I should be using didSelectRowAtIndexPath.
Without using datasources (keeping things simple),if you display a list of names with UITableView and all you want to do is select a name and return it to whatever parent view controller created the UITableView list.. what would you do?
I'm used to Windows MFC programming where you have a dialog class and you call DoModal() to display the dialog and then query member variables of that dialog object to get the results.. With iPhone programming I'm confused with the whole paradigm. I push the UITableView into action, but at what point should I try and retrieve the results? pushViewController is asynchronous in nature isn't it? So I can't expect to retrieve results on the line immediately following the pushViewController method?
I'm using NSMutableArrays of NSStrings to keep things simple.
The patter you are going to use is called delegation, what happens is that you call the new ViewController and let it do its work, the function that called this will return normally,
Now you need to implement didSelectRowAtIndexPath and get the selectedRow, after this you will need to return the selected index or value to the original view controller( this will be recieved in another function) please read more about #protocol and delegateion
iPhone forms, where do you put your validation?
People suggested me to directly put the value of my textfields in my core data entity, which I did (see my second edit). Thing is, when a person update an entity, since I put directly the value that the user is typing in my entity, even when I don't save my ManagedObjectContext, my TableViewController (using NSFRC) updates with the latest infos the user entered (even if he pressed cancel). If I restart the app, since it didnt save, everything is back to normal.
How can I avoid this?
I'm assuming you are using the same NSManagedObjectContext for both viewControllers. You could use a separate NSManagedObjectContext for each viewController. If you are using iOS 5.1 set the 1st viewController's managedObjectContext (MOC) as the parent of the 2nd viewControllers managedObjectContext. So if you save the 2nd view's MOC via [theContext save], it will merge the changes with the 1st MOC automagically. If you don't want to keep the changes simply pop that view off the navigation stack.
MOC's are scratchpads. So in essence you want to use that 2nd viewController as a scratch pad, until you hit save.
I've been expanding my horizons recently and am trying to start utilizing KVO more in my programming.
I have a view controller in my iPhone application which acts as the datasource and delegate for a UITableView. I also have a singleton model controller which coordinates populating my model with data fetched from the web.
In my view controller, I request that the model's controller load new data from the web. Then I can observe the "dataset" property of the singleton and receive KVO notifications when items are added to or removed from the set.
Now, each cell in my table view has an indicator which specifies whether the content in that cell has been read or not (like the blue "unread" dot in mail). Like mail, when a row is selected, I'll display details about that row. In the viewDidLoad for the detail view, I set the object's "read" property to YES. I would like the original view controller to be able to observe this "read" property of each object in the dataset, so that [tableView reloadData] can automatically be called as necessary and redraw the cells without the blue dot.
In researching this, I found the following link: http://homepage.mac.com/mmalc/CocoaExamples/controllers.html#observingACollection
According to this, it looks like I will do the following:
1) Be an observer of the array
2) Whenever I get a notification of a change to the array, I add (or remove) myself as an observer for the individual properties I am interested in.
3) When I get a notification of a change to the property I'm interested in, I can call [tableView reloadData]
I'm currently in the process of attempting to implement this approach. Can anyone with experience doing this offer some advice on this approach? If this the best way to handle this type of situation?
If this is the correct approach, would anyone be willing to share their implementation of adding/removing the observers for objects in the collection when the collection changes?
Thanks!
I think you can accomplish this task by using Core Data and the Fetched Results Controller.
I'm sure this can save you a lot of work.
Here's a good guide: Ray Wenderlich Core Data Tutorial, getting started
I have an NSManagedObject with attributes that a user can edit with a view. The view is populated with the values from the object, the user can edit the values, and the values are written back to the object. I want the user to explicitly tap a save or cancel button to commit or undo the changes.
The problem is that the view is in a UITabbarController where other things are going on. The user might perform operations in another tab where [NSManagedObjectContext save] or [NSManagedObjectContext undo] might get called. This would affect the NSManagedObject (from the first mentioned tab) before the user decides if they want to save or cancel it.
Is there a way around this? Can we temporarily disable persistence on an NSManagedObject until the user taps the button?
There is no way to disable persistence for a managed object. Instead I would recommend an approach like this:
Typically, when showing a view that edits a particular object, you update that view with the data from the object in the viewWillAppear: method and update the object with the changed data in a corresponding "save" action or viewWillDisappear:.
Whenever i make a change in the objects in the first tab of my application the updates are automatically upated in tab 2 becuase it uses a fetchedResultsController. Now i have a third tab that should also update itself, but how can i do that?
I only have a nsmangedObjectContext in the third tab to get the appropriate data. How can i receive notifications whenever the objects in this context change?
I am also struggeling with the question how i can make my data fetching more efficient, becuase tab 2 and 3 use the same set of data. I am currently making another fetch in tab 3, to get the same data as tab 2. I dont know how i can use the data from tab2 without disturbing the fetchedresultscontroller.
Information on this subject would really be appreciated!!
If your tableviews are very closely related, then you can just have a single UITableViewDataSource that provides data for both of them, and have it manage the NSFetchedResultsController. From your description, this case seems very likely.
If the tableviews are not very similar, such that having a single UITableViewDataSource would create excessive if() logic, then move your NSFetchedResultsController into an separate model object and post NSNotifications when it receives delegate call-backs. Your UITableViewDataSources can then observe those notifications to update themselves when they are on-screen.