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

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.


Desktop Hybrid Apps, Plugins, and IonicNative

This is the first in a series of posts on just one tranche of the future for hybrid apps; the one that sees them continue to expand their reach on to PCs and Macs as ‘Desktop Hybrid’ apps.

Desktop Hybrid Apps

And since this is ‘post number one’ in the series, let us start with an introduction to desktop hybrid apps. As with mobile hybrid apps, those for the desktop can be initially understood as applications that are written with web technologies – HTML, CSS, and JavaScript – but they reside within a native container that exposes functionality and features of the host’s OS and hardware. This exposed layer includes support for aspects such as the following;

  • Installability – As with mobile hybrid, apps can be installed on to the host OS, just like any other app
  • OS UI Integration – Desktop app icons, tray icons, native menus, etc.
  • Hardware APIs – Filesystem access, Bluetooth, cameras, etc.

On mobile devices, this container layer is supplied through technologies such as Adobe Phonegap. With the ever-increasing oomph of mobile hardware, and the rise in adoption of frameworks like Ionic, mobile hybrid apps are no longer seen as the poor cousins of native apps – with many having millions of users¹, and winning both consumer² and enterprise³ awards, including Most Innovative Mobile Solution, Salesforce Partner Awards 2016, won by the TOPS app built using MobileCaddy.

Screenshots of Apps on mobile devices

As on mobile, desktop now has its own enablers for hybrid apps. These have their containers provided by projects including Electron and nw.js. These offerings utilise Node.js to build the bridge between the JavaScript world, and that of processes which have access to standard OS features, such as the file system. The hybrid apps can also be crunched up into natively installable (and upgradeable) forms, such as MSI for Windows and dmg for Mac OS.

atom

Despite its young age, there are already many popular apps written using Electron. Companies using Electron include Microsoft, GitHub (who developed Electron), Slack, and Automattic (WordPress.com).

Our own MobileCaddy desktop offering, for full offline-enabled, custom desktop apps for Salesforce, is currently in beta and is looking amazing. It appears the appetite for installable, offline-enabled desktop clients for Salesforce is strong; if you want to find out more, request an activation code using the form below.

Hybrid vs PWAs

Before sitting down to write this article, I was already debating with myself when one should choose to build a hybrid app, rather than build a Progressive Web App (PWA). As with the overall hybrid architecture, the similarities between mobile and desktop again come into play, but this time in reference to the pros and cons that arise when questioning which route to take.

With mobile, hybrid apps have access to a whole raft of native features through Cordova plugins, whereas PWAs are limited to those provided by WEB APIs. The functionality and features you get with PWAs are increasing though – you can have “add to home screen” support, push notifications, and plenty else aside.

The situation on the desktop is very similar. PWAs have the same kind of access, but hybrid apps still (for the time being at least) have greater reach into the native layer, and are treated more like first class citizens. Hybrid apps are able to, for example, make use of native menus, tray icons, and store data outside of web storage.

I’m positive, and excited, to believe that the list of restrictions upon Web Apps will only continue to shrink, but in the meantime, let’s crack on.

One Codebase to Rule Them All

It is now only right to start thinking that, as app developers, it should be possible to have more or less a single codebase that supplies hybrid apps across the mobile and desktop landscape. This is something that the folks at Ionic have written about before, along with their intent to embrace PWAs.

In actual fact, we’re very close indeed to having a single codebase. It’s possible to write a JavaScript application that can be served as a PWA, enclosed in a Phonegap wrapper, or included in an Electron project. This means we can cover this vast landscape without the need to change barely any of the code that makes up the business logic or styling of your app. The vast majority of differences are more aligned to build tasks rather than application code.

So we’re there right? Well nearly, but not quite. Let’s say that you’re writing an app using Ionic – and so it’s an Angular SPA – and the app wants to create and access a private, persistent SQLite database… well you can do this on mobile using plugins such as Cordova SQLite Storage, and on desktop using the Node SQLite3 node package. To achieve the same functionality on mobile and desktop, we’ll be installing multiple plugins (though both eventually installed through npm, under the covers), and we’ll need to inject/reference them differently; we’re now left having to split our project into two.

