{"id":21692,"date":"2018-03-07T17:46:36","date_gmt":"2018-03-07T17:46:36","guid":{"rendered":"http:\/\/giving_your_mobile_app_a_boost_part_2_mobile_responsive_image_delivery"},"modified":"2024-06-04T15:33:42","modified_gmt":"2024-06-04T22:33:42","slug":"giving_your_mobile_app_a_boost_part_2_mobile_responsive_image_delivery","status":"publish","type":"post","link":"https:\/\/cloudinary.com\/blog\/giving_your_mobile_app_a_boost_part_2_mobile_responsive_image_delivery","title":{"rendered":"Giving your mobile app a boost – Part 2: Mobile responsive image delivery"},"content":{"rendered":"

In part 1 of this blog series,<\/a> we told you how we can optimize the process of uploading user images from your mobile app by taking advantage of the new pre-upload image processing functionality available in Cloudinary\u2019s iOS and Android SDKs. We showed how you can scale down all user images to the maximum size necessary before you upload them, to save bandwidth and improve app performance.<\/p>\n

In this part, I\u2019ll show you how to implement our new responsive images<\/a> solution, which enables you to optimize the image you deliver based on the requesting device\u2019s resolution and the available dimensions. This new feature can help you to simplify the many complexities of creating multiple variants of every media assets, with on-the-fly manipulation and fast delivery through the CDN.<\/p>\n

What is mobile responsive image delivery?<\/h2>\n

Having a responsive mobile app design means that the content responds to the application environment. In the scope of media assets, this means that images should be automatically adjusted for optimal viewing based on device size and layout. As mobile developers, we should make the effort to optimize our application for different screen sizes and densities, and it\u2019s our responsibility to be careful about our assumptions regarding pixels and bandwidth, because not all users have high-end devices or a strong internet connection.<\/p>\n

Supporting multiple device sizes and slow connections<\/h3>\n

The Android ecosystem has tens of thousands of different devices<\/a> that offer different hardware capabilities, screen sizes and densities. iOS has a much smaller set of possibilities, but it still has quite a few to add to the mix.<\/p>\n

You might also be surprised to hear that 25% of new Android devices selling today have only 512MB RAM<\/a>. These devices are mostly found in emerging markets like India, but definitely not only there.<\/p>\n

Moreover, according to OpenSignal<\/a>, when talking about mobile internet connections, even in countries like Germany, Italy, France and the U.K, the chances that a 4G subscriber will connect to an LTE network are little better than a coin flip. This means that even when our phones and mobile suppliers support it, we don\u2019t always enjoy the benefits of a high speed network.<\/p>\n

\"Likelihood<\/p>\n

Image source: igvita.com: Resilient Networking <\/a><\/i><\/p>\n

Making your images deliver more responsively improves the user experience and minimizes the user\u2019s data plan usage. You deliver the image that looks and fits best in each user\u2019s device without sending an image that would be too large or too heavy for those seeing it on a small screen or via a low bandwidth connection.<\/p>\n

Different devices and different display dimensions<\/h3>\n

Delivering responsive images also requires us to be aware of the size, quality and format of the original images and adapt all of these depending of the target view and the platform of the final user.<\/p>\n

The problem is vividly clear<\/h3>\n

The following screenshots highlight the challenges described above. The screenshot on the left shows a mobile app that downloads original images. They look great, but its a huge download expense \u2013 over 10 megabytes for a few thumbnails that barely fill the screen. The screenshot on the right shows the same app set to download all the thumbnails at a fixed width of 100px. The images have a very small download size of around 40 kilobytes each and the images even look reasonable on smaller devices, but look quite bad on large screens or high density devices.<\/p>\n

\n<\/div>\n
\n\n\"mobile<\/a>\nhigh quality, huge filesize<\/b>\n<\/span>\n\n\"mobile<\/a>\nsmall filesize, but poor quality<\/b>\n<\/span>\n<\/div>\n
\n<\/div>\n

What this app needs is an easy way to deliver different image sizes to different devices, never exceeding the max resolution that looks good on each device for the defined image view size.<\/p>\n

Cloudinary as your one-stop-shop for mobile media management<\/h2>\n

Cloudinary can help reduce the complexity of maintaining and generating multiple image versions with its dynamic image manipulation features. You can build Cloudinary dynamic image URLs that define any image width and height you want. This means you don\u2019t have to pre-create perhaps hundreds of versions of each image. Instead your images are dynamically resized on-the-fly, before delivery, as needed. Using Cloudinary, you can upload a single, high-resolution image to the cloud and deliver it in as many different sizes as your users (whom you don\u2019t know) need via URL parameters according to the target devices.<\/p>\n

To make things even easier, you can now use our mobile responsive solution, which not only saves expensive development time, but also automatically handles the calculation of the required image dimensions for the many (many, many) device screen sizes.<\/p>\n

\"Android<\/p>\n

Image source: OpenSignal 2015: Android device fragmentation<\/i><\/p>\n

When you include the responsive option in your delivery command, Cloudinary first retrieves the exact available dimensions for the image view element that is requesting the image, and then rounds up the height and width to the nearest step (100 by default). For example, if the exact image view width is 284X284 pixels, a 300X300 pixel width image is generated on-the-fly and delivered to the requesting device. This functionality prevents too many image versions being generated and reduces cache hits for subsequent requests from other devices. The next time any image view measuring 201-300 pixels requests the same image, the existing 300X300 image is delivered directly from the CDN cache.<\/p>\n

Not only does this solution save you the effort of pre-generating tens or hundreds of images; it also eliminates the guesswork on the required sizes and number of images needed. Such guesswork nearly inevitably leads to some delivered images being too small for the image view, resulting in poor quality, while others may be significantly too large, resulting in wasted bandwidth.<\/p>\n

Let\u2019s see it in action<\/h3>\n

Android<\/h4>\n

You use the MediaManager\u2019s responsiveUrl<\/code> and generate<\/code> methods to generate a dynamic image URL based on the dimensions needed for the image according to a specified ImageView element.<\/p>\n

For example, to generate the responsiveUrl for the sample image, automatically resized to fill the available width and height:<\/p>\n

MediaManager.get().responsiveUrl(true<\/span>, true<\/span>, \"fill\"<\/span>, \"auto\"<\/span>).generate(\"sample\"<\/span>, profileImageView, new<\/span> ResponsiveUrl.Callback() { @Override public void<\/span> onUrlReady(Url url) \n{ \n\/* Use your favorite image download library to fetch the image, picasso example:\n*\/<\/span>\n Picasso.with(context).load(url.generate()).into(imageView); } });\nCode language: JavaScript (javascript)\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n
iOS<\/h4>\n
With iOS, it\u2019s a little different since the responsive method is provided at the level of the UIImageView component. For example, here\u2019s how you would set an iOS UIImageView component named photoImageView<\/code> to responsively fetch and display the sample<\/code> image in JPEG format, automatically resized to fill the available width and height:<\/p>\n
let<\/span> transformation = CLDTransformation().setFetchFormat(\"jpg\"<\/span>)\nlet<\/span> params = CLDResponsiveParams(autoWidth: true<\/span>, autoHeight<\/span>: true<\/span>, \n  cropMode<\/span>:   \"fill\"<\/span>, gravity<\/span>: \"auto\"<\/span>)\n\nphotoImageView.cldSetImage(publicId: \"sample\"<\/span>, cloudinary<\/span>: cld, \n  resourceType<\/span>: \"image\"<\/span>, responsiveParams<\/span>: params, transformation<\/span>: transformation)\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n
Remember the problematic file sizes and qualities in those screenshots we showed earlier<\/a>?\nWell, with the simple code like that shown above, you get the optimal image size for each device.  With this code, the same app we described above now scales the images according to screen size and density. For small, low density screens, the images are delivered at about 30-40 Kb. For large, higher density screens, the images will be delivered at up to 200-250 Kb (still a far cry from the original 10MB images and the visual quality is just as good).<\/p>\n
Let\u2019s sum It up<\/h3>\n
This post demonstrated how Cloudinary optimizes the trade-off between required image size and number of images by automating the calculation based on the requesting device in real-time. This enables you to deliver responsive images<\/strong> to your native iOS or Android app by adding a single line of code.<\/p>\n
In our previous post<\/a>, we showed how you can use our other new feature, pre-upload processing<\/strong>, to perform client-size resizing of user-generated content based on the maximum size you ever expect to deliver that image, and to only upload the resized image.<\/p>\n
Using both of these new mobile SDK features in your Android and iOS apps can save your users bandwidth and improve app performance on both upload and delivery, while saving you valuable development time and effort.<\/p>\n
If you don\u2019t have a Cloudinary account yet, sign up for a free one<\/a>, install the iOS<\/a> and\/or Android<\/a> SDKs, and discover how quickly you can start improving your users\u2019 experience.  Oh, and if you have a web-based version of your application, make sure you check out how to deliver images responsively in the browser<\/a>.<\/p>\n
We can\u2019t wait to hear how you are going to use these new capabilities and we\u2019d love to hear how they improve the performance of your native mobile app.<\/p>\n
Further Reading on Responsive Images<\/h2>\n
For more information on the usage of these methods, take a look at our responsive documentation for Android<\/a> and  iOS<\/a><\/p>\n