The Move Beyond Ionic v1 & AngularJS v1 – The MobileCaddy Approach and Timelines

Written by

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/17 - 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.

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.

MobileCaddy Dev Tips – Using the console

Written by

The developer tools available in modern browsers are just mind blowing, and we love them here at MobileCaddy. In this post I’m going to cover a couple of tips on how I use the JavaScript console to help me build and debug my MobileCaddy apps.

Calling Angular Services from the Console

Did you know you can call an Angular service from JS console? I didn’t.

angular-service-console-closeup

 

I honestly love the fact that you can do this, but I can’t remember where I first heard about it, so sorry for not crediting a source.

Let’s say you have a service called MyService with a function myFunction(), but it’s not behaving as you thought. You can call this function with these commands in the console;

How cool is that?

Calling MobileCaddy Utils from the Console

In the same light as the above you can call the MobileCaddy API from the console too.

mobilecaddy-utils-js-console-closeup

 

Let’s say you are having trouble with a smartSql call not returning what you want, or you want to make sure that you’re table contains the data you thought it did.

In the 2nd line I’m calling the MobileCaddy readRecords function passing in the “MC_Time_Expenses__ap” table name and, if the promise resolves I will log the output to the console, and if the call fails I will get a console error.

I have actually added the above two examples into the Sources –> Snippets in my Chrome dev tools so they’re easily accessible, and I can just copy, paste and modify them as I need to.

These two small tips have helped me no end, I hope they do the same for you too.

London AngularJS Meetup – March Review

Written by

A very hectic few months has meant that I hadn’t been to an AngularJS meetup in quite some time, so I was looking forward to getting along again. And with the topic being AngularJS Performance – Tuning the Engine I was doubly set on making time for it.

The meetup was again held at the Bloomberg office at Moorgate, and as with the previous meetup there their food did not fail to impress – “Chicken Caesar on flatbread with a quail’s egg” canapés. As for the rest of the venue it’s perfectly suited to a large meetup. Huge thanks to them for hosting.

Tuning the Engine – Todd Motto

I’d heard of Todd before, though I wasn’t even following him on Twitter (I have rectified that now) so I wasn’t sure what to expect. Todd is a developer advocate at Telerik, who provide developer tools for desktop and mobile apps.

His talk was originally going to be called AngularJS: The Performance Parts but he’d updated it to suit the story of his presentation. At MobileCaddy performance is key, and potentially any tweak that can be made to improve a desktop JavaScript application has an even greater impact on performance when run on a mobile device.

digest

 

Todd’s talk was split into two main parts, the first being some educational coverage of the Angular event loop and its $digest cycle, and the second covering some things you could do to help your app’s performance, as informed by the first part.

The slides for the talk are available here.

Angular Event Loop & $digest Cycle

First up, Todd talked us briefly through the Angular event loop (or should that be AngularJS event loop?). He showed us that it looks like the below (thanks to Todd for the image), with events from the DOM (change, click, blur etc) prompting a chain of events that results in a run (or two) of the Angular $digest cycle that generally ends up in the DOM being re-rendered with updates.

angular-event-loop

 

He went further into the $digest cycle next, covering $rootsScope, $scopes and $$watchers. This slowly built up a picture of how these, especially the $$watchers can impact AngularJS performance of an app. This idea, on a general scale, was one I was already familiar with, but he then mentioned something that I wasn’t aware of. When you assign a value to $scope it does not create a watcher for it, a watcher is created when interpolating a value in the view;

someController.js

someTemplate.html

During the running through of the above, Todd showed us a very basic demo, and Angular uses the same techniques internally.

Tweaking

The second part of the talk covered a few techniques that can be used to make the most of the way Angular works, and one or two that, for me at least, seemed to appear from left field.

I don’t want to re-produce his talk here as I’d rather you use his material for that (useful links below). But I was previously unaware of a particularly interesting one, so I thought I’d cover it briefly as well as bullet-pointing some of the areas covered;

  • Reducing the $digest frequency
  • Optimising the use of ng-repeat
  • Speeding up filtering (using controller filters)
  • $digest batching
  • Production Settings

