How Salesforce can lead Gartner’s Mobile App Magic Quadrant

Written by

In June 2016, Gartner released their Magic Quadrant for Mobile App Development Platforms report. It looked at the major vendors within the MADP (Mobile Application Development Platform) space and evaluated them against multiple factors, including customer experience, pricing, marketing understanding, and innovation.

Gartner Magic Quadrant 20a16
Image: Gartner

Within the report, Salesforce is favourably judged and comes a clear third, both in terms of Completeness of Vision, and also for the Ability to Execute. First and second place are closely contested between IBM and Kony.

Whilst third isn’t a bad position, with the addition of MobileCaddy to your tool-belt, it’s clear that it becomes a real contender to take the lead spot.

Mobile App Testing

In the report Gartner notes “In the Salesforce App Cloud platform, mobile app testing support and its integration with third-party testing services are not such a focus area as in other MADP offerings.” Whilst this is true for apps written to be consumed within the Salesforce1 container, it certainly isn’t for custom applications built upon the Salesforce Mobile SDK.

MobileCaddy applications have their client part written in JavaScript, and as such are well supported by existing testing frameworks, services, and continuous integration setups. As well as having the client code being pushed through CI processes – for example Travis CI, Jenkins or Pipelines – we’re also able to push automated testing through real devices using open tools such as appium, as well as third-party services.

MobileCaddy Apps can be tested through 3rd part CI tools

Image: Atlassian

At our very core is the belief that app performance is paramount, and as developers, designers, and architects, we need not just our applications to be paranoid, but also our development and deployment workflows too.

Custom UI and UX

The report writes, “Customers must temper their expectations on RMAD (Rapid Mobile App Development) capabilities, because the Salesforce1 container approach to deploying apps created with App Builder poses UX limitations.” As accurate as this is for those applications that are built with and for Salesforce1, it’s certainly not the case that Salesforce customers are limited to this when it comes to application UI and UX.

With MobileCaddy you can have a fully custom UI and UX in your application, whilst retaining the incredible flexibility, scalability, and security of the Salesforce platform.

Salesforce Mobile App with Custom UI/UX through MobileCaddy

Image: MobileCaddy

At MobileCaddy we openly support and promote the use of the highly-rated Ionic Framework in providing the UI layer for Salesforce mobile apps. With the power of Ionic – it’s components, platform continuity, and performance focus – we’ve been able to deliver beautiful apps that offer 100% bespoke design. These are ideal for community applications where it’s key that the branding of the application is truly aligned with that of the task and organisation it was built for. The custom UI enabled by MobileCaddy extends right through to the App Store listings and app icons.

The Bottom Line

Salesforce is a strong player on the MADP space. With the use of MobileCaddy it can be even stronger and address the concerns that Gartner had during its evaluation. Since the report Salesforce has also strengthened and refined its own position on mobile application development with the introduction of App Cloud Mobile.

Request an evaluation today to see how MobileCaddy and a Gartner-backed MADP can give you a true mobile advantage.

If you found this article interesting, our eBook can offer much deeper insight into how to leverage Salesforce to make sure you succeed with your own enterprise mobile apps.

Creating Mobile Solutions in a Flash with the West London Salesforce1 User Group

Written by

MeetupLogo

We’re excited to be presenting at the first meet-up of the West London Salesforce1 Users and Developers Group  next Wednesday 21st January, which will take place in the Club Workspace at the Barley Mow Centre in Chiswick, London. The theme of this meet is Creating Mobile Solutions in a Flash, and we’re looking forward to hearing the group’s views on Enterprise Mobility, and listening to the hopes and fears Salesforce users have when it comes to ‘going mobile’ and the projects being undertaken by fellow developers, admins and users.

Continue reading…

London Salesforce Dev Meetup – Jan 2015

Written by

 

lightning

