Performance issues derail even the most well designed and managed Salesforce mobile projects. The purpose of this article is to set expectations of the type of issues you are likely to face, and in broad terms, how to prepare yourself and the project team by following some of the practices we at MobileCaddy have baked into our product.
A few things to set the scene:
Before we dive in it is worth just re-iterating the challenge we set ourselves when embarking on the delivery of a Salesforce custom mobile application that is often going to be a key digital tool for our employees, partners or customers:
Delivering a custom Salesforce mobile app is not the same as delivering a Salesforce app via the browser. There will be different skills from the outset but most importantly a difference in design and methodology for delivery, operation and support.
We assume that every app is carrying out critical processes with critical data AND that resilience, especially network resilience, is non-negotiable. Even if the non-functional requirements do not specify clearly carry this assumption through every stage of the app lifecycle.
Take a DevOps approach from the outset. Through the early stages of the application lifecycle have a clear understanding of how the app will be operated, supported and enhanced and who by, as well as clarifying the platform application(s) it will run alongside and any integrations that may have an effect.
What issues can we expect?
With this in mind let’s take a look at a few classic issues (as would be reported or raised) to put some perspective around what we mean by visibility and issue identification and why it cannot be an afterthought.
My user says they performed an action on the app but they cannot see the records on the platform.
My user says their app crashes but they cannot remember exactly what they were doing.
My user reports that they cannot see the records they expect on their device.
I’m developing my app but when I try to insert some records the sync or platform update is failing.
I’m testing my app but the user cannot get access to the camera (or any other device API)
In all these instances it is possible that without the right tools and design of the mobile app we may never get to understand the issue fully. We might pick up the issue during testing, or have the issue reported once deployed. However, these reports can often come much later than the failure itself which makes analysis very difficult. Worse, we may never even be told of the failure.
This is why visibility and issue identification is so important and needs to be baked in from the design stage onwards.
Is it just my project, my app?
Judging by the calls we have when partners and clients are evaluating MobileCaddy, these types of issues, unfortunately, occur very frequently. There are a number of contributing factors to all software development issues but with a mobile project we are by design integrating what is really two applications (frontend/device and backend/platform) and on top of that working in a highly volatile environment of which we control very little.
So what should be done about it? Can we summarise best practices?
First – Let’s assume failure in the app we are building, the platform and any other external systems (and let’s make sure we have a retain/retry model built into the heart of all app to platform calls we make). As we say at MobileCaddy.. ‘Only the paranoid apps survive’
Second – make sure we build or incorporate an in-app monitoring system. Yes, this is going to be super useful for the ops and support team but with the high level of iterations in the development phase it will prove out the effort over and over again.
Third – make sure we have an active (rather than passive) alerting system. Its great we are monitoring but I want to know immediately something is amiss. I do not want to rely on reports for sure but also we want to bring confidence to the team, the business that we are on top of things.
And as a bonus Fourth, we should try to not just record but contextualise everything. “Error 5678″… this means nothing to me. “Failed to Update field Status__c due to invalid permissions”…We’ve basically solved the issue! Don’t cut corners here – there is nothing more frustrating than visibility with limited context or depth.
Here at MobileCaddy, we have attacked all of the above head on so it makes sense here to use some of our tactics and product features to explain how we may go around handling the visibility and identification of the issues above. However, if you are building your own bespoke app without the use of MobileCaddy you should still get good value but understanding our approach and incorporating in your project requirements where possible.
Now let’s cover some specifics
We have covered this previously but it absolutely vital that an in-app logging system is specified AND used. Good developers with time will naturally want to include if the system is easy to implement and the value is also returned in the dev cycle.
API recording & Logging
It is a pain and can need to be structured in a way to ensure we do not consume platform limits or too much storage, but again non-negotiable. It must be possible to easily log the incoming or outgoing responses to the platform and, hitting on an adjacent point, ensure that these are then alerted to the project team or support staff if the app is already deployed to production.
We really do not want to lose data. To that end, a simple but effective strategy is to build in a retain and re-try model when inserting or updating records from a device to the platform. At a basic level, this means if, for example, a user has lost permission to write to a field after the app has been deployed we will not lose this update but instead retain locally and retry on the next connection/sync cycle. This ideally is matched with the API logging (so we can inspect) and with an active monitoring system so we get notified.
Emulators and simulators are great but issues arise on real devices with real users. Spending the time to scope out a set of requirements to answer common/generic questions that support or QA may have along with app-specific tests (such as device-specific test calls) will have a positive pay-back from the first day of testing and of course will be inherited into production./p>
Version & dependency control and changelog visibility
This is related to the approach of the contextualising everything but often overlooked. It is no good catching all the info from a failure or issue but not knowing which version of the app or the container app, the OS or a library that was being used. And as a precursor to this good dependency control in the build phase means this visibility and checking will have a history to see where and when a change occurred which can be extremely useful to track down root causes of issues.
No matter how much disciple and skills the team brings to the table a well-trod and proven methodology for the delivery of mobile apps is crucial. This means not just the individual skills but the whole team has an understanding of the app lifecycle and how small amounts of effort and forethought can have a tremendous impact on reducing or removing issues and resolution time in subsequent stages.
And the last word on that last resort…recovery
Unfortunately, there are times where no matter what happens we cannot get the app to connect to the platform (this could be hardware or software related). For that see if you can factor in some form of in-app recovery (with the necessary security layer around it).
This is not just useful for the retrieval of any data but also for the logs that have been caught which will then help to debug and fix and bring back confidence in the app, the team and the technology.
The quality of the design, the teams, the code and the overall project management in any software project are variables that we have to balance along with budget and timeline. It’s not always perfect but ensuring app performance even with the best of the above still needs someone in the project team to lead and push for the approach above.
It’s not easy but I hope with the above at least some of the thought processes will bring some light to what can and should be achieved.
Much of the methodology outlined is automated and the features naturally built into your custom app when using the MobileCaddy Application Delivery Framework – if you’d like to take a deeper dive it’s always a pleasure to arrange a one-to-one demo.