I'm displaying a few images that are being downloaded over a network connection on a UITableView. Loading these images is extremely slow. Are there any performance tricks I can use?
If you are displaying images from the network, they should be cached for any sort of reasonable performance. Consider the built-in App Store application: it only loads images for table cells that are on the screen, but after an image is loaded the application stores the image for later.
Also, parsing XML on the iPhone is going to be slow--especially with binary data embedded. You should serve images to your app as PNG/JPEG over HTTP for best results.
What part is slow -- the network, or the drawing?
If it's the network, unless you control the source of the data (e.g. maybe the Web server hosting these images), there's not much you can do, unless you can switch servers somehow (say, from a small Web site to using Amazon's cloud technology).
If it's the drawing, you can use Core Graphics for drawing your views, if you're just using UIImage/UIImageViews, and you're certain that's the bottleneck, as it's a bit more work. You should also be (at the very least) caching the data you're downloading.
Edit: Have you profiled your code to see what's slow? That's always the first step in optimizing anything; measure, then optimize. If you're parsing XML, that could very well be the bottleneck, but there's no way to tell until you profile. As you can see, it's hard to tell someone how to speed up performance without knowing what the problem is first.
Related
For my Windows Phone Mango app, I want to make overlay a heatmap on Bing Maps, and a tile overlay seems the best way to do it. I've been having trouble finding any good documentation or code samples to work from. It seems like most people are pointing the tile source to a web service. I'd rather render the heatmap on the phone itself - is that possible?
One of the main reasons to use tilelayers to represent data on a map is that the computation and rendering involved in creating the layer is performed in advance, generally as a one-off or infrequent task. Then, at runtime, the only work the client needs to do is to retrieve the pre-rendered tile images from the server and display them straight on the map, which is a simple, low-resource activity.
Rendering tiles can be a resource-intensive task, both in terms of processing and memory usage - for example, I can only render about 3 tiles per second on a quadcore desktop machine with 8Gb RAM. Even if it's technically possible to create the tiles dynamically on a handheld device, the performance is almost certainly going to be unacceptable for any user. You've also got the question of how you're going to store the data from which the layer is created. Since you're talking about plotting a heatmap, I'm guessing you have a reasonably large dataset of points - did you envisage these stored locally on the device, or retrieved over the network? (either will create different problems).
Basically, while it may be theoretically possible to create tile layers dynamically on the client, doing so would negate almost any benefit of using tilelayers in the first place, which is why you probably won't find any code samples explaining how to do so. Perhaps you could explain your comment why you'd rather create the heatmap on the phone?
It's pretty easy to create a server-side tile renderer using .NET or PHP that renders and server tile images to a Bing Maps client, or you can use an existing map rendering library such as mapnik.org or geoserver.org.
Is Core Data in iOS 5 still the optimal way of caching things such as images (and their related metadata) in addition to other client-side data on the iPhone, or is SQLite the way to go if not all of the cache is being loaded into native controls such as UITableView? Some of the data I am looking to cache will be loadable by a UITableView, the other half of it will not. I know Core Data shines more with its integration into a table view, but I was curious if it's still worthwhile to explore for caching structured data that would normally come from a third party service.
For iOS development, I would not use SQLite over Core Data. Core Data has a large number of optimizations that would be time-consuming and difficult to implement yourself. Caching images in Core Data really depends on the size of the images. Thumbnails aren't too bad, larger images are. Core Data Programming Guide - Large Data Objects (BLOBs) has more information.
iOS 5, also has the ability to store large objects in the file system, rather than the database. If your project is targeting iOS 5+, I'd go that route.
You could use CoreData to manage the cache, but keep the files on disk. Each app has its own Cache directory which does not get backed up when the user syncs. I would be surprised if someone hasn't implemented this sort of thing already.
I have a DB and web server in the same host. I have an iPhone app that sends XML to the web server. The web server will query the database and return data back to the app.
I'm not sure whether this is the fastest way
Are there other ways faster than this?
In server-client programs, the biggest bottleneck is usually the network latency unless you are doing very complicated time-consuming processing at server side or you have behemoth data in your RDBMS and need to search from it.
There are a couple of things (scopes more than XML) that you may try for fast loading:
If you are feeling that database is the bottleneck, you may try caching (look for MemcacheD and the likes) objects in front of database. This will reduce DB hits and retrieval will be faster.
Use compression in XML. Or use shorter notation like JSON or YAML. In general, for webapps:
Reuse and use optimized (compressed) images. Use more CSS less images wherever you can.
Minify the components like CSS and JS.
Don't load everything at once, if not needed.
You may look into XML compressors or if you can, use some shorter notation like JSON or YAML. But I guess it will be hard to change data format if you have already developed the app.
XML isn't the world's most compact format, so you could obviously speed things up by reducing the amount of data that you send and receive. If you can talk to the database directly, you can cut out the web server, which would surely speed things up too.
The thing is, though, that XML and HTTP are standards, and there's a lot of value in that. Is the small increase in speed that you get from a purpose-built custom protocol really worth the loss of flexibility and extra development time?
My iPhone app has a built in RSS reader. There are images and I'd like to find a way to cache them on the system but have the system manage the caching and eventual clean up.
Is there a way of doing this?
Three20 does decent image caching. You don't need the rest of it, just look at TTImageView which is a drop-in replacement for UIImageView. You just do
someImageControl.urlPath = #"http://example.com/your/image.jpg";
And TTImageView handles the rest, including caching on disk etc.
I only have two minor problems with this approach myself:
for some reason, it does not seem to load all image formats, even if the image is valid JPG/PNG otherwise. Haven't yet debugged this.
I am not sure how it handles the cleanup part. I notice some images are sometimes disappearing from cache and refreshed from network, but it has not bothered me enough to investigate. It "just works."
TTImageView has some other nice properties that I don't have to waste my time on, e.g there is a placeholder image that you can ship with your app that is shown until the real image loads from network, etc.
I have an application where the user will navigate around a set of photographs. What's best in terms of performance for this scenario, SQLite + Core DATA for persisting the photos as NSData objects or having the photos as png files directly on the file system?
thanks.
It really depends on the size of images. I would certainly put small things (like thumbnails) right in the DB. If your images are large you will either want to put them into separate files, or be very careful that those columns are not faulted in unless you actually need them.
With CoreData you can just use a computed property to load and save the external file.
I'd agree with Louis. The file system is almost certainly going to be faster for images of any significant size.