Part 2— The Mobile Client. How to build a real time data sync, multi platform app with Cordova

This is a part from a series of posts on how to build a real time data sync, multi platform app and the second part addresses the mobile client.

Today there are 5.2 billion mobile devices worldwide (compared to just 1.5 billion PCs) and every market share study shows exponentially increasing interest in mobile devices and mobile development.

From a technical perspective we need first to understand that the mobile applications can be grouped into 3 major categories:

• Native applications — that are created for a specific platform or operating system. The code is written in a specific platform language, hence is usually much faster to run, but the major downside is that you will need to write an almost entirely new application for every targeted platform
• Web applications (Progressive Web Apps)- responsive versions of the web application that can work on any mobile device running in a mobile browser. These are built using standard web application stacks, so there is a single code base, but most of the times no or limited access to native device functionality and slower performance by not being platform specific
• Hybrid applications — which are a combination of the above allowing to reuse the same code base, but packed as native applications (can be installed from platform-specific app stores) and offering access to native functionality via plugins. From a performance standpoint they sit in the middle, far better than a web application but not quite there when it comes to native application performance

The beauty of the times we’re living in is that even if your team lacks native mobile development skills, you can still develop mobile applications. This is exactly what we did by successfully building, publishing and maintaining hybrid applications. And now more than ever this should be achievable for almost any development team.

Context

Just to refresh our context, in this blog series we are presenting how we built a multi-platform personal assistant app, that would allow the user to manage and share his tasks with friends and/or his other devices in real time.

The first part of the series covered the Database decisions and architecture, and the chosen duo is CouchDB/PouchDB, the NoSQL, real time sync, offline first Databases.

In this post we will focus on the mobile client. The alternatives, criteria, pros and cons will be reviewed.

In our case, we had to overcome our lack of mobile native dev skills and found out Cordova, “an open-source mobile development framework that allows you to use standard web technologies — HTML5, CSS3, and JavaScript for cross-platform development.” which has the major benefit of one single code base.

The choice wasn’t easy when we made it, and these days it feels it would be even harder to make, but the good news is that alternatives are great and if you’re not happy with one there are others available, just make sure that the specs, constraints and goals are clear.

Criteria

When our client approached us on this new project, the very first thing that we all agreed upon was that we had to build a concept proof. We had to validate the top functional features like offline usage, real time data sync and the Drag and Drop (moving items between lists via DnD).

Of course the best user experience was (and still is) offered by native apps, but that wasn’t really an option for us because we don’t have native apps dev skills, the development costs are higher and there are more development challenges (it’s far from easy to manage a team developing a multiple platforms product).

So, when we first started looking at the options things looked a little different than they are now: Xamarin was quite attractive, React Native was starting to pick some speed but was in it’s early stages.

These days things look better with the new players on the market, and to keep things accurate will include some of the latest options (you may check this really cool Google Trend comparison):

• Xamarin. Using CouchDB/PouchDB was out of question and also we tried to see if the there are experiments with Drag and Drop. We found some options but the Drag and Drop wasn’t actually going to be performing at the expected level.
  So that wasn’t a real option, and so far it seems to have been the right choice not pursuing it, but in other projects might be provide value, even if it doesn’t look like Microsoft has lots of future plans with it.
• React Native was definitely the rival for Cordova at that time, especially since we decided to use React on the client side. The database integration would have been pretty much the same because React Native is Javascript based.
  In our tests the Drag and Drop performance was not acceptable (now there seem to be some more options) and since we couldn’t have a single code base for the UI/UX because of the different views, we had to give up on it as well. But this still is an interesting alternative, which we would gladly consider for the future thanks to its strong community, backed up by Facebook and the rich set of tools (if you plan on using it make sure you check Expo toolchain)
• Flutter was not an option at that time, but lately Google has managed to do a great job with it, and has been ever since among the market leaders. From the performance point of view it should be even better than React Native, because it compiles into native code, so the apps should run faster (React Native needs a communication bridge to the native mobile platform which makes it slower).
  Flutter has a very neat language and toolchain support in Dart, which is key to its high performance and effectiveness. Another major benefit in adopting Flutter is that it has web support via Dart Web Platform, but it doesn’t seem allow reusing a single code base.
  Someone did a awesome job in comparing Flutter and React Native, which you should definitely check out if you’re trying to decide between the two. Bottom line Flutter is a definitely an option worth considering, but in our case still wouldn’t be our top call, especially from the single code base and local database interaction points of view
• Blazor, the newcomer from Microsoft, promises a lot because it executes WASM (Web Assembly) code, as opposite to Javascript in Cordova’s case.
  It’s still single threaded, it lacks support in older browsers (and possibly other mobile browsers), it has a big initial download size, but it has the major benefit of changing the paradigm by allowing code to be written in C# (that’s for mobile client app!) and creating a seamless client/server communication bridge via SignalR.
  It has a great potential, but we’re not sure if it would have fit our criteria for DnD performance and PouchDB client integration
