Relationship counseling with Cordova
— post souped up by Andrei Draganescu and Adrian Florescu
Do you know the agency dance? One step forward, one step right, one step left, one step right, one step left, one step right, one step left, one step right, one … okay, okay i’ll stop here. The point is you’re going nowhere, but you’re doing a lot of motion.
Tired of the agency dance we’ve decided to just go ahead and build it ourselves. But, alas!, there was nobody around to write some objective C and Java for us. We’re web people. We do web stuff. We know scripting languages. We want to see instantly refreshable UIs. Sure we write software, and software is built with tools and one should choose the right tool for the job, and if you don’t know how to use the best tool you RTFM. Yet, software is not only about tools and processes, isn’t it? Software is very much an art and a craft.
We love the web. We are web people. The reason we keep so close with using web technologies to build everything we do at Vivre, is because we’re deeply in love with the transparency and the dynamic and cursive flow of the web stack.
But the open libertine web and the conservative walled gardens of the native app stores have a bad marriage. Its crippled by bad communication, prenuptial contract guilt, diverging personalities and interests, you name it.
So we decided to use Cordova, for relationship counseling!
Building with Cordova was the wisest thing as it got our web skills and the native experience in a blessed union that is now on the fast track to version 3.0.
I am writing this to detail our side of the work, the web technologies which we used to bring our app from the browser to our users’ device beloved home screen.
Backbone.js
Backbone deserves its name.
We took the small framework and implemented with it our own simple, in house toolkit. Maybe it didn’t always spell out what we had to do, and yes there was a lot of thinking, but the default project structuring offered our team the best starting point.
Our big advantage was that we knew exactly what we had to build. Having a clear picture of the product, we worked a bit so that the architecture provides as much magic as possible. Our backbone toolkit made the following magic possible:
- auto loading views
- auto loading templates
- self fetching models
- automatic rendering
- nested views
Obviously, magic in computer programming means convention. What we have in place is code that expects things to be named a certain way, and objects to have certain methods, and then the toolkit handles the rest. We found that in the case of an ultra flexible system such as Backbone.js convention over configurations is the key to agile development.
We are happy with how the toolkit works and we plan to release it as a default Backbone project setup on GitHub.
Do we recommend backbone for everything?
Well we did not build “everything”, but we can say that for normal e-commerce apps the overhead of other, more structured options might not be worth it.
Handlebars
An framework without a template engine is as useful as a bicycle for a fish.
There are literally countless resources online about handlebars and various implementation solutions, however what is worth mentioning is that without compiling your templates your app will not make it very far.
Compiling a handlebars file in the browser using the traditional Handlebars.compile(template) takes a heavy hit on the tiny device CPU.
Therefore we created a Gulp task to compile all the handlebars files into a single JS file that contains all the templates with a namespace and proper naming conventions using gulp-handlebars plugin.
With this, now we just need to pass the model results to a handlebars function and get a HTML view populated with data much faster.
REST API build with the Yii2 default component
The nicest surprise in our stack was the server side effort. Because backbone plays so nice with REST APIs we decided to build one for the use of the mobile app, and then to phase out the old, custom built, undocumented one.
Yet, if there is one nice and unique advantage of REST, then it must be the self documenting features of this architecture style added by the HATEOAS constraint.
Sure having an API that is as simple as the HTTP verbs opened doors to further the developments and add things. That obviously exposed the weakness of REST which is basically: as soon as your endpoints have side effects you will struggle to keep your api as simple as the architecture requires. However, this is a good thing. The verbs and the simple endpoints will force developers, as it did with us, to think about the API like a resource built for the future, cleaning and dropping a lot of overhead and applying the KISS principle every time.
Some of the code we had on the Yii 1 codebase was easily portable — especially models — and we did rewrite bits of the specific e-commerce logic which were dependent on Yii 1 features changed or deprecated in Yii 2.
Another tricky aspect was authentication. We implemented an OAUTH 2 authentication system to allow users to connect to clients and clients to connect to the API with the user credentials. Unfortunately the system is not a core functionality of the Yii framework and because of that there were some hoops to go through setting it all up.
Gulp
We use gulp as a middle man for out hybrid app. Below we’ve listed a few thing gulp helps us do.
Live Reload
Building the app on both platforms, or even reloading a browser page for each small change in CSS, HTML or JS is a pain.
For that we use BrowserSync to power up a server for us. The server can be accessed by anybody in our wireless network, especially our test devices. Best thing is that the CSS is injected hence no page reload, and that makes developing CSS for single page applications a breeze.
SVG
There are lots of ways of using and embedding SVGs in a web page, but since our app is a single page application, we used the <use> method.
This method implies that you inject the sprite on each page, therefore a bigger DOM, but since we actually have only one page, that will be loaded only once.
We created a sprite using svgmin plugin that injected our sprite into the body of the single HTML file and that referenced each icon with the <use> tag.
This plugin also helped us generate a list of all the icons available for our style guide.
SASS
Everybody uses SASS these days and we do too. It should be a standard or something. To simplify our SASS development we have a Gulp task in place which takes care of source maps, autoprefixing and injecting the generated CSS in the DOM.
Assets build & Cordova run on device
So, we’ve made a few changes that impact the native functionality of our app and we need to test this on a real device.
The gulp build process in our case handles the removal of the old files “www” folder, copy of the new one and running the cordova commands like “cordova build iOS”.
UI and Animations
Because of various things, some intentional some simple technological limitations, apps run faster and feel better compared to a web page. Anyone developing for Cordova so to make a web page feel like a native app.
For our UI to feel native, we used CSS transitions for our animations.
We also tried Velocity.js that worked great on most devices, but when all the functionality was in place, velocity ripped the CPU and we had junk animations.
FYI we’ll create a new post where we’ll do into detail on how to handle page transitions and states in backbone.
Cordova
Maintaining a Cordova project can be a hustle since you need to keep track of and document everything all by yourself.
By everything I mean plugins, settings and other things like generating hash keys, commands for cordova or setting for third party apps.
We’ve added in Git only the “www” files and nothing regarding cordova because our app works just fine in any browser without cordova. Therefore all the configuration are stored in a (hopefully well written) “readme.md” file, so that any new developer can get up and running in a few minutes (unless npm decides to be funny that day).
Cordova plugins
For our project we use a handful of plugins that make the user experience better than a mere web page. Here are some of the core plugins we use:
Crosswalk WebView Cordova Plugin
Since we have many new HTML5 and CSS3 features we must to use the latest Webview component provided by the OS. This where this plugin comes into play.
[Crosswalk WebView] makes your Cordova application use the Crosswalk WebView instead of the System WebView.
Hides, shows, customizes colors and triggers events on tap for the status bar. Tap on the status bar should scroll the page up on all of the app. It’s on ours too.
Every morning when we release the new campaign you’ll get a notification from us. This plugin gives us a token if the user accepts to receive notifications, we send it to AWS, they send back the notification, and the plugin shows it to our users.
Login with Facebook is as simple as clicking a button. If you use the correct plugin (the official, official one) and you set it up properly. And sometimes you go to GitHub and ask around what is wrong with your Java for android deployments.
Tracking activity is an important part for any website or app. With this plugin you can measure page views, track events and many more.
Automating Icons and Splash Screens
Keeping track of all the icon sizes Android and iOS requires is a nightmare. Fortunately the guys from Ionic made this a breeze with the command:
`ionnic resources`Read more here.
Lessons learned
Optimization is not optional. On the device CPU is precious, don’t waste it.
Cordova is heaven but the plugins are still hell.
Cache locally all that you can possibly cache. Use the first start to load stuff not in the bundle, the user is more patient at first launch.
For native like animation of the UI always mind using hardware accelerated options, free your DOM from leftover elements and don’t over do it.
Publishing
I wish there was an SFTP for app publishing. There isn’t. Once you submit, it is a black box. What comes out, you deal with it.
Xcode has a special way to hide options and processes. After we got a grip on what to do, we forgot to explain how to select the language of the app and someone from the review team ended up with a random Eastern European language they didn’t speak. One more week passed, but in the end it all went OK.
Google’s Play Store is a different story. The only thing we got stuck on is compiling for multiple platforms, which eventually worked out fine.
