Once your client has been registered, you could start with creating your own Android application.

In your command line, move to the directory where you want to create your mobile project and execute the following command.

This will prompt for the following user inputs.

1. Name of your Mobile App (For e.g., Lead Approver).
2. Desired Java package name of your Mobile App (For e.g., com.zoho.test).
3. Zoho OAuth Client ID (obtained during app registration).
4. Zoho OAuth Client Secret (obtained during app registration).
5. Zoho OAuth Redirect URL (obtained during app registration).

On successfully executing the above command, a project folder will be created in the same directory. The name of the project folder will be the same as the Mobile App's name.

Note

• By default, apps created are complied on and targeted for Android API level 26 (Oreo). However, you could change this to your required API level in the app’s build.gradle.
• Also, please note that switching the API levels may require you to handle any missing dependencies for the new API level.
  

Run the Project

The newly created project is actually a demo Android app, that can be run instantly using Android studio.

1. Open Android Studio.
2. Click File > New > Import Project, then choose the newly created project folder and click Open.
   The newly created demo app will be opened as an Android project.
3. Install any missing dependencies as recommended by Gradle, if required.
4. Upon successful build of Gradle, run this project into an emulator.
   The app will open with a Zoho login screen in the emulator.
5. Log in with your Zoho CRM credentials and view your data with the demo app.

Extend the App

Once your project is successfully built and run, you could further design and create new screens and functionalities for your app as per your requirements. There are no front-end restrictions in developing your app. However, to ease user authentication, please make sure to take note of the following points while designing your app.

To handle log in/log out

1. To handle user login properly, launch activity is already configured in the SDK to make sure that only users who are logged in are able to view the data of the applications.
   
   • However, if you want to show your own customized login screen, give your custom login class package to customLoginActivityClass in app_configuration.properties. we launch your customLoginClass as launcher activity, no need to mention this class as launcher in your manifest. To ensure smooth functionality, please make sure that you are starting ZCRMLoginActivity intent from your custom launch activity, to initiate the login process.
   • While writing a custom launch activity, please make sure that you are not making any calls to Zoho CRM, without invoking ZCRMLoginActivity.
2. To handle user logout, the activity where you handle the onClick call of your logout button must extend the ZCRMBaseActivity and its onClick method should call super.logout().

In app_configuration.properties file

1. mainActivityClass (mandatory) - Mention your main class package (the class that starts after the login activity)
2. oauthScopes (mandatory) - Samples scopes are already mentioned in the created property file, you can change the scopes as per your need. Learn more
3. accessType (optional) - Type of environment in CRM
   
   • Production - Environment that have active paying users accessing critical business data.
   • Development - Environments where you can extend, integrate and develop without affecting your production environments.
   • Sandbox - Environments specifically used for testing application functionality before deploying to production or releasing to customers.
4. minLogLevel (optional) - Mention your preferred log level here ( ALL , FINEST , TRACE , DEBUG , CONFIG , INFO , WARNING , ERROR , OFF).
5. domainSuffix (optional) - Multi DC support.
   
   • us - www.zohoapis.com
   • eu - www.zohoapis.eu
   • cn - www.zohoapis.com.cn
6. portalID (optional) - Mention your CRM Portal Id (Ex : 65468393). No need to mention "portalID" within properties file, if you do not have one.
7. showSignUp (optional) - Give the value as true if you provide signup facility in your app, else give false.
8. customLoginActivityClass(Optional) - Mention your launcher activity class package. From that launcher class, you can customize your login by starting ZCRMLoginActivity's class intent.

app_configuration.properties

The file will be available at the following path:
project home > app > src > main > assets > app_configuration.properties.

You could also add any properties and values of your own, if required. Invoking ZCRMSDKConfigUtil.getConfigValue(propertyName); at any part of your Java code after the app startup will give you the values of properties that you add to this file.

Zoho CRM API wrappers

To ease data access through Zoho CRM Rest APIs, the built-in API SDKs for Zoho CRM shall be used to access CRM data through APIs. This layer takes care of your API authentication (generating and refreshing OAuth access tokens), API response and request structures and returns Java objects wrapping the API responses.

Hence, an API call would just be a method call for the client app.

Please refer from the Class hierarchy section of the Zoho CRM Java SDK documentation.

SDK Data Access wrappers

In addition to the above wrapping of Zoho CRM APIs, in order to avoid unnecessary API calls, essential module metadata are cached by the SDK in the device’s local storage.

Currently, CRM data (records) are not cached and only metadata of modules such as layouts, sections, fields, custom view details are cached.

ZCRMCachedModule

Some additional metadata caching is done with ZCRMCachedModule. This extends the ZCRMModule class of the Zoho CRM API Client Library. This class provides the following methods.

• getLayouts - returns all the layouts of the module as a BulkAPIResponse.
• getCustomViews - returns all the custom view details of the module as a BulkAPIResponse.

Refreshing the Cache

ZCRMCachedModule stores and uses the metadata information of modules and form layouts cached in the device’s local storage. The SDK refreshes the stored metadata of a module for every 12 hours.

In case, you want to force the SDK to drop the cache (Example: If you intend to provide something like a swipe to refresh in your app) and refresh the metadata through a Zoho CRM API call, you can force it by setting the refreshCache flag provided in the overloaded versions of the above methods. A sample invocation is given below.