• Ionic is actually a Cordova with lots of prebuilt components and plugins, but that doesn’t come for free since it’s a subscription based development platform. The major advantage is that speeds up the development to a degree, but from a point onwards it would make some changes and features extremely expensive or in some cases prohibitive (from the performance point of view). The Ionic team has also a cool toolchain, StencilJS, for building PWAs, which might be a good strategic move switching gradually from Hybrid Apps to Progressive Web Apps for them
• PWA (aka Progressive Web Apps) are a very appealing alternative to build mobile apps for web developers, but currently the PWAs support is limited. Especially, on iOS the 50M limit for storage stopped us from going any further with this approach, but the wonderful news is that Cordova allows switching apps to PWAs to be done quite easily. Even though currently there seems to be no major interest (at least from Apple) to support them on iOS, we think the future will put PWAs into the light
• Electron. Even though it’s not targeting the mobile platforms, we think Electron looks like a fantastic tool for developing “cross-platform desktop applications using JavaScript, HTML and CSS.”, and that would make it the equivalent of Cordova for desktop applications, so it’s worth mentioning
• Cordova, our choice, will be detailed next. Even if it doesn’t have the same GitHub and Google Trends metrics as the leaders, it has been here for more than 7 years, has an active community, has support for all native features like (camera, gps, etc) and more than that all plugins are open source so you can always fork and fix them if you need to. And most importantly the code is a single code base of js + html + css

Except for Cordova, all the other platforms involve significantly more development time, because the biggest advantage of Cordova is the fact the the same code base can be deployed to all platforms. Another big advantage is that Javascript is the dev language used, which allows us to extend the team easily. Basically any frontend developer can be a Cordova developer.
Another factor that weighed in a lot towards our decision was our previous experience with Cordova, being able to build and publish successfully mobile apps since Cordova 3.

Cordova

Cordova is a platform that allows building mobile apps by wrapping a WebView (headless browser) that runs our web app while at the same time allowing access to native functionality

As with any choice, ours has it pros and cons too, and we’ll try to present them as objectively as possible.

Pros:

• Single code base for all platforms (web, Android, iOS)
• Plugins for every native functionality (with alternatives)
• Active community
• Javascript
• Open source code (you can always fork and fix not only plugins but even the Cordova engine or Cordova platforms, and we did it for quite a few)

Cons:

• Harder to fix specific platform issues
• Mobile OS updates sometimes affect the WebView and can break the app
• Slower than a native app on low end devices
• For animations and transitions you have to make sure you know what you’re doing and using GPU CSS optimizations to avoid flickering and other nasty side effects

When it comes to integrating the web application with Cordova and consuming native functionality the steps are nicely described in Cordova’s help but in a few generic lines it would look like this:

• Install the package and the platforms (which are a few commands, like npm install -g cordova and cordova platform add ios)
• Install the appropriate plugin (cordova plugin add cordova-plugin-camera) and configure eventually some security rules in config.xml
• Call the functionality from your web app code in Javascript navigator.camera.getPicture(cameraSuccess, cameraError, cameraOptions);

Of course, it is not always that simple and in some cases there is quite some work to get the build running (and ideally fully automated), but it’s still totally worth it.

Mentions

There are lots of things to mention, so we’ll try to present the most important concerns when building a mobile client app with Cordova, so that you can take the most informed decision:

• Access to native functionality (like the Camera example above) can be easily done via native plugins, and is usually pretty straight forward. From Screen Orientation to GPS, Network or Status Bar, all can be accessed. Even more advanced scenarios like GeoFencing can be supported
• If you’re missing a native functionality you can always build your own plugin, which is not that easy if you don’t have the platform skills, but the point is that you can do it (we did fork and adapt a few) and you just have to natively build that specific part, not the ENTIRE app!
• When a major version containing a breaking change is released, it takes a while for the plugins to get updated (being community supported), which might cause some drawbacks and frustration. But again, being open source, you can always try to fix/update, and if it’s ok why not do a PR (Pull Request) and you will get a chance to contribute as well
• Push Notifications (getting notifications even if the mobile app is turned off) can be achieved via Firebase Notifications plugin, but lately Azure Notification Hubs are available (watch out that Microsoft is migrating away from AppCenter Notifications)
• Publishing a mobile app is quite different than publishing a web app client. In the case of a web app you take the build, host it on a web server and point the DNS to it. For a mobile app you have to do some extra work like packing the Cordova build as a native build (XCode, Android Studio), creating and configuring the app in the specific application store, uploading the bundles and going through the approval process
• For iOS, the hard build (obtaining the .ipa package for the AppStore) needs to be done on a Mac, you need a developer account for publishing and there are some extra code-signing steps to be done in XCode
• For CI/CD it’s worth mentioning that a Hot Code Push mechanism is totally worth considering. It allows updating the mobile app without having to do a hard build / native app packaging which is time consuming. The good news is that there is support from Microsoft via AppCenter

Conclusions

The world is shifting focus towards mobile devices faster than ever. Since you can do so much with your phone, from taking a picture to navigating to an address, checking your email, social networking and even paying for groceries, most probably your applications will have a big benefit from being accessible on a mobile platform.

Implementing a mobile application is not that simple, and since the major platforms today are incompatible and force the development team to create an entirely different client application for each platform, the community started looking for smart ways of overcoming this. And here, hybrid applications are doing a good job.

Even if they are not suitable for each type of application (e.g. games), they can solve a series of cost issues and development management challenges because they allow a single code base to be used on all platforms, including web. Of course it comes with a cost, but compared to the alternative of building 3 completely different apps for web, iOS and Android, this is a smart way of tackling it.

Hoping that we’ve made you a little curios and offered some helpful insight, please join the discussion if there’s anything you want to share and make sure to check out the next part of the series!