For mobile we could use the IonicNative project (and let’s say our chosen plugin is supported by it), which means we’ll inject that single dependency, and use IonicNative to access the plugin, which in-turn bridges the JavaScript-to-Native divide and allows us to create and use our SQLite database. For desktop, it’s a little different. For our app to access the node package we could use Electron’s IPC to make a call from our renderer process (where our SPA is running) to the main process.

It can be seen that this difference in inclusion and access means that our codebase can’t be the same, or can it?

IonicNative to the Rescue

Here is where you’ll need to indulge me… what if IonicNative rocked up and said, “Hey, yeah we already love making life easier for devs, so ima gonna step up to the plate”. This is what I’m thinking;

Not only does IonicNative provide a wrapper to Cordova plugins for mobile, but it also has an awareness of the device it’s running on. And if it knows that it’s running inside an Electron environment, it makes an Electron IPC call instead of calling through to the Cordova plugin. And what if the Cordova plugin developers, as well as having branches of code for Android and iOS, also had a branch for Electron? This branch could support the IPC messages and interface to the native layer to fulfill the request from IonicNative.

Architecture diagram

With this architecture in place – or something similar – the application developer wouldn’t need to concern themselves with platform nuances, or managing multiple codebases. Their process could be something like;

I recently managed to kidnap Alex Muramoto – Dev Advocate for Ionic – and chatted with him through some of the above in relation to bringing MobileCaddy apps to the desktop. I’m hugely grateful for the time he spared me (he was busy writing slides for the Ionic UK Meetup) and our conversation definitely helped me to flush through some of my thoughts.

I’d love to find some spare time to put together a proof-of-concept of this, perhaps using the SQLite example above. Perhaps I’d initially start with just implementing intelligence into IonicNative to make the Electron IPC if needed, and have my project package explicitly pull in either the Cordova plugin or Node package, depending on the build target.

Summary

I hope this post triggers some thoughts and discussion and perhaps leads to a more unified future for hybrid app, right across the device landscape.

For our part, at MobileCaddy, we know that the demand is there for driving towards a single codebase for Salesforce clients on both mobile and desktop, and we know that hybrid is the answer. As part of this we’ll be keen to share our ideas, and contribute to the great projects that help enable this.

Future posts in this ‘Desktop Hybrid’ series shall look further into the topics of Salesforce, Ionic, and further analysis into the differences between hybrid and PWAs.

Footnotes and Links

  1. Sworkit – Personalised Video Workouts
  2. Untappd – Time Magazine – 50 Best Apps of 2016
  3. TOPSs – Most Innovative Mobile Solution, Salesforce Partner Awards 2016

Why Ionic is Ideal for Enterprise

ionic-formular

Let’s start with a couple of facts;

university
  1. I am – and the rest of the folk at MobileCaddy are, too – massive fans of Ionic. We’ve been using their tools and loving their work since early beta, and the incredible team there (and their community) just keep turning out more and more amazing stuff.
  2. I’ve never had training to use software, or websites. Whether for the desktop or mobile, these things are usually very straightforward to use.
  3. I’m a liar – Of course I’ve had training on apps and software – and so has everyone else I know who’s been forced to use any form of enterprise software. One company I worked for once had every employee undertake training on our new expenses software. It included a module on changing your password. For too long enterprises have forced poor software on their employees… but no more!

And what’s the point of this post? Well it’s to call-out enterprise software and to tell it that it needs to up its game. Traditionally, software given to employees to use has been given next to no time in terms of graphical design, let alone any dedicated UX focus. And don’t get me started on employee-facing mobile apps.

Perhaps the reason for this has been how tough it used to be to build good apps, maybe it’s because there wasn’t any evidence that showed the evidence of correlation between quality of the software and user adoption and productivity. It could be that there used to be a smaller mobile workforce expected to have mobile apps to assist in their everyday tasks, so maybe less investment was put in. There’s also no doubt that the pre-hybrid-app-world required larger, and more specialist, development teams… so as you can see, not everything was stacked in the favour of users getting good apps from the companies.

It’s clear though, that the number of mobile workers is growing at an incredible rate. This could be thanks to the real adoption of SaaS, perhaps due to its increased accessibility and proven stability. And with this growing workforce comes growing expectations. As I said earlier, I was trained to use internal systems at previous employers, but I’ve never had training on Amazon, Ebay, Trello, Jira, or banking apps… so why on Earth should we think it acceptable to release software to our own employees that isn’t intuitive enough, or works well enough, for them to be able to use without training? THIS STOPS HERE.

