One of Google’s main themes with web app development is preventing Jank (not pronounced Yank). They define Jank as a sluggish performance of an app. With a target refresh rate of 60 fps, an app must take 16 ms to redraw the screen before the user will notice, something that is often quite hard to do consistently without using native development technologies. The Device Agnostic Development talk discussed the train of thought you should follow when trying to improve the performance of your web app, so that it will work well on all target devices.
There was lots of time spent discussing ways to optimize website/webapp performance and load times and avoid other pitfalls of HTML5 development, which all sounded very interesting and useful. ShinobiSpy, however, couldn’t help but wonder whether getting a nice user experience really needs to be this hard? There are obviously times when HTML5 is exactly the right tool, but sometimes it just feels like a square peg of a tool, for a round hole of a problem! Certainly our experience from using HTML5 and speaking to customers all over the world is that some of the shine is coming off the HTML5 bubble. It’s still a great technology in many cases, but it’s definitely not the silver bullet it was hyped to be – at least not yet!
On other fronts, the new Gradle build system for AndroidTM apps looks like a major step forward, and it is long overdue. Gradle is a sophisticated build tool, similar to Maven, which deals with the complete build lifecycle, including build variants, dependencies, packaging and distribution. Moving from the current mess of Ant and shell scripts to a professional build tool is definitely a good idea. As was moving to stand underneath the air conditioners. Alas, ShinobiSpy digresses.
The Gradle Android plugin has facilities for build configurations (release, debug, etc) and build flavours (orthogonal to configurations, so for example free versus paid variants), with the resources and code for the various permutations they produce being automatically merged and built as required.
The plugin supports the concept of Android libraries, packaged as .aar files, which (analogous to .jar) are binary packages which can be pushed to an artefact repository. Another major addition is a test API which can be used to deploy and test built artifacts on remote testing platforms, for example spinning up simulated instances of Android devices, testing the PAK and reporting back the results.
This will be a useful feature for anyone using things like Jenkins for Continuous Integration (as the ShinobiControls team do…). It can be used on our own system or with third party providers such as Manymo. Another major improvement is the ability to specify a toolchain version in the Gradle metadata file. In the past developers have had to play catch-up every time a new SDK version is released, but it’s now possible to have more than one toolchain per SDK and choose on a project by project basis which is the most appropriate to use.