Do Androids Dream Of Salesforce Clouds?

Blog:

This article assumes you have a basic knowledge of mobile development and Salesforce administration.

For years I’ve had a love for Android, and you can imagine my excitement when Salesforce created a way to integrate the two technologies. I remember my first “real” program was an Android app which played Rock, Paper, Scissor, Lizard, Spock. I was 17 at the time, and it started a lifelong passion in computer programming. When Salesforce released Software Development Kits (SDKs) for iOS and Android, I jumped on it as quickly as I could.  

At one of my previous jobs, I was a lead creator and manager for a Salesforce mobile computing department. I wrote the handbook on best practices, case handling, story writing, and everything in-between. I handled apps which helped clients utilize Google Maps and their salesforce databases to automatically track when shipments on semi-trucks would arrive, what cargo they had, and if any issues arose (think simplified roadside assistance). Other apps included registration apps for events and much more. Most of the data being saved on the devices automatically synced with their Salesforce instances to allow management clear reporting visibility without increasing clerical overhead. 

Regardless of the app’s goal, the way Salesforce developed their SDK allows for programmers to write beautiful applications with a relatively small learning curve to get started. In the next few sections, I’ll cover how to get started, what resources to review, and building your very own Salesforce-integrated app. 

Installation 

• JDK (Java Development Kit) 

• Android Studio 

• Once studio is installed, create a virtual device 

• Salesforce Native Android Trailhead 

At the time of writing this, I’m using API level 29 for my emulator and 28 for my project. Using the most recent versions possible on your program is highly recommended to reach the most phone users possible. I didn’t choose these versions for a specific reason other than being the most recent ones available. But do be careful which versions you choose as they sometimes prevent you from accessing things such as Bluetooth and other components in the phone. Google goes into far more detail about that stuff here.  

Order Management App 

I decided to spin up a dev org for this project and create a simple order management application. I imagined myself as the user who happened to be a delivery driver for Chicago Cloud Group. I was hungry when making this, and sadly we don’t deliver food (yet). Regardless, I chose an order management app for a few reasons: (1) I’m utilizing the native Order object in my dev org so it’s a simpler setup than most examples and (2) a delivery driver both reads and updates data as they make their stops. I’m not going to develop a crazy complicated application in this article. The focus will be on learning the basics behind mobile development and how easy it is to get started. 

Before I perform any work in my Android application, I must first set up the Salesforce instance. I went into my sandbox and had to enable Object-level visibility to the Orders object. Despite being a system administrator, the Orders tab is not visible by default. Simply go to: 

Setup -> Profiles -> System Administrator -> Orders Tab = “Default On” 

Next, I added a picklist value to the Status field on the Orders object. The value I added is “Completed.” It’s going to be useful in showing how validations and updates work later. 

Setup -> Object Manager -> Order -> Fields and Relationships -> Status

You may have noticed the validation rule right above the value set. We’re going to add this validation rule to help showcase some graceful error handling in Android.

Next, we’re going to lead a handful of test records. Luckily for you, I already made three data loads for you. First one is the Pricebook (Pricebook2), then Product (Product2) record set. Next will be the Orders. Finally, the Order Line Items. As you’re loading the Order Line Items, make sure to change the Product2Id field to match what your system created.

Connected App

Salesforce requires an endpoint to access its data from an external resource such as our application. In a previous article I wrote, I went in depth on how to make a Connected App. Please reference that until it talks about using Postman.

App Development

First, you need to set up a native project by following this Trailhead. Once you’ve got that all set up, we can start developing the base of the application. First, we’ll need to have objects to record our data. In the setup, I’ve made Order.java and OrderLine.java classes to record the data I want.

I used the “Implements Serializable” method to handle passing record data between Activities later. I could store this data in the phone’s database for offline access, but that’s for another article. Next, I’ll need to update the Gradle to import a handful of useful libraries for this.

Next, I want to use Android’s RecyclerView to handle list data because it’s versatile, efficient, and scalable. To do that, you need a supporting adapter class. MyAdapter.java provides the basis for this.

Now its time to develop the core logic. We’re going to rely on Salesforce to provide the business logic. The app should only handle app pages and reading/updating data. The app should never handle business logic. But if you find a situation where you need to handle business logic in the app, it should be kept to an absolute minimum. Following this mindset allows your app to quickly scale with the business without adding dozens of hours to updating business logic.

Within the MainActivity.java file, we process the request response from Salesforce as JSON. The basis of this response comes from using a SOQL query that you’re probably familiar with already.

Below is an example of the JSON response you would see when dealing with requests.

In a previous section, we used the “Implements Serializable” so when we pass an Intent (move from one screen to another), we’re able to pass the full record for better code management. Below, I’m passing the full Order record as an “Extra” with the name “productRecord”. When a user clicks on a given Order in the list, it will automatically pull the right data into the next screen.

In the Orders Activity, I’m “fetching” the record by getting the intent by name.

And the last major thing to take note in the file is the update call. In the MainActivity.java file, I only queried data. In this one, I’m going to be sending an update call to set the status of the Order to “Complete.” Notice the “RestRequest.getRequestForUpdate()” function, this is how the function decides to read, create, update, and delete records.

Remember the validation rule from above? It’s going to be useful in providing instant user feedback. In the event a user is trying to modify an order that is already complete, we should provide that in a simple format that is easy to understand. Without creating massive overhead or separate functions for every single reason a record couldn’t be saved, we’re going to write a single handler and make Salesforce the source of truth.

If the result comes back with a status code 400 (follows the ideas of HTTP status codes), then a validation rule was hit. You need to extract the message and show it in a Toast. Otherwise, it worked and you can tell the user of the success. If you did everything in this article correctly, your result should look like below.

Ta-da! You’ve built a fully functioning Android application which reads data and updates it. You can now build complex apps using both Salesforce as your data provider and Android as your content delivery medium. If you’d like access to the full code set, it is available here on Github.

Special side note

When I first dealt with the Salesforce SDK, I was disappointed that authentication was required to utilize the libraries included. It took a while but after digging through hundreds of resources, I found this article which describes how to make an HTTP callout prior to authentication. It’s not commonly talked about, and you could utilize extra libraries to do this, but to make managing the codebase easier, I wanted to reduce library dependencies as much as possible.

This is useful for situations where you may want to check the weather prior to the driver heading out and warning them of severe alerts. Other instances may be downloading settings you’ve designated in Salesforce which configure the app instantly without requiring major Google Play Store updates all the time. The possibilities become limitless when using Salesforce as your basis in your Android and mobile endeavors.