Cloudinary Blog

Introducing the Cloudinary Demo Android App, Part 2

How to Customize Cloudinary's eCommerce Android App

Recently we added the Cloudinary Demo - eCommerce App to the Google Play Store. This app demonstrates the best practices for optimal delivery of images on a storefront, including category pages, product pages, and a shopping cart. At the time, we published Introducing the Cloudinary Demo Android App, Part 1, which provided an under-the-hood tour of how the eCommerce Android App was designed and how Cloudinary was integrated throughout.

The app demonstrates how to leverage some of Cloudinary's capabilities, such as managing file uploads, displaying images responsively, and optimizing delivery through global Content Delivery Networks (CDNs). The app was developed as an open source project so that you can explore the code for yourself and see how to improve your users' experience and the performance of your apps by delivering images, enhanced and optimized for different contexts.

CloudinaryDemoApp1 CloudinaryDemoApp1 CloudinaryDemoApp1

Webinar
How to Optimize for Page Load Speed

In part 2 of this series, we will focus on how the open source code that we've published on GitHub can also be used as the code base for developing your very own Android app, using Cloudinary for media upload, optimization, and responsive delivery.

Tip
Some sections in this post assume you have a basic understanding of how the Cloudinary Demo Android App is designed and structured. If you didn't get a chance to read Part 1 of this post, or it's been a while since you did, we recommend reading it before continuing.

Overview

After you fork the Android Demo Application github repository, you just need to make a few basic changes to make the app your own:

  1. Configure your App with the Cloud Name to your account.
  2. Update the Data Flow from the data and remote packages, through the repo to the ViewModels, and then on to the UI.
  3. Give your Product Images Context so that your app will use your own product images from your own Cloudinary account.
  4. Switch Over to a Real Backend Flow instead of the local file implementation.

So that's it in a nutshell. The following sections go into more detail:

Configure your App

Your App needs to be updated to use the Cloud Name of your own Cloudinary account to retrieve product images. If you don't have a Cloudinary account yet, you can easily sign up for a free account. The first step is to update the cloudName in two places:

  • The config.xml file located under /res/values
  • The CloudinaryWebService.java public interface located under java/com/cloudinary/android/ecommerce/demo/remote

The App uses Cloudinary's client-side resource lists to return all the images that have been tagged with e_commerce_product, however this can be changed to a tag of your choice, under the config.xml file located under /res/values. Make sure that your App will be able to access Cloudinary in this way: open your Management Console and then navigate to Settings => Security => Restricted image types and make sure that the Resource List check-box is clear.

Update the Data Flow

The starting point for personalizing the app for your own needs is updating the data package to use your own models. Make changes as follows:

  1. Adapt the model itself to use a class representing your own products (e.g. for this app, a Product is the main model).
  2. Update the ProductDatabase to include the new and modified models.
  3. Update the ProductDao to refactor the queries, and add/remove queries to handle the new model and relations.

The next step is adapting the remote package for your own use. Change the fields and parameters to use the new models. Once that’s done, the ProductRepo also needs to be updated similarly: modify the parameters, fields and types to handle the new models as well.

Now on to the viewmodel package, to update the parameters and types as well as the application logic if needed, followed by the necessary UI changes in the app package. Most of the fragments, screens, and grids can and should be reused. XML layout files can be updated and those changes should be reflected in the different adapters (e.g. CategoriesAdapter, ProductAdapter etc.).

Give your Product Images Context

All images to be included in your app need to have a common tag (e_commerce_product by default). The app logic utilizes product information stored with the images as ‘context’ key-value pairs: make sure that all images to be displayed also include the following 6 ‘context’ key value pairs:

  • department: “men” or “women”.
  • description: a short string description, 2-3 words.
  • name: a short string, preferably one word.
  • price: a number.
  • productId: a number
  • isMain: a boolean value determining whether this is the product’s main image (only one asset per product should have “true” for this field).

All the context key-value pairs, except for isMain, should be identical across all the images that represent the same product. An example of the context key/values assigned to an image:

