1

Working on an Application that displays images in various sizes as grids, lists (Instagram like), images that take up the whole screen.

Ex. - you might have is a grid view image (not very big), but also this same image is shown in another screen that's almost the size of the entire screen. It's like a blown up version of this. There are also the smaller thumbnails of these images.

Working with the Backend team to come up with an optimal solution.

Questions:

  1. What's the most optimal way to handle images for different screen sizes? I know instagram sends the URLs for high resolution low resolution and thumbnails.

  2. Do we need multiple sizes for each image? example. grid view (do we need a 1x, 2x or 3x) for each image?. or can one size serve all phone screen sizes and we can just set the scale mode in code? Would this be ok even for smaller screen sizes? Would this be a poor experience for smaller phone sizes since they need images. To me this wouldn't be optimal since smaller phones like SE don't have the same processing power as iPhone 8 plus.

  3. If we're using the same API to serve iPhone and Android - how can this api be leverage for android given that they have more image sizes to handle.

Any guidance would be greatly appreciate it.

TheRealRonDez
  • 2,807
  • 2
  • 30
  • 40

4 Answers4

4

PREMISE:

You are talking about images from web server. Not svgs, not interface graphics. There's no official documents of this field, just suppositions and results of experience. I'm sharing mine.

If you meant interface graphics, there are official documentations from Apple and Google. If you meant svgs, they're automatically scaled. If you intended to have answer for those, please edit the topic or open new ones

A solution could be, instead of acting only on images sizes, to change the quality of JPGs.

You can use a full quality ~200x~200 image for little thumbnails (avatars, photo icons), which could be ok for all devices sizes, resolutions and models, without being too heavy.

Then, for bigger previews/full image opened you could maintain the same size (the original one, or a maximum size you define) but, using two version of the image: one with little JPG quality (so that it can be loaded quickly, consume less bytes and show the image content) and the other with the original quality (which requires loading and bytes, but it's only shown by demand).

To choose the right value of the little thumbnail (the ~200px), check the bigger thumb size you have. If you have an avatar bubble which is 96x96 on smallest res, multiply it for 3 (96*3=288) and you have the size! It is true that the smallest res screen will only require a 96x96 image, but, given that those are little numbers, the difference is not relevant (also, because we are talking about photos and not vectorial images, if you scale manually or if you leave the scaling to the device, the result is the same).

I've found some documentation from Google, which explains some things about image formats and how to reduce download sizes: https://developer.android.com/topic/performance/network-xfer.html They say to use JPEGs, PNGs, or WebPs and show some examples and guidelines for choosing the right format Format choosing by Google

Michele Bontorno
  • 1,157
  • 2
  • 13
  • 27
  • 1
    Yes I meant images from the server. It makes sense. I'm trying to find supporting documentation on this. To me - it makes sense, but this is the first time I do it. – TheRealRonDez Oct 24 '17 at 14:41
  • 1
    I found some documentation from Google, added it to the answer – Michele Bontorno Oct 24 '17 at 15:35
  • this approach makes a lot more sense. So for every case - if it's a thumbnail or medium size image or even larger images - you'd want to have two version of the image. Why because some devices don't need the bigger size images - you'd want to load only the one that you for that device. The API would return both a low and high res urls for each. I think this would cover most of cases for iOS. You answer makes a lot of sense - we'll see how this goes in practice ;) Thank you! – TheRealRonDez Oct 25 '17 at 00:40
2

You can use svg resources(which is a vector-based-image) : By doing so, you don't need to generate a resource for each resolution, and just need 1 resource. In realtime, the svg image will expand to the resolution of the device.

According to the documentation, you have a lot to gain here :

Using vector drawables instead of bitmaps reduces the size of your APK because the same file can be resized for different screen densities without loss of image quality

I have used this in Android, and it solves your issue in Android.

I Haven't used this in iOS but, it looks like there's a similar solution as well.

Dus
  • 4,052
  • 5
  • 30
  • 49
  • I've heard of vector based images - I've never done it for iOS. I wonder how this would work on things that aren't web views. I will have images that are small like thumbnails and big images that users can zoom in and checkout details. I will look into thank you! – TheRealRonDez Oct 25 '17 at 00:32
1

Your all questions are nearly have same goal. So Basically save 6 versions of images like 50px 100px 200px 400px 800px and 1600px etc.

6 will be enough since you can cover nearly all screen sizes like google does in android. which is ldpi mdpi hdpi xhdpi xxhdpi and xxxhdpi

Use an API for picture requests, send your screen sizes to api as parameter then give back resulting images width and height. for ex: for a 800x600 screen send back 400px version of it.

If you not do so, you will have to resize them on client size which is bad for performance and also bad approach for auto layout in IOS.

Kutlu Ozel
  • 182
  • 1
  • 7
  • I see what you're saying - I definitely don't want to use big images if its not needed. That's why you'd want to load images based on the screen size....from a url. – TheRealRonDez Oct 25 '17 at 00:34
1

You can use third party image managing solutions like Cloudinary.

https://cloudinary.com/

Cloudinary generates images of different aspect ratio which can be serve to all types of devices.

G K
  • 66
  • 7