Code deployment validation
With the MobileCaddy Application Delivery Framework (ADF), code deployment is made simple from a developer’s perspective, thanks to the CodeFlow development environment. CodeFlow enables one-button deployment, from the developer’s local environment up to the Salesforce platform. This bundles up the application logic, UI, and much more into one simple flow.
Following this, an extremely important step in the testing is to ensure that code has deployed successfully. By using the MobileCaddy Platform Emulator, along with the browser’s development console, developers can validate the code immediately after it’s been deployed. This is beneficial because a partially failed deployment, or missing assets, will be picked up for correction before any QA or UAT processes begin.
Once the code has been deployed, it’s always difficult to run testing on physical devices. Although this is a necessary step, it’s best to conduct initial functional testing through emulators.
As the MobileCaddy framework is built for a hybrid application approach, browser emulation is possible, and there are two specific ways to do this (one through our bespoke CodeFlow emulator and one through the MobileCaddy Platform Emulator). These allow developers and the QA team to run the app in near parity to their smartphones and tablets, without having to go through the time-consuming process of installing and re-installing on various physical devices for initial functional testing.
This is a much easier and quicker approach when needing to reveal any issues, meaning developers can resolve them without having to load the app on to a device. Testing time is significantly reduced thanks to this, and it also allows for the browser console to be used to spot errors and warnings.
API transaction visibility
Any integration between a mobile app and the Salesforce platform can be somewhat of a dark art, in the sense of working out what information is being passed to and from the platform. The MobileCaddy ADF allows full logging of every interaction through the API, which could include users installing, users upgrading, users processing records, users requesting records, or any number of different actions, and this can be turned up or down depending on the environment.
As a result, both the developer and the QA team can immediately see the results of any application code run, transmitting and querying to the platform, the results of any data inserted, updated, or queried, along with copious amounts of de-bug logging. The benefit here is that, when problems arise, developers will spend far less time trying to understand if it was the app that went wrong, or the platform, or if data issues are to blame. Any issues will be surfaced very quickly, along with the logs, allowing immediate remedial action to be taken.
For example, in a process where a record is going to be updated, it can report out if the record was available or not in the local store, and if there were any errors or warnings hit, these will create a MobileCaddy Mobile Log. That would then be pushed back up to the Salesforce platform for the developer to understand any issues encountered by the user or by themselves during testing.
Partitioned version deployment
Being able to run multiple versions of an app in the same Salesforce instance allows teams of developers to work on independent requirements, either simultaneously, or ahead of the QA and UAT teams, especially in single sandbox projects. This important advantage is achieved by allowing these versions to run in parallel, but with a partition between each other. The benefit of this is that deployment can be more frequent, and it provides visibility into each release. This feature is used all day, every day for anyone building apps with MobileCaddy, and is extremely helpful to the development process.
Post-deployment environment check
When a version of an application is migrated from one Salesforce instance to another (for example, from a development environment to a QA or UAT environment), it’s often the case that these can shift out of line, with new or missing fields, extra validation, and so on. Even with the best tooling and constant communication, there can often be misalignment between environments. This is a major cause of application failure, as it would be for all integrations, and the app code is often the first thing people assume to be the cause.
Our post-deployment environment check allows whoever is migrating the app to simply press one button, and it skims through all the metadata to ensure everything the app is referencing is present and correct, ensuring the environment is as required in terms of the app being able to do everything it needs to.
The devil is in the details…
Mobile app testing is something everyone within a project team understands and appreciates, but there’s rarely enough time accounted for in the project timeline. When there are quick patches, releases, and the inevitable last-minute requirement changes, it’s always testing time which suffers.
The MobileCaddy Application Delivery Framework though is, by definition, not just focused on the initial development process. Many of the components and tools are designed to ensure all applications are free of any bugs or defects when deployed into production. This, as well as having automated testing in place, means businesses can save significant time and money on any mobile application during the development process and, more importantly, beyond the app’s deployment.
There are many other areas of mobile app projects in which the MobileCaddy framework saves valuable time and effort for those involved. To discover more benefits, catch up on how using MobileCaddy removes the need for a number of specialist skills for developers building Salesforce mobile apps.