Deleting or moving rows for a UITableView that is backed with local data (e.g., NSArray) is easy and instantaneous:
Remove the value from the array.
Call deleteRowsAtIndexPaths:withRowAnimation:.
Profit!
But my table view communicates with a web service, which means once the "Delete" button on that row gets tapped, I have to forward a request on to the server (via ASIHTTPRequest, of course), get the response, and then tell the table view to run its little delete-row animation, all with a few seconds of latency in between.
From a high-level, what's the best way to do that? Throw some callback selector into ASIHTTPRequest's userInfo dictionary? KVO?
Bonus points for some nice UI touch, like some kind of spinner on the soon-to-be-deleted cell.
The most elegant way I know of is to use Core Data for the local data, and to have your UITableView listening for change notifications from the Core Data store. This maintains model/view separation, and yet you can still get the eye candy of a row-deletion animation. It goes like this:
User says to delete a row.
Your code sends off an ASIHTTPRequest, and registers a selector to be called back when the request succeeds.
When it's done, the callback selector modifies the model that is in your Core Data store.
This automatically causes your UITableView to be notified that a row was deleted, so it can animate the deletion of the row.
This doesn't get the bonus points, because it doesn't give you any sort of UI indication that the cell will be deleted soon. One thing I've considered doing sometimes, but haven't been brave enough to try, is to optimistically code things on the assumption that the web-service call will almost certainly succeed, so go ahead and delete the row immediately, before the ASIHTTPRequest indicates success/failure; but then, if it does fail, roll back, and make the row re-appear. This has the advantage of making the app much faster in the common case where the web-service call succeeds. Core Data gives you a couple of ways to do this kind of "roll-back" stuff, but still, it definitely gets tricky, so it may not be worth it.
If you don't want to use Core Data, then to me KVO is the second-best solution.
EDIT: Thinking about it a bit more, in order to get a visual indicator that the row is about to be deleted, your Core Data model could have a flag on each row, "markedForDeletion" or something; when you fire off the ASIHTTPRequest, you would also modify the model to set markedForDeletion to true. The UITableView would be notified of the change (because it has registered for notifications); so it would then do whatever UI you want on top of the row, e.g. a spinner or something, to indicate that it's being deleted. Then, if the ASIHTTPRequest succeeds, it just deletes the row; but if it fails, it sets the rows "markedForDeletion" flag back to false, which causes the UITableView to turn off the spinner.
Related
I've got an NSTableViewDataSource/...Delegate backed by an array in my controller. Now, from time to time I'm going to update the array, but I'd like to make sure this doesn't happen while the UI is possibly refreshing what's displayed.
The trivial part is locking the list itself, so it doesn't get change while drawing each cell. But how do I lock it for the whole update cycle? (i.e. from getting the number of rows to finishing the current screen draw) Are there any pre/post update hooks I can use, or are there better ways to approach it?
I am attempting to run a database fetch process in the background without locking the user interface.
Currently I have a button that does this, but I would like it to be automatic so that it can get more results as user is browsing current results.
Here is the code that the button does, I would like to make this automatic and not lock the UI. Also if there is a way to pause the process, but continue where it left off if user goes to another screen that would also be very useful.
Thanks in advance!
-(IBAction)continueUpdatingResultsButtonPressed:(UIButton*)sender{
[findMoreButton removeFromSuperview];
[self continueFindingMoreRecipes]; //(do this in background without locking screen)
[self loadRefreshButton];//At completion load this button (a blinking button) to refresh the cells with new results
}
A typical pattern you can use is something like this:
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
// perform data processing here (done in the background)
dispatch_async(dispatch_get_main_queue(), ^{
// update user interface here (done on the main thread)
});
});
You could do batch requests where you cache the next X amount of answers every time your UI got with in Y of the current end. Depending on what you are using a lot of databases have protocols that can help you batch cache easily. Good luck!
Use grand central dispatch. Create a new queue, dispatch it with a block and when you need to update, call dispatch get main queue. There is no way to pause this once the queue has been dispatched though. Maybe load recipes into intermediary then update as needed.
Look for some gcd tutorials there are a few decent ones there.
Would give you more code but I'm typing on iPhone.
It strikes me (especially since you are, by your own admission, "very new to programming") that it might not be prudent to pursue GCD to prefetch data in a background queue, make sure you coordinate the background queue's database operations with the foreground's database operations (possibly via something like FMDB's FMDatabaseQueue or something equivalent), gracefully handle pausing this operation as you go to other screens (as you indicated in your question) and making sure you don't cause retain cycles in the process.
To make matters worse, I gather that this is all in pursuit of a possibly questionable goal, if I understand you correctly, to retrieve 10,000 recipes in the background. Don't get me wrong. You certainly can design all of the background operations like we've outlined, but I think you should stop and ask yourself whether that's the right design for your business problem.
I might suggest an infinitely easier solution. Just load your tableview with the first x recipes, and as the user scrolls down, when you start to approach the end of the tableview, detect that fact and retrieve the next x records and add them to the tableview. But any user interface that is expecting the user to flip through 10,000 entries doesn't pass the smell test. When I think of a database with 10,000 entries, I think of something more like a imdb/wikipedia/google/facebook-like user interface rather than a contacts-style user interface.
Regardless, you almost certainly don't want your app just endlessly retrieving recipes in the background. You can solve your UI performance issue, but maybe replace it with memory management issues. And you're going to design a complicated system architecture when it's not entirely clear whether your recipe app requires that.
I'm working on a real estate app. The app query a datafeed server after user fill in a form (min rooms, price and so on) and it gets a json string with specific key/value pairs (property name,property address,longitude/latitude,price,etc...).
What I'm trying to do is allowing the user to browse the listing in a UITableView even if the feed contains a long list of items without having to overload the user iphone (the returned items count is not known before the query is done, so the app need to handle this)...What would you suggest me for paging ?
Thx in advance,
Stephane
If your tableView:cellForRowAtIndexPath: method is written correctly using dequeueReusableCellWithIdentifier: (and you don't use tableView:heightForRowAtIndexPath:, or it is very fast), UITableView should be able to handle thousands of rows without overloading the device. You just need to be concerned with the storage of your raw data.
As for your problem of not knowing the number of rows until the query is complete, that is easy enough to work around. As you receive more rows from the query, just use UITableView's insertRowsAtIndexPaths:withRowAnimation: to inform the table view that more rows are available (and be sure that your tableView:numberOfRowsInSection: and tableView:cellForRowAtIndexPath: will then reflect these new rows).
If you are also wanting to wait until the user scrolls to the end of the current list before continuing the query, note that UITableView is a subclass of UIScrollView and UITableViewDelegate implements UIScrollViewDelegate. So just use scrollViewDidScroll: on your UITableViewDelegate to know when the user scrolls and then check the table view's contentOffset to determine if they've scrolled down far enough that you want to load more data.
whats the average number of items people can have? 10, 100, 1000? Does it have images or just data? Generally, I'd vote for not having any pagination - just load more as you scroll down, and try to load all of them at the very first time if there are not too many. You can also cache them on the device and add "pull to refresh" functionality, this way you improve offline experience.
Well if some one is interested in paging using buttons then I found this post usefull http://www.mindyourcode.com/ios/iphone/pagination-in-uitableview-with-next-previous-buttons/
may be for some others it would be helpful
I have implemented a client for a paginated REST service where I populate the whole table with empty entries and then load them in the background using pagination when the user starts scrolling the table.
This seems to work very well except for a little detail: I am calling reloadRowsAtIndexPaths: in the main UI thread (because UIKit requires so), and I feel the animation sometimes makes me lose input touches.
This is, the user starts scrolling through the list and items start to load. Sometimes a reload animation happens at the same time the user is just touching the screen again, and this touch is not recognized. The scrolling then doesn't continue and stops. It doesn't happen all the time, and I guess it is an infrequent user case (the user is expected to read each row of results before scrolling down) but it annoys me to no end.
I'm doing most of my animations with blocks and the flag UIViewAnimationOptionAllowUserInteraction is really helpful, so is there a block version of reloadRowsAtIndexPaths where the reload animation would not block the user interaction with the scrolling?
I think the solution you seek is to background-load your data in a thread (as you describe) and only call reloadRowsAtIndexPaths: once the data is received and ready to display. You should also probably redisplay the data NOT animated.
I don't think there's anything you can do to get around the missed touches with your current scheme. My suggestion is to "do what iOS wants" rather than "try to cajole iOS to do what you want." Yes, probably not the answer you wanted to hear, but I think that's just the way it works.
(Btw, you can always use bugreporter.apple.com to make an enhancement request! :)
I am developing an iOS application and am having some issues deciding how to approach a problem.
I am using two UITableViewControllers to display different views of the same data. One is a master list, and the other only contains items which are marked as "favourite". Also the items are variable height, so I am using "heightForRowAtIndexPath" to indicate the height for each item. The problem is speed, when I switch from one view to another, it needs to be updated to display the changes made in the other (marked favourite/unfavourite).
Solution #1:
Reload the data each time a table view becomes visible. This does not work nicely because although the data is display using lazy loading, the "heightForRowAtIndexPath" is called for every item before ANY data is loaded, and its slow. on my iPhone 4 a list of about 300 items takes about four seconds to load, even if the height values are cached (the bottleneck is applying the height, not retrieving it).
Solution #2:
Manually manipulate the tables when changes are made. I have not tried this, but it would likely be buggy. Your thoughts?
Solution #3:
Using a notification type system to notify the other table of updates to items that might currently be loaded. I have not tried this, because it seems over the top and might not work at all.
Does anyone know of an easy way to show two views of the same data?
You can reload n rows with reloadRowsAtIndexPaths:withRowAnimation. I never did it, but I think it's there because it's faster, so you might want to try it out.
On the heightForRow: thingy, I can remember reading in the Apple docs that that function is indeed a killer for performance. Perhaps you could take the maximum height of the rows, and set that in the UITableView.rowHeight?