Copy to clipboard
“department”:“men”,
“description”:“Messenger bag”,
“name”:“Messenger”,
“price”:“245",
“productId”:“10",
"isMain":"false"

Switching Over to a Real Backend Flow

Lastly, you'll probably want to switch the injected remote repository to use a backend instead of the local file implementation that we used for demo purposes:

  1. Update the ProductRepo.java file located under java/com/cloudinary/android/ecommerce/demo/data: change the label in the constructor annotated parameter, from cloudinary to backend (i.e., @Named(“cloudinary”) should become @Named(“backend”))
  2. Change the implementation of BackendWebService.java located under com/cloudinary/android/ecommerce/demo/remote to retrieve and save data against your own backend. Both saveProduct() and getAllProducts() should be completely re-written, while all the other methods should be completely removed.
  3. Your backend logic should now determine the relevant PublicIds of the images for each product and the product metadata should now be implemented directly in the model from your backend, and not from the context key-value pairs attached to the image.
  4. If any Android components are added, removed or modified, verify the injection engine is updated accordingly (the di package).

To App or not to App

The open source code of the Cloudinary Demo - eCommerce Android App can be easily modified to provide the framework for your own App. The code takes advantage of existing open source libraries and gets them to work together while adopting best practices for efficient management and optimal delivery of your images when building your own Android App. If you don't have a Cloudinary account yet, you can sign up for a free account and give it a try.

About Cloudinary

Cloudinary provides easy-to-use, cloud-based media management solutions for the world’s top brands. With offices in the US, UK and Israel, Cloudinary has quickly become the de facto solution used by developers and marketers at major companies around the world to streamline rich media management and deliver optimal end-user experiences.

For more information, visit www.cloudinary.com or follow us on Twitter.

Recent Blog Posts

Create Lightweight Sites With Low-Code and No-Code Technology

Consumers expect modern websites to be mainly visual. But, the more compelling and complex the related media is, the more data is involved, compounding the site’s weight. In today’s content-craving world, delivering unoptimized media can cost you because it leads to sluggish page loads, resulting in visitors abandoning your site in search of a faster alternative. In fact, a page load that takes more than three seconds can cause as many as 40% of your visitors to bounce. Given this competitive, digital-first environment, you can’t afford to lose page views, for time is of the essence.

Read more
A Blueprint for AWS-Secured Webhook Listeners for Cloudinary

tl;dr: An AWS-secured and optimized Cloudinary webhook listener for extending the Cloudinary service

Code: Github

A webhook is a communication medium for sending notifications from one platform to another about events that occurred. In place are user-defined HTTP callbacks that are triggered by specific events. When a triggered event takes place on the source site, the webhook listens to the event, collects the data, and sends it to the URL you specified in the form of an HTTP request.

Read more
New Accessibility Features for Cloudinary’s Product Gallery Widget

Cloudinary’s Product Gallery widget, which launched in 2019, has enabled many brands to effectively and efficiently showcase their products in a sleek and captivating manner, saving countless hours of development time and accelerating release cycles. By adding Cloudinary’s Product Gallery widget with its customizable UI to their product page, retailers reap numerous benefits, often turning visitors into customers in short order.

Read more
Why Successful Businesses Engage With and Convert Audiences With Visual Media

Most business buyers prefer to research purchase options online, as do many shoppers. No wonder online retail sales in the U.S. rose by 32.4% in 2020—an impressive gain of $105 billion.

For B2B and B2C businesses, text-heavy websites are no longer adequate in attracting shoppers. Instead, engaging visual media—spin images, videos, 3D models, augmented reality—are becoming a must for conveying eye-catching details and differentiators about products or services.

Read more
Making User-Generated Content (UGC) Shoppable With Cloudinary

User-generated content (UGC) is a powerful marketing tool. Not only does video complement marketing efforts for e-commerce by enabling customers to explore products in greater detail, but UGC also adds an element of trust. As a bonus, user-generated video is an exceptional opportunity for e-businesses to attract website traffic without their marketing team having to create promotional videos from scratch. User-generated content drives conversions and brand loyalty as a direct result of authentic interaction.

Read more