views:

67

answers:

3

I'm working on an ipad application that needs to work with images; it uses four different versions of each image in different situations (each has its own resolution and image quality).

The options I have to get the images in the app are:

1) Download only the original image. Convert the image into several formats on the ipad. CPU/mem consumption on ipad will be larger, bandwidth will be lower.

2) Convert the image into several formats on the server, download all the variants to the ipad. CPU/mem consumption on ipad will be low, bandwidth usage will be higher and download times will be longer.

From your experience, which of these solutions is the best practice? And would your approach be different if you know up front whether or not the application will be mostly used using wifi or on the road using 3G?

A: 

In my opinion downloading as few as possible is more convenient. Chances are, converting on the device is often much faster. Especially when not on WiFi or 3G but on a much slower connection - which happens to many people frequently. It also minimizes amount/costs for data transfer, which might be important to some users.

Probably easier on the server-side, too...

So if the calculations are not brutally slow, client wins for me.

Eiko
A: 

As you're assuming most people will be using WiFi, I say resize on the server:

First, memory/speed. While you can spawn multiple threads on the iPad to speed up resizing to multiple formats, this will only get you so far as you're rather constrained memory-wise. Merely loading one 1600x1200 image will easily rack up 40M on its own. Multiple formats in multiple threads might get you in trouble (like getting killed for not having enough memory). Your server will have multiple gigs of RAM and multiple processors. The iPad just isn't going to beat that. The downside, ofcourse, is that you are going to have to maintain a companion site for the lifetime of your application.

Secondly, having it on the server and not hardcoding the exact formats in your iPad application will give you more freedom when you decide to change (or bugfix) something with your formats. Changing server-side code is, obviously, much easier than redeploying your iPad app to the App Store with a little tweak (and having some people upgrade and some not).

I wouldn't worry to much about bandwidth consumption, but make sure to make note of it when your user is on a 3G connection (use the Reachability API).

MathieuK
Thanks, I indeed use Reachability to warn the user if they're going to download over 3G. The companion site is not a worry, images are downloaded and kept on the iPad anyway, so if the companion site goes, all that happens is that there will be no more new content.
Ivo Jansch
Additionally, I would suggest hosting the images on a reasonably fast and available content delivery network. Amazon Cloud Front and S3 work well for me.
TomH
A: 

It depends on the size of the images doesn't it?

If you are using really big images, you could even download a smaller one, then let the server actually do the edits on the big images, with the iPad app sending back the directions on what to do to the big image(s).

That way you could edit full resolution 14 megapixel photos with an iPad - download a 'mere' megapixel image (it could be jpg compressed some), then tell the server to deal with the 14*4 = 56MB * 2 or more memory needs for the real process.

3G is pretty fast - some coffee house wifis are slower. I would not let that worry you.

Tom Andersen