Yesterday myself, Paul and Justin attended the first London Salesforce Developer’s meet-up of 2015. We had all been to many in the past but were particularly excited about this one, as Doug Chasman and Skip Sauls were presenting on the much hyped Salesforce Lightning.

The meetup was hosted for the first time at the dotmailer offices near London Bridge, they provided excellent facilities which were matched only by the quality (and quantity) of pizza and beer supplied generously by the kind folk at MakePositive. So big thanks to both companies.

LonDevSFDC

Doug and Skip (though mainly Doug, as Skip had laryngitis!) talked and demo’d us through the history of Lightning, the architecture of Lightning Component, some examples and a look into the future to see what’s on the roadmap. There was a lot of information passed on, and I have to be honest and say I don’t want to (or maybe can’t) regurgitate it all here… but I will cover what I seem to believe are the main nuggets that got me thinking.

Lightning and Aura

  • Before Lightning became available to developers Salesforce had been using it internally for sometime.
  • In fact SF1 is built using Lightning.
  • Lightning is also known as Aura. Salesforce’s marketeers didn’t want to call it Visualforce2
  • Aura is Salesforce open source UI framework, and can be found on github here.
  • Anyone out there can contribute to Aura through Pull Requests, and with that their work will end up inside Salesforce and powering Lightning.
  • Aura/Lightning is built by the same team that built Visualforce
londevsfdc

Security

Doug also covered (many times) the fact that trust and security were high priorities… obviously that was great to hear. This eye on security has meant a couple of things. 1) lightning components (on the platform) live on a lightning domain. 2) Communication to/from the client/server parts of Lightning components is locked down. This point was one of the very few “guidances” that is put on how components are used.

Here are a few other points on Lightning;

  • There will be a Component Exchange, a-la AppExchange
  • The client/server comms are called Action Services. There are options to box car calls as well as other behaviours (display-last-known-good, auto-refresh, etc).
  • Offline capabilities are limited to read at present. Create and Update are on the roadmap (no dates given).
  • BIG SAFE HARBOUR – Summer ’15 should see the ability to put Lightning Components inside Visualforce pages.
  • As well as Lightning Components being available for use in Visualforce pages, Lightning Out will also enable Lightning components to be used within other containers (websites, etc).
  • The Lightning team are working closely on getting integrations with other JavaScript libraries. These include Angular, Polymer, React, Meteor, and others.

For more information on Lightning, check out the Salesforce developer site.

All-in, the session was excellent. Both guys showed passion for the platform and certainly for Lightning. If you get a chance to see them talk then I’d definitely recommend it.

Big thanks to Anup and Co. for another brilliant meetup.

Want More Salesforce?

If you have a thirst for more Salesforce goodness then come along to the Create Mobile Solutions in a Flash session of the West London Salesforce1 Users and Developers group, where our good selves will be among the presenters.

Custom Domain in Salesforce Mobile SDK Solution

Written by

When running up an app built with the Salesforce Mobile SDK there is an option to login to a custom domain. This is useful when testing against a sandbox or developer environment. The option, when running on an Android device, is accessible via the Change Server menu item which is available via the hardware menu button.

Screenshot showing menu for setting custom domain in pre 3.0 SDK

The issue comes though if your device doesn’t have a hardware button… what then?

The Solution

If an acceptable option for you is to have this custom domain hard-coded (so that it cant be changed) then you can modify some code to use your defined custom domain as the default. It is as easy as replacing a single line in one file… so let’s have a look. In the below I have commented out one line and replaced it, and in my example I’m setting the default domain to https://test.salesforce.com (as in my case I’m testing against a sandbox environment).

This means next time you run-up you can enter your custom domain login credentials without needing to switch server details.

As I have said, this is just a work-around, and is in fact fixed in the Mobile SDK v3.0. But, if you’re stuck using an older SDK then this may prove useful.

In the v3.0 SDK the login screen now looks like this, with a handy menu in the top bar.

Screenshot showing login screen with menu for setting custom domain/server

Happy coding.