Tips for Your Xamarin.Forms Dynamics CRM App

Dominic Jarvis, 19 September 2017

Having recently created a custom app that integrates with Dynamics CRM, I came across a few issues that took me a while to resolve. This post I’m sharing some of the workarounds I have for those issues.

Async, Async, Async…

When working with the mobile SDK, one of the things you’ll find is that almost everything happens asynchronously. This means all SDK calls take time to come back, and leave the app open to interaction from the user within this period of time that may lead to unintended behaviour – opening multiple Navigation pages, instantiating multiple instances of an object, creating duplicates of an object in CRM, or just throwing errors (null or otherwise), left right and centre.

Some Things You Can Do to Avoid These Issues Are:

• Make clear that there is background interaction happening.
  Whether you’re logging into the service, loading data, or simply populating the information on a page, it can be helpful to provide the user with a visual reminder that work is being done. I’ve found that Activity Indicators and Progress Bars, either used together or separately, can provide the user with enough of a visual indication to dissuade from, as so many users do, just clicking again because it’s ‘not working fast enough’. Running these for the correct period of time can be really easy, particularly for the Activity Indicator. A simple example of this is shown below:
  
  
• Disable any buttons that may cause unintended behaviour.
  When  working with CRM, as most of the calls to the SDK are asynchronous, I tend to put the bulk of my code into asynchronous methods, so I can use .NET’s ‘await’ keyword to obtain the data from the task before proceeding with operations. However, I often have a second synchronous method which fires off the same click event that disables the button. This ensures that there is no time between the button being clicked and disabled for the user to cause unintended behaviour.

Plugins and Triggered Events

When integrating your app with CRM, it’s important to note that the plugins on your target system will still run on the messages created by the calls from your mobile application. This means that performing any action that would cause the web interface to throw an error in the app will have the same result. This is often in the form of an OrganizationServiceFault. It’s important to catch these and deal with them appropriately, be it in the form of informing the user and cancelling the operation, or throwing an in-app error. Not handling these exceptions properly can cause the app to crash.

This is because the plugins act against the SDK messages, and your app uses the same SDK messages as the web interface. This means that you should expect to see the same behaviour from triggered events as well.

Data is Expensive

Data doesn’t always seem too big, but when dealing with several tens of thousands to hundreds of thousands of records, data can come at a big cost, particularly if you want to cache the data for offline use. Consider caching only required data, and for the rest simply downloading and using as needed. If your app involves retrieving all entities of a specific type, consider setting a record limit for a single view, with option to load more if required. This can greatly reduce the amount of data that is required to be stored on the device. However, if the target application has a small data set, this may not be a concern for you.