Disable Debug Info – You can remove unwanted (for production) bindings and class names by disabling the Angular Debug Info config. It’s a one liner in your config block;

I have yet to try this out myself, but I’ll update here once I have to see what impact this has. I have high hopes as the official AngularJS docs state a “significant performance boost.” Note though that doing this at build time might not be ideal as protractor and batarang (among others?) need it enabled to work.

Useful Links

Wrap Up

It was another really useful and interesting meetup, and as well as the talk itself being great I also got the chance to chat to a couple of folk I’d met at previous events: one of whom had actually seen me talk about how MobileCaddy and Ionic can be used to create offline mobile Salesforce apps – what a small world.

 

Big thanks should go to the event sponsors and also to Ed and Josh for organising another really good meetup, I really hope that time allows me to make the next one.

 

Adopting the Angular Style Guide

Written by

This week we pushed a considerable update to our seed and shell apps and I thought I’d give some thoughts as to what they included, why they were done and what the future holds for them too.

For those of you that don’t know, our shell apps are repositories that can be used as starting points when first beginning the process of building mobile apps for Salesforce. They contain some skeleton code as well as the dependencies needed to install all the tooling-goodness that MobileCaddy provides to make the app building process and breeze and a joy. Our seed apps are similar, but instead of a skeleton app they are a full blown demo apps, useful if you want to quickly see an application in action.

What changed?

Well, we’d known for a while that our current shell apps could be improved when it came to scaling out to full enterprise requirements and use cases… and then we came across this John Papa talk on his Angular Style Guide that he presented at ng-conf.

This led us to his style guide over on github and this gave us a clear way forward, and we definitely recommend you give it a read.

From this list of recommendations we have picked off some of the bigger changes and they’re now in the shell and seed apps that are used by our MobileCaddy CLI tool when you start off a new project. The changes included in the lastest release are;

Why did you do this?

The style guide mentioned above does a really great job of explaining the benefits of each, but along with all of that comes the alignment to one of our favourite taglines here at MobileCaddy, an app is for life, not just for Christmas. A mobile app should be around for many, many years, delivering value to your business day-after-day; but it shouldn’t stagnate, it should evolve along with your business and it’s demands.

An app is for life, not just Christmas

The approach outlined in John Papa’s guide allows for good code management and maintainability. It means that a team of developers could be working on it at the same time. It means that a new developer, perhaps a contractor, should be able to take a look at the project and it’s structure and known where to look for relevant code and functionality relating to a change or bug. It means your application will be in the best state to facilitate updates and fixes.

And are you done?

Oh no… there are a host of other items in the guide that we want to take on too, and these should be rolling out to our public repos once tested over the coming weeks.

 

Ionic UK October Meetup Review

Written by

This month’s meetup was a special one for the Ioinc UK group… we had Ionic Royalty in the house!

Yes! Max Lynch and Perry Govier joined us following their time at the AngularConnect conference, and we were all honoured and pleased to get the chance to hear from them and have a good ol’ chat.

Max was keen to mention how he admired the Ionic UK group, especially as it was the BIGGEST meetup group, even including the ones near their home town of Maddison.

Ionic 2 – Perry Govier

Ionic2

Perry gave us a run through of the slides that Adam Bradley showed at the AngularConnect conference, but talked through them in a way that an audience who already knew Ionic (from the V1 days… aah… I remember like them like it was yesterday).

We skipped through some of the initial slides (they can be found here) and moved quickly onto the technical differences of V2. Of course one of the primary changes is that it’s built on Angular 2, and as such gets a lot of the benefits of that with it… importantly this includes the speed improvements, which on mobile are very key. I was hoping to find some performance comparisons but I haven’t come across any yet.

Perry mentioned that a lot has changed since V1, not just with Ionic but with all the technology surrounding it. We now have better, faster devices, improved web APIs, fewer poor devices (through churn) and, of course, improved browse engines. As for Ionic though there are also a lot of changes. I suggest reading through the initial blog post from Ionic on V2 as well as the slides and even watching Adam’s presentation from AngularConnect.

 

