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
Related
In my app I have a bit where the user can take a photo and it get dropped into a list and the user could technically forever keep adding photos.
So what is the best way of saving, storing and loading the photos the user takes? Taking into account, there could be hundreds. Also, loading them all in at once might not be a smart idea as well, but say have a scroll view, scroll down, and when hitting the bottom it could load say 20 more and then another 20, etc.
Any help, much appreciated, thanks.
Just decide where you want to store the photos, built-in photo library or apps documents folder or both (I'd go with photo library for users's convenience in watching, deleting, synchronizing etc.). If you choose documents folder, don't forget to support deleting ... Disk space is the users problem.
If you choose only to store in photos library and want access the photos later from within the app, you have to save the urls of the saved images. This answer tells you how it works.
Loading the photos in scroll view will need some optimization, i.e. it wouldn't be a good idea to load all photos in memory, but only the visible ones. As another answer says, the re-use of cell in UITableView could be a solution, but I think, UITableView is for the typical iPhone table, adjusting and customizing it and its UITableViewCells isn't worth it, if the only reason is memory usage.
I'd go with UIScrollView and react upon the delegate's methods to load new content and drop old one. If you want a non-paging UIScrollView you should use scrollViewDidScroll , which is fired really often, so maybe there will be need for another optimization - test it. A paging UIScrollView seems to be easier to me. Just react on scrollViewDidEndDecelerating for loading and dropping content.
Hope that helps.
use tableview, it will load it manages the memory and jst visible rows are loaded into memory if u use dequecell method
read tableview more here
http://developer.apple.com/library/ios/#documentation/uikit/reference/UITableView_Class/Reference/Reference.html
So, I'm a bit of a noob to iOS (PHP dev). I have a UITableView in a UIViewController. The cells consist of a combination of any of three different custom prototype cells. Which cells are loaded is based on a service that loads the questions and types. One has a segmented control with 2 choices, another with 8 choices and the third has a UITextView to receive a comment. This is essentially a survey. I can grab the values of the controls as they are answered, but I'd like to be able to just gather them up when the 'submitResponses()' method is called as an action attached to the 'Submit' button.
Any ideas? Should I be going about this in another way?
The "correct" way to do this is definitely to collect the data as it is entered!
One of the biggest problems with the approach that you suggest is that for larger tables it simply won't work because if a table view cell is off the screen, you can't access it or the controls/views that it contains (and it may not even exist yet!).
I have a series of images in a tableview, and I want to give users the option to value each image +1 or -1. The images come from a database, and obviously i dont want each user to be able to rate more than once.
I can only think up one solution; and that's creating another table with the image id's, device id's and 'kudos'. It would however need to check with the database every time an image is loaded for a specific device.
Can anyone think of a better solution?
Storing the images' votes in a DB is a good solution, as long as you are able to fetch them in time for display in the tableview - I recommend you use Core Data and check out NSFetchedResultsController which is just what you need, it is smart enough to update the table when there is a change to the votes, to pre-fetch the votes for the visible and the nearby cells, etc.
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?
I want to have a screen in my app that shows real-time log information - e.g. a scrolling list of textual strings. Previously I've seen people just use a textview and append new log entries to the list - it seems this may be not so efficient, especially when the list becomes long. Is there any sample code out there that can efficiently show real-time text log information? Or does everyone just write their own using a tableview?
Thanks
UITableView would be the way to go here, and using the deque idea Alex mentioned above, just call insertRowsAtIndexPaths:withRowAnimation: and deleteRowsAtIndexPaths:withRowAnimation: as you push/pop log entries onto your deque.
If you're building your own, perhaps you could use a deque of UITextView instances, adding to the end of the queue and removing from the front, only buffering a constant number of instances.
You could perhaps feed the deque to a UIView that contains the text views as subviews, with various offsets set based on how many lines your application is displaying at one time.