Update July 12th 2018
MobileCaddy v2 is GA.
v2 versions of the MobileCaddy CLI, MobileCaddy developer libraries and a new mobilecaddy-angular component module is available.
Work has been undertaken to ensure changes/bug-fixes to the v1 branch have been merged into v2, and that v2 is now the source for both Ionic v1 and Ionic 3 apps.
We’ve further aligned to the Ionic approach to their framework, with the MobileCaddy developer libraries being vanilla JavaScript, and with the release of the mobilecaddy-angular module to bring MobileCaddy components to the Ionic v3 Angular space. These components further reduce development time and the architecture means these can be readily updated as changes are made to these by MobileCaddy.
Update 5th April 2018
Work is continuing on the updates of the MobileCaddy starter apps. Additional work has also been undertaken on the CLI during this period to allow for validation of the behaviour of the starter apps.
The timeline is unchanged.
Update 22nd March 2018
Timeline is unchanged. Focus has switched to rewriting the MobileCaddy starter apps with the emphasis on adopting the best practices from the official Angular docs.
At present bare-bones apps are running up and being built with an early alpha of the updated MobileCaddy CLI with work currently focused on porting and updating the AngularJS SyncService.
Update 9th March 2018
The timeline remains unchanged and progress continues with the refactoring of the MobileCaddy libraries. Technical milestones that have been passed include;
- Ionic 3 app running up and including the refactored libraries
- When running in CodeFlow the app will initiate the DB and create the database tables.
- Access to the MobileCaddy libraries from the developer console
- Ionic 3 app running up on device using the refactored libraries and unchanged container apps and platform package.
- When running on device the app will initiate the DB and create the database tables based upon metadata retrieval from SFDC
- Caching and Offline access is working as expected.
The current design should mean that there is reduced friction when wanting to include other 3rd party libs in projects, we hope this continues to fruition.
Update 12th November 2017
Ionic have released Ionic v3.9.2 that supports Angular 5. This release appears to have only a relatively small impact on the MobileCaddy Ionic 2+ roadmap in the guise of breaking changes (e.g. template → ng-template).
Update 3rd November 2017
New major release of Angular released. Angular 5.0. There don’t appear to be many breaking changes (or architectural ones) in this major release from a MobileCaddy standpoint. I’m sure we’ll find out more when Ionic officially release support.
Update 12th April 2017
Ionic 3.0 made its way live on 7th April. This major release has a few notable changes – primarily support for Angular 4, TypeScript 2.2, and the IonicPage page decorators. There appears to be still a few known issue to iron out, according to their blog post.
In terms of MobileCaddy impact it appears that TypeScript considered best practice and will be adopted by Ionic as the way forward. We are continuing to asses the least-impactful way to bring the MobileCaddy libraries into the TypeScript build process, but no doubt this will impact our original dates. The rate of change from the Ionic v2 release, points us to believe that this is not yet enterprise ready and as such are extending our stability window (see updated timeline below).
Update 24th March 2017
On the 23rd of March Google released Angular v4 (note they skipped version 3). Key updates should make the app bundles smaller, which is of primary concern of ours when thinking of mobile devices in poor-connectivity areas. There has been no word in Ionic support yet, we believe.
The Move Beyond Ionic v1 & AngularJS v1 – The MobileCaddy Approach and Timelines
Ionic v2 Final Release is finally here, and aren’t we glad to see it. We’ve been watching the progress on Angular v2 and Ionics v2 beta release with some excitement – and were even present when Ben Sperry – Ionic – announced their first release candidate back in Sept 2016.
And yes, this means that Ionic v2 support is on the roadmap for MobileCaddy too. With the promised performance benefits coming from Angular and the component based architecture it brings we certainly want to be able to give our partners, clients, and their users these benefits too.
As with the move from AngularJS to Angular (v2), and Ionic v1 to Ionic v2 this will very likely have some impacts to our apps, our libraries and also our CodeFlow build environment and tooling, so let’s have a look at what this might mean.
Our Current Concerns
With all the goodness that comes from moving to Ionic v2, we need to be wary of a number of factors.
- Current Ionic v2 / Angular v2 bundles sizes are just too big. This is really just a concern for Angular – and when fixed will be fine for Ionic too – but at the moment packaged app bundles are many times larger than we can accept. Work is ongoing, and these are being dramatically reduced, but we’re not there yet.
- Code / Tooling Stability – Even since the last Ionic UK meetup, where we were told that Ionic RC.0 would be accepting only bug-fixes, we’ve seen not only changes to core components but also the build tools.Changes in this area are sure highlight that we’re not at a level of maturity yet that is fit for enterprise.
- Lack of “real-world” feedback – It’s very early doors, and we’re yet to see any real feedback from heavily used consumer apps using Angular v2
- TypeScript – With the advent of Lightning brought the whole world of JavaScript to existing, experienced Salesforce developers. This is obviously a “key win” for our partners who can make use of their current developers to build out their mobile applications. With this in mind we need to take serious consideration about whether to adopt TypeScript as our default language for our Seed, Shell and Starter apps.
Enterprise doesn’t want bleeding-edge tech, it needs stability.
– Todd Halfpenny, CMTA MobileCaddy
With the above in mind, we’ve created a rough impact assessment on what a move to Ionic v1 would mean for us (at the time of writing);
MobileCaddy Core Libraries – These are the libraries that manage the local encrypted database, handle the synchronisation process, and expose the developer APIs. These libraries cannot be ported straight into an Ionic v2 app. It’s believed that at least some refactoring be undertaken to make them ready for use.
Shell, Seed, and Starter Apps – As these are the base of every MobileCaddy application, we’d need to ensure that these are re-written with the most up-to-date best practices and efficient code as possible. It is believed that these would need to be written in TypeScript to align to Ionic starter apps and tutorials.
Build Process (MC CLI) – MobileCaddy apps are not currently built with the use of the Ionic CLI. It’s thought that the move to webpack along with the optimisations features of both the Ionic and Angular CLIs (such as AOT compilation and tree-shaking) that we would try to align with these, instead of having to re-invent the wheel. This move would have knock on effects and would require some re-architecting, but is thought to be the best long-term solution.
MobileCaddy App Add-Ons – (note – added Nov 2017) As per our shell, seed, and starter applications we would need to re-write these in TypeScript and for Ionic v3.
CodeFlow Control Panel – Currently thought that there will be no impact to the CodeFlow Control Panel code, though some process around exposing it in the Ionic/Angular CLI may be required.
Documentation – Existing API documentation should remain untouched.
Tutorial – Our tutorials and cookbook examples will be required to be updated to show the current approach and syntax (e.g. in TypeScript)
Internal Test Rigs/Scripts – The move from Ionic/AngularJS v1 moves from the controllers/services structure. This has direct impact on the unit testing setup with our shell, seed apps. The changes to the MobileCaddy Core Libraries is also likely to require changes to the automated test suites.
Code Deployment Tooling – It is believed that the deployment process can remain mostly unchanged, with only minor adjustments needed to cater for the updated production-deployment commands, and packaged-app structure and contents.
CodeFlow Emulator – With the initial belief that we’ll be moving to aligning with the Ionic CLI there’ll likely be some impact around maintaining the features of the CodeFlow emulator.
Timeline last updated 12/11/2017 – please note this is an internal proposed timeline and is subject to change based on external factors and/or internal test results/architecture decision. Please contact MobileCaddy prior to any purchasing decisions.
What are MobileCaddy doing
Our core priority at the moment is to construct a flexible, future-proof, and backwards-compatible architecture to support the changes in Ionic v2 and Angular v2. The changes relating to TypeScript and build processes impact our current model somewhat, and we’re trying out a few models to see what works, and also what means least impact for the developers and administrators of MobileCaddy powered apps.
Speaking of the devs we’ve already moved to advocating the controller as syntax, and updated our seed and shell apps to utilise this. Although admittedly a smallish step, it should lessen any migration work.
Along with the above we’ve been re-visiting our build tools, and have agreed on an initial move (correct at time of writing) to make more use of the Ionic CLI and it’s own well tested functions.
What about v1?
V1 apps, and support for them, isn’t going anywhere, not for some time anyway. There’s currently nothing wrong with using Ionic v1 – it’s performs excellently and is currently at a level of stability and maturity that is well suited to applications for Salesforce customers.
Ionic have also pledged their support for v1 well into the future.
What Next?
To even get to a point of Ionic v2 Final Release we’ve seen several changes in direction and reverses in expected behaviour, so we’ll be posting updates to this article as we get them, so keep your eyes peeled.