ionicon-settings

As designers, developers, CTOs, and architects, what do we need in our tool-chest to right these wrongs?

  • Outstanding Performance – If our apps don’t function well, in terms of speed and robustness, then our app isn’t performing. And if our app doesn’t perform, our users won’t use it.
  • BYOD – Users don’t want to carry around specific devices for their business tasks, would you?
  • Familiarity of UI – Sure, companies want to have full control over the branding of their apps, but that’s not the same thing as disabling the users’ muscle memory because you’ve decided to use a set of non-standard icons in your app.
  • A Standard-Based Open Stack – There’s many benefits to using standard open tools in your stack. A couple of key ones are the community support, and backing a horse that’s got a low risk of becoming neglected.

Ionic – It’s got Enterprises’ Back

Tis true, Ionic answers a whole lot of questions when it comes to turning around enterprise software.

ionic-formular

Their recognition of performance issues in mobile apps, and the impact that it can have on users, has led to them make incredible progress in enabling apps to perform beautifully, even across older versions of both iOS and Android. You simply don’t get this in other solutions. As I said, I really like what Ionic have done, across the board, but this one thing is the real key for me. Janky apps need to die.

And their out-the-box platform continuity is entirely painless. There’s no need for users to be served up Android-looking apps on iOS devices, there’s no chance that they’ll be confronted by an unfamiliar UI that makes them stumble in their tasks.

Being based upon open web standards, the hugely popular AngularJS has many benefits too;

  • Existing web developers can pick up the code with ease, they don’t necessarily need to have any bespoke training or qualifications.
  • The development of the framework and its underlying technology is all in the open.
  • There are many developers around the world building with the tools, filing bugs and fixing issues.
    Support channels are numerous and active.

The above points not only mean that there are many already trained developers out there, but also that your application relies on a single code-base, thus removing issues not only with having two sets of skills, but also with minimising other tasks further down the chain, such as testing.

What it Means for your Business

Using Ionic as part of your stack when delivering apps can be boiled down to a couple of key points – though for me my favourite aligns absolutely with our goal at MobileCaddy – which is that it enables developers to get on with engineering functions and features that drive business value.

ionicon-graph

In the same way that MobileCaddy frees up the solution designers and developers from having to re-solve the implementation of a robust, offline process, Ionic frees them up from worrying about reinventing highly performant scrolling lists of thousands of items, or having to put effort into providing familiar UIs across different OSs.

Experience of such a solution can be read about in this interview with one of our clients. They ended up with an award-winning mobile app that blew all expectations out of the water.

And now it’s time to do your bit; start giving your employees the apps and experience they deserve and expect, and trust me, you’ll be seeing the benefits too.


Ionic UK October Meetup Review

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.


Introducing the MobileCaddy CLI

It’s been hiding in the wings, but our MobileCaddy CLI v1.0.0 is here!

cli-1.0.0

 

The MobileCaddy CLI is the easiest way to use MobileCaddy to create offline first, robust and versionable mobile applications for Salesforce.com.

Using the MobileCaddy CLI you can quickly create a project structure based on one of our template applications that will allow you to have a deployable mobile application in a matter of minutes. Too good to be true? Just watch this video where we create a new mobile application using Salesforce.com as a backend.

As well as helping us create our new projects, the CLI tool gives us a few workflow benefits including;

  • Ongoing SCSS compilation and live-reload
  • JavaScript JS Hinting
  • Automatic package bundling

If you’re familiar with accessing SFDC from a localhost environment you’ll know that you have to have a CORS proxy set-up, but not to worry, the MobileCaddy CLI will manage the creation and running of that for you too.

What’s new in v1.0.0

The latest release was primarily focussed on stabilising the features we already have, but we also added the capability of defining your own project templates when starting a fresh project. This can be used, for example, if you re-use the same design patterns over-and-over and don’t want to keep re-implementing them on top of the standard MobileCaddy templates (see our Seed and Shell applications). To use a custom template the new command can now be run with a URL that links to a zip file of a project based upon one of the MobileCaddy templates.

We currently have two Ionic based templates available… have we mentioned the we LOVE Ionic?

