How do you guys deal with thumbnails in apps? What...

# android-architecture

[ursus]

How do you guys deal with thumbnails in apps? Whats the best way of future proofing this? Should the app tell backend what resolution the screen is and backend scale the image accordingly, or rather backend provide N sizes and app picks the best one? Do you also recalculate this based on current resolution?

[Michael Bernier]

we use a service called cloudinary, which takes care of cropping, resizing and caching images, we pass it the size and density we need depending on device and network quality. Then when the user goes into the picture viewer, we download a non cropped, higher quality picture

[ursus]

and how do you know the size? isnt size - aspect ratio constant and the size changes based on density you provide? (which you get from resources)

[ursus]

but then the backend kind of needs to know about the usecase how is it displayed in "dps", right, thats kind of silly?

[ursus]

or maybe required? im confused on this

[Michael Bernier]

yeah, size is constant, I only send the density I need

[Michael Bernier]

1x, 2x, 3x

[ursus]

ok, but that presumes that the thumbnails are for you specific usercase in app -- say avatar image, which is square

[ursus]

if you change design to rectangle, then thumbnails need to be regenerated on backend right?

[ursus]

or if you make the imageview bigger, then image that used to fit will be small, sinze you are still 1x density for example

[Michael Bernier]

that’s why we use an external service, we don’t need to setup anything, it caches request the first time, and then serve the cache version

[ursus]

Sure but you have to provide square source image

[ursus]

and precalculate its source size too.. i.e 1x is 30x50 etc

[Michael Bernier]

we provide the source image, the service does Center Cropping for us, we don’t precalculate anything, we just use the view size displayed on screen

[Michael Bernier]

with Glide or Picasso it’s done automatically

[ursus]

no no, I mean that the source image for the cloud service has to be say 500x500, and app provides that it wants 1x density, i.e. divide it by some factor, so it gets served 100x100 for example

[ursus]

i.e. the density just commands the factor, not the actual size, hence the original has to kind-of know about the usecase -- how big in dps is the element in app .. extreme example original image is 3000x3000, app tells its mdpi, and 3000x3000 asumed is xxxhdpi, so it gets divided by factor or lets say 4x, so it gets served 750x750 .. for 24dp avatar

[ursus]

which is obviously wasteful on the network

[Michael Bernier]

You also pass in the size you want the image in, so if you have 100dp x 100dp imageView, you with hdpi you will receive a 200px x 200px cropped image

[Michael Bernier]

you can also just pass the width, or height and ratio

[Rok Koncina]

We use GraphQL where we ask for the specific size. We calculate the size (px) locally, so that the server doesn't have to know that "the request came from Android device with hdpi"

[ursus]

@Michael Bernier if I pass in the actual size in pixels, i.e. you read it via imageView.getWidth etc, then whats the point of the density? irelevantn now

[ursus]

@Rok Koncina yea exactly

[ursus]

but how do you do it, I mean, do you provide precise image view size, and server gives you the closest match, i.e. bucket, or should It resize to precisely the pixels you want?

[Michael Bernier]

the server does the cropping/resizing

[Rok Koncina]

In our case we get the closest match, which is (atm) enough for us