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.
Related
I am newly in iOS development.I have to make an application for a car dealer in which i have to show different cars with different colors.Please tell me the best way because i have to fetch lots of images every time from the web server.How can i reduce the rendering time in fetching the images.
Please consider i am very new in ios development and need your help.
If you have any sample application please share it with me.
You can use DB to store images as BLOB and also fetch images only when there is update at server.
First, make sure you send images that are no larger than needed.
If you have a list view that shows pictures of the cars, have a webservice send you premade thumbnails that are (preferably) exactly the right size.
Second, Make sure the images are loaded separately from the data set.
The best place to do this, would be in the controllers for your UITableViewCell.
Just have your UITableViewCell start their own thread to download and display the image as soon as they come into view.
Third; caching.
Make sure you save local copies of the thumbnails, and make sure the Table View Cells search for local copies of the images, and load those instead of downloading them if they are already locally present.
you can do:-
use lazy loading
use paging
use predicates for searches
use fast enumeration
these things in general will keep your app smooth
If you are going to show images in UITableView then you can use lazy loading. It will load images only for the displayed rows and once image for any row index has been downloaded, it will not repeat downloading for that row index. So its faster and useful.
Can anyone point me towards an example or tutorial for this? I basically want to save images to the documents folder then have a table that contains them for user review later on.
I've got it working but only when I go and add each image to an array then generate the table with contents of said array first. Is there a quicker or more automated way to do this?
Here's a nice tutorial giving a project you could adapt:
http://www.raywenderlich.com/19788/how-to-use-nsoperations-and-nsoperationqueues
While it's actually about doing lazy loading and other image operations on a secondary thread (keeping your UI responsive) you may as well display images in a table this way to begin with.
The main modification you would make is to look for the locally stored image first, then go and do the network fetch if it is not available. A further refinement would be to check a timestamp stored with each local image and update from the web if a newer one was available.
That is correct, you prepare your datasource first (which is array of images), then you pass it to tableview and reload it. If you are working with lots of images, consider lazy loading.
Apple has an example on this.
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'm relatively new to iOS development and am just wanting a few pointers as to what will be the best way to go about doing this. I am building an app with a tab bar and one of those tabs will be a table view at the top of which is a segmented control with two buttons allowing you to swap between datasets.
The first question I have is:
The data is relatively simple but there are about 6000 records would it be best to use a simple NSDictionary as the data source or should I look into using Core Data. Users of the app will simply be able to select a record to add it to a favourites list, or deselect it.
Secondly:
Should I use two different view controllers and swap them in and out depending on which option is selected or should I use a single view controller and swap the data in that class to populate the table.
I'm a registered Apple Dev so I have access to their examples but often can find them difficult to follow, any pointers to resources/tutorials would be VERY appreciated.
First off, for anything nontrivial always consider Core Data - in your case especially so. A 6000-object dictionary can easily get unwieldy to manage.
As for the view controllers, I believe the canonical thing to do is to use a single table view controller (since you remain on a single UITabBarController tab), but change out its data source, or just change the data returned from that source.
If you need it to look reasonably smooth, you can play with the built-in UITableView animation methods - I believe the AP application changed out its news stories by animating out all the old ones and animating in all the new ones within a single table view, so the effect was of a complete dataset change but without the extra view controller.
Generally I've found the Apple examples and tutorials to be the best available, but there's no substitute for just building apps and playing around with the technologies yourself - if you don't understand an example, try to reimplement it yourself and see what's giving you trouble. If you're truly stuck on something, come back and ask another question!
First question:
If your dataset is fairly simple, I would recommend sticking with an array of dictionaries; or, if order is well-defined, and each row has a meaningful unique key, simply use a dictionary.
There's a complexity tradeoff involved in using a large framework like Core Data, and until you have—for instance—relationships expressed in your object model, I don't think the tradeoff is worth taking.
That said, there are performance issues to take into account when making these kinds of decisions. You have 6,000 records, but is each just a key and a value? That wouldn't be such a big deal. But if you have a number of columns, and sorting is an issue, Core Data's SQLite backend would help you out a great deal.
If the array or dictionary is filled with standard Foundation data types, you'd get serialization for free, since all of them implement NSCoding.
Second question:
Read through Apple's article on the model-view-controller design paradigm. The thing to note about what you're trying to do here is that since you're only looking to vary your data, only your model should be changing.
UITableView is designed to make that easy. It's a view, so it doesn't store its data, but it has a dataSource property which it queries to display information. So when your user switches datasets, simply switch your table view's data source.
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?