Get it today

What? You’ve not installed it yet?

If you want to have a dig into the code the project is over on github.

We hope you enjoy it and would love to hear your feedback.

Looking for more info? Why not check out our tutorials and you’ll be mobile applications for Salesforce.com in no time at all.


End2end Testing Ionic collection-repeat with Protractor

featured-image-blog

 

I have been recently building out the end2end test suites for our MobileCaddy Seed and Shell applications. The core goal was to give Salesforce mobile application developers a starting point on which they could add their own test suites and specs, giving them a head-start when end2end testing Ionic apps. During this process I ran into a couple of “gotchas” when dealing with Ionic’s collection-repeat directive. This post should highlight the issues, propose some work-arounds and also lay the outline on how we rectify the issues we’ve seen.

This post assumes you know about Protractor, if not you can read up here, but the long-and-short is that it’s a testing tool built for AngularJS applications. It is assumes you are familiar with Ionic’s (incredibly brilliant) collection-repeat directive.

The Scenario

I’m going to use our Time & Expenses mobile application for Salesforce as our example (you can download it from github). The main screen of our application simply lists projects that are assigned to our currently logged in user. This list uses Ionic’s collection-repeat to populate the DOM with our projects, and with our application in test mode the list should contain 5 projects. What I want to do is use Protractor to end2end test that our app starts up and that this screen has 5 projects listed.

Salesforce Project List

With this in mind our application code looks something like this;

And our test like this;

We’re using the repeater locator to pull out the list of items in our collection-repeat and then we’re checking this against our expected number of projects… or at least that’s what we wanted to do.

The Issue(s)

After running our protractor test we run into the following error;

So what happened? Well actually Protractor doesn’t support collection-repeats in it’s repeater locator. That’s OK right because we can work around this and use a different locator perhaps. In our case we can use the binding locator and look for project.Name. This could be the first stab at our new code;

Let’s run our test again, and this should work right?

Wrong! Here’s what we get;

Where did that count of 20 come from? We only have 5 projects.

After digging into the Ionic code I can see that collection-repeat currently creates 20 DOM items, regardless of if there are less or not.

Hmmm… so what can we do?

The Work-Arounds

The first step, mentioned above, is to use an alternate locator instead of repeater. But this only takes us so far.

The second step (which is admittedly ugly) is to spec our test like this;

Now we’re using the binding locator and also checking that the 5th element has some content and that the 6th is empty. Of course this is not ideal, but hey, this is a work-around right… and does it work?

Woohoo!

Our (planned) Solution

There are actually two prongs to what we’re going to do to make this nicer and better;

1) Pull Request to Ionic for collection-repeat

We currently have a PR submitted to Ionic to dynamically scale the number of DOM elements created in a collection-repeat. This will remove the need to check, for example, the content of elements that shouldn’t really exist.

2) Create a protractor-ionic-locator Package

UPDATE: We have launched our protractor-ionic-locator package… check it out. This adds a custom locator to select collection-repeat lists (with more locators to follow)

We’ll update as both of these progress… but in the meantime we hope that our write-up here might save you some time when end2end testing Ionic mobile applications.


Ionic loading spinners in RC0

Following the (very exciting) release of Ionic’s Release Candidate 0 (v1.0.0-rc0) you may have found that the animated icons you had for your loading dialogues are no longer there. This is due to the version of Ionicons included by default being moved to 2.0.1, and this release has dropped the icons such as ion-loading-b, etc.

Ionic animated loading icon using ion-spinner

The reason for this is explained in this forum post and is deliberate. There is a new ion-spinner directive available that makes use of SVGs and can be used as a replacement.

We’ve put together a quick Codepen that can be used as an example. Note the extra SCSS to treat the ion-spinners in a similar manner to the icons, this is pretty but it means minimal work to get it working as a replacement. Also note the SVG targetted SCSS that shows how these can be styled.

See the Pen Ionic rc0 Loading with SVG ion-spinner by Todd Halfpenny (@toddhalfpenny) on CodePen.

I’m sure they’ll be some further enhancements to the built-in Ionic SCSS to better manage this, but for the time being this seems to be a very workable solution with our controller code looking like this;

 


Ionic UK Meetup – Jan 2015