As a quick summary though, here are a few of the changes that I’ve noted;

  • Performance – Yes, I’ve mentioned this already… but it’s so key when dealing with app experience on mobile devices. This is really as good as native.
  • Move away from using CSS classes to define Ionic behaviour. Ionic elements are now all defined through directives and as attributes. Not only does this remove ambiguity from the “best practices” but it also has the positive side-affect that CSS specificity should make it easier to over-ride any Ionic styles.
  • Ionicons v3 – These are improved, all SVG and also match up nicely with the native icons on both IOS and Android.
  • Android Material Design is now an integral part of the experience on Android devices.
  • Routing – This is one of the major internal changes I believe. The Ionic team’s approach was to try to make it easy to programatically take control of the app’s navigation system. It should now be possible to have quite complex navigation support. And the interesting thing about areas such as navigation is that something that is technically complex can really map to something very intuitive from the user’s point of view.
  • Animations – Ionic 2 takes advantage of the Web Animation API to allow for JavaScript controlled animations that can take advantage hardware acceleration. This is a big deal for animation performance on Android devices.

There are other areas of change too, including the support for TypeScript, JS ES6 and the bundling of the ng-Cordova type interfaces.

Although Ionic 2 currently wears an alpha badge Max said that this was based upon the core reliance on Angular 2, rather than the internal state of Ionic 2… a nice sign of confidence.

I asked about ongoing support for V1 from the Ionic team and was told that this is likely to be around till the take-up of version 2 has at least surpassed that of V1, so we should feel pretty comfortable with this.

From a MobileCaddy point of view we hope to have versions of our Seed and Shell applications written in TypeScript, running with Ionic 2 in the near future. We’re definitely excited about the prospect of performance improvements and can’t wait to see some Salesforce mobile applications written in Ionic 2 on-top of Angular 2.

Ionic 1 – Sani Yusuf

Meetup co-organiser Sani gave us a quick run-through over some of the (our) much-loved Ionic V1 features and implementations… I won’t go over this here, but if you’re wondering “what’s so cool” about Ionic then I can only suggest you give yourself some time to have a go at running up an app… you’ll only need half-an-hour.

asim_perry_sani

Showcase

I really enjoyed the previous meet-up’s showcase segment and was pleased to see it have another slot. In this part of the meetup folk are invited up to talk about projects they are working on, would like to be working on, etc… it’s great stuff.

Jambuster – A real time traffic monitoring app built for Londoners. With the app you can set routes and times so that you only see the information relevant to you. The app allows you to see live traffic cam statuses and pictures. The chap that built was an old-skool dev, building the backend with Perl, Emacs and sqlite. I can’t find a link to the app unfortunately… but I’m on the hunt for it. The developer is after some cash and users to test it.

Jasper – 19 year old Alex Emedeme gave a quick pitch of his app Jasper that “… helps friends experience the places they’ll actually love.Plan it. Vote on it. Do it“. It looks like a potentially useful application for those wanting to meet with friends but always seem to struggle finding a place that suits everyone. Alex came across very comfortable and knowledgeable about his app and I can only wish him the best.

Electric Jukebox –  Electric Jukebox gave us a hiring pitch for their product, which by the looks of things is really going places… so if you’re a talented Angular/Ionic dev then why not get in touch with them?

Ionic in Space  – (well sort of)… Tom Halfpenny (what a great name) demoed the app that helped them become finalists in Nasa’s International Space Apps Challenge. And he gave props to Ionic for helping deliver the app development speed. Here’s a video of their “Stereo Vision” app in action…

Wrap Up

You’re probably not going to be surprised to hear that I really enjoyed the meetup again. The mixture of knowledgeable talks, interesting showcase and great post-meetup chats and beers made it almost perfect. Almost? yes, sadly I missed out on pizza… so perhaps there could another 2 or 3 ordered next time as I think a few people didn’t get any.

Regardless, thanks go to all the speakers and folk for getting up during the showcase… and of course to Sani and Ryan for organising… oh and the sponsors for helping out with beer (of which there was enough, I think), pizza and venue.