Cloudinary Blog

Shortening the Development Cycle of Media-Related Apps

Shortening the Development Cycle of Media-Related Apps

Currently, the Android platform boasts the highest demand for mobile solutions, as evidenced by Google’s announcement in 2017 that there were two billion monthly active Android devices, a number that is likely to increase in the years ahead. For app developers like you, now is the right time to build and release solutions for Android. you might have also noticed that a higher percentage of apps being developed nowadays are filled with visual media: images and videos.

The challenges of managing image and videos on Android are well known. It is for that reason that libraries such as Glide, Picasso, and ExoPlayer (for videos) became available with the aim of accelerating the loading process and better managing device memory. Are those libraries meeting your needs? Yes? Excellent! So you ask: What then is the problem? Read on.

Webinar
How to Optimize for Page Load Speed

The Challenge of Efficiently Delivering Images

An increasing number of resources used by app developers are from Web services and other remote locations, which limits your visibility into important information about the image, such as size. Imagine a 5616 x 3744 image being served to you, which you must then serve to your audience. With an image library, loading the image a second time (from the cache) might be a smooth sail. However, loading it for the first time before compression and caching might require an inordinate amount of time and bandwidth. Even now in the 21st Century, reliable broadband connections are virtually nonexistent in some countries, in which case your users there might find themselves staring at an empty screen or a perpetual holder image across the entire app for long minutes.

With Cloudinary’s robust solution, you can bypass that issue. Cloudinary offers too many features to describe in a single blog post. This one focuses on Cloudinary’s image optimization capabilities only.

A Test of Resource Usage and an Analysis of the Results

We just performed a test to check the resource usage in a device—before and after Cloudinary. We loaded a large image into an app without Cloudinary and then did the same with Cloudinary in order to evaluate a worst-case scenario. The device in question is a Samsung SM-GF32F with a RAM capacity of 1.5 GB. Finally, we measured the metrics with the Android Profiler.

Loading that unoptimized image took about 13 seconds, resulting in high CPU and network activity and a memory usage of 48 MB. More details are in the image below.

Metrics of an un-optimized image

Loading an optimized image yielded these results:

Metrics of an optimized image

The optimized image loaded in only four seconds, using up 23 MB of RAM and minimal network and CPU activity. Those are important metrics to take note. Because many Websites display numerous images, optimizing the latter would significantly shorten the download time and deliver a boost in user experience.

Process of Optimization

By leveraging Cloudinary’s impressive optimization capabilities, we were able to effectively optimize the image while still maintaining excellent image quality. Specifically, we employed these three techniques in Cloudinary:

  • Reduction of mage widths
  • Automatic format selection
  • Automatic quality selection

We achieved optimization by adding this code snippet:

Java:

Copy to clipboard
    MediaManager.get().url()
            .transformation(new Transformation().width(500).quality("auto").fetchFormat("auto")).generate("dog.png");

Kotlin:

Copy to clipboard
    MediaManager.get().url()
            .transformation(Transformation<Transformation<out Transformation<*>>?>().width(500)!!.quality("auto").fetchFormat("auto"))
            .generate("dog.png")

The parameter values in the above code are all defaults. In addition, Cloudinary contains an algorithm that scales the quality of images. For more details on image optimizations, see this section in the Cloudinary documentation.

Conclusion

With Cloudinary, you can appropriately scale images, thereby reducing the bandwidth in a device’s memory and CPU and shortening app-development cycles. Try it out for yourself; you’ll be impressed.

Recent Blog Posts

Transitioning JPEG-Based to JPEG XL-Based Images for Web Platforms

When the JPEG codec was being developed in the late 1980s, no standardized, lossy image-compression formats existed. JPEG became ready at exactly the right time in 1992, when the World Wide Web and digital cameras were about to become a thing. The introduction of HTML’s <img> tag in 1995 ensured the recognition of JPEG as the web format—at least for photographs. During the 1990s, digital cameras replaced analog ones and, given the limited memory capacities of that era, JPEG became the standard format for photography, especially for consumer-grade cameras.

Read more

Amplify Your Jamstack With Video

By Alex Patterson
Amplify Your Jamstack With Cloudinary Video

As defined by Amazon Web Services (AWS), Amplify is a set of products and tools with which mobile and front-end web developers can build and deploy AWS-powered, secure, and scalable full-stack apps. Also, you can efficiently configure their back ends, connect them to your app with just a few lines of code, and deploy static web apps in only three steps. Historically, because of their performance issues, managing images and videos is a daunting challenge for developers. Even though you can easily load media to an S3 bucket with AWS Amplify, transforming, compressing, and responsively delivering them is labor intensive and time consuming.

Read more
Cloudinary Helps Move James Hardie’s Experience Online

While COVID has affected most businesses, it has been particularly hard on those that sell products for the physical ‘brick and mortar’ world. One company that literally fits that bill is our Australian customer James Hardie, the largest global manufacturer of fibre cement products used in both domestic and commercial construction. These are materials that its buyers ideally want to see up close, in detail. When customers have questions, they expect personal service.

Read more
How to Build an Enhanced Gravatar Service, Part 2

Part 1 of this post defines the capabilities of an enhanced Gravatar service, which I named Clavatar, and describes the following initial steps for building it:

This post, part 2 of the series, explains how to make Clavatar work like Gravatar and to develop Clavatar’s capabilities of enabling requests for various versions of the images related to user accounts.

Read more