As per our preview post, some of the MobileCaddy crew headed to the very first Ionic UK meetup… and boy what a fab evening it was. The event was organised by Sani Yusuf and Ryan Hanna and to say their efforts were clear to see would be an understatement.

The meetup took place at the excellent SkillsMatter, and they had everything that could have been asked for from a venue.

IonicUK logo

Sani Yusuf – Kick Off

An introduction to Ionic, it’s past, present and future was the starter dish for the evening. Sani took to the front in his famous Google Glass and took us through what life was like before tools like Ionic arrived on the scene. This was a time when to develop apps for mobiles meant using different languages for the different platforms. A time when these restrictions meant porting apps and having multiple, non-interchangeable teams of developers. He told us how the first wave of Hybrid apps promised to free us from these constraints and how these promises never really delivered… and then came Ionic.

Ionic, for those that don’t know, is a framework/SDK enabling folk to quickly build hybrid mobile apps using HTML5 technologies. Ionic uses the amazing Apache Cordova tools to take advantage of device features (GPS, camera, etc) as well as enabling the apps to be built into suitable formats for submission onto the different app stores (iTunes, Google Play, etc).

With Ionic came a toolset that removed some of the pains that developers were used to when initially building Cordova apps. A focus on performance meant that apps could now be built that had native like experiences… users shouldn’t/wouldn’t need to know if apps were native or hybrid. And this is what we really like about using Ionic ourselves at MobileCaddy. With every release (and keep in mind it’s still in Beta) the performance across all platforms just keeps getting better. Have I mentioned yet that we big fans of Ionic at MobileCaddy?

A quick demo was then rolled out to demonstrate just how quick it is to get started with Ionic… and if you want to see for yourself head over here. Sani joked at how you could have a $1bn app in minutes, in a way there are real serious opportunities available.

Sani and Ryan, organisers of the meetup

And just then not only did the beer and Pizza arrive, but we were also privileged to have Max Lynch (one of Ionic’s founders) join us on a Hangout.

Max Lynch – A Hangout

Max mainly focused on chatting about the new and upcoming features and tools that he and the Ionic folk were working on. Most of the focus was on the upcoming Ionic.IO. He discussed how that even though Ionic was currently enabling devs to build amazing hybrid apps that there were still pain-points and a lot more that could be done. Ionic.IO essentially delivers a platform to sit alongside the actual apps. This would deliver the following types of features;

  • Push Notifications
  • Dynamic Versioning – Being able to update your app without having to go through the app submission rigmarole.
  • Analytics
  • A/B Testing

At MobileCaddy we have already started addressing some of these issues using the Salesforce platform, for example we can already do Dynamic Versioning and have taken the idea even further with a greater level of control.

Max also talked about the recent work they have done with the Crosswalk project, and how this is further pushing increased performance on Android devices. Essentially this allows you to bundle a specific version of webkit with your APK (the binary application file that is installed on people’s devices). This has the effect of meaning, as a developer, you have a known landscape when dealing with your HTML/JS/CSS, as well as of course meaning you can take advantage of newer builds and their feature sets sooner that might otherwise have been possible.

One question came up for Max about Angular 2. His reaction was positive, saying he was excited and that Ionic for Angular 2 would be on the cards. He also mentioned that Angular 2 is pushing towards a component based framework. I’ve not really looked into Angular 2 in any great detail, but this component based framework might play very nicely with Salesforce’s Lightning components. We heard about these from Doug and Skip from Salesforce at the last London Salesforce Developer’s meetup, so see our review for more information.

Ryan Hanna – Showcase

Co-organiser Ryan was next up, with the task of showing off a few apps built with Ionic, but before I get to that I should cover some of Ryan’s background. He’s a self taught developer (using Code Academy) and has only been in the game for three or so years. What’s amazing then is the fact that he’s the sole developer on his own app Sworkit, and the success that this has had… but more about that later.

Zourist

Zourist is “an audio travel Guide to World Famous Monuments, a free mobile app which provides you authentic and reliable information so that you can visit the monument at your own pace”. It is developer by Nancy Goyal using Ionic and at the time of writing has a 5 star rating on Google Play.

Sworkit

Ryan then discussed his own app, a 4.5 star app available on both iTunes and Google Play. This is a real flagship app for Ionic, with over 3m downloads covering both OSs and is available in a Lite and Pro guise. The app is available in 13 languages, and this has been achieved using the Angular Translate module. Modules like this mean that tasks like making your app available for the international market reachable without too much effort, something that will be music to multinational organisations I’m sure.

With such a large user base I was keen to find out what Ryan’s experience had been with the accessibility of hybrid apps built with Ionic. He told me that the feedback he’d gotten so far had been very positive. My understanding is that basic HTML5 good practice pays off in the same way for apps as it does for websites.

Ryan had also mentioned something called localForage, this is a library that gives you a nice API for asynchronous storage (IndexedDB, WebSQL), resulting in an interface more akin to localStorage. We could certainly introduce something like this into our CodeFlow environment.

Todd Halfpenny – MobileCaddy

pres_small

I was up next, and took the meetup attendees on a speedy tour of how MobileCaddy can enable JavaScript developers to build enterprise grade, robust mobile applications for Salesforce. I’ll hopefully post the slides up shortly, but the key takeaways were that MobileCaddy enables;

  • JavaScript developers to build enterprise grade apps for Salesforce
  • (Secure) Offline, Data Synchronisation out the box
  • Salesforce authentication with no coding
  • A controlled application development/deployment lifecycyle, including OTA app updates.

We also demonstrated our Deploy to Salesforce feature for the first time.

Screenshot of MobileCaddy's Deploy to Salesforce Button

This allows developers to deploy new versions of their mobile applications to the Salesforce platform from within the very app they are building. I have to be honest and say that I am very excited about this, and even more so about where we see this heading. Just another tool that we hope will ease enterprise mobile application development.

Richard Sands – Angular Fullstack Ionic

A late entry to the lineup, Richard give us a whirlwind tour of his new Angular Fullstack Ionic project. I think he can explain it better than I can, so this is lifted from the Readme;

The motivation behind Angular Fullstack Ionic is to streamline the development of projects that include an API, Angular webapp and Ionic app. It’s core design principles include sharing code and assets wherever possible, creating an efficient workflow and making it super easy to start off a project with handy components available out of the box (e.g. user signup/login).

It is based on the brilliant Yeoman angular-fullstack project

His enthusiasm and passion shone through, and despite the project be very young I can see that it shows potential.

Closing Notes

The event was a great success, and I look forward to seeing more from this exciting community. And I’m sure that MobileCaddy will continue to be a part of it.


Ionic UK Launch Event

IonicUK logo

If you follow us on Social Media or have read our Dev Blog you may have noticed that we’re big fans of the Ionic Framework: “The beautiful, open source front-end SDK for developing hybrid mobile apps with HTML5.” So you can imagine our excitement when we heard there was going to be a brand spanking new IonicSDK Meet-up group on our proverbial doorstep; somewhere we can wax lyrical about the Ionic Framework, AnugularJS and building mobile applications that can be deployed everywhere.

The Ionic UK Meet-Up group is hosting it’s launch event on the 29th January in Skills Matter offices  in London. There’s a full agenda of talks and presentations: Sani Yusuf, the event organiser will get things rolling with a talk about Ionic’s, past, present and future, and a demo of some features. After a live hangout with Ionic Founder Max Lynch and the team at Ionic HQ in the US, there’ll be a showcase where group members can demo what they’ve been building with the framework.  Ryan Hanna, founder of chart-topping Ionic-built exercise app Sworkit, will be presenting some of his work, and Andrew Savoury from Adobe’s Phonegap will also be around for those that want to talk about this very successful open-source platform.

We’ll be presenting MobileCaddy during this showcase, so if you’re interested in how our suite of dev/ops tools mobilises the salesforce.com platform, come and check out our demos of seed apps built using the wonderful Ionic framework. We’d also like to demonstrate how Ionic developers can rapidly start building enterprise apps using an encrypted local store, so that the apps work fully offline with no extra development work. This is at the heart of what MobileCaddy does; for information on our design concept please read this blog post by our CEO Justin.

All in all, we’re really looking forward to what promises to be an interesting and insightful evening, and seeing how one of favourite developing platforms is being put to use. Hope to see you there! Feel free to contact us at any point with any queries on info@mobilecaddy.net. To sign up for the meet, follow this link.

MeetupLogo