Sunday, May 31, 2015

Dipping Toes into Material Design

The first thing that I noticed is that the Android folks (Google) are pushing a new design philosophy (infrastructure) called Material Design starting with the Android 5.0 / API 21 release.  In order to allow for wide deployment of this design, they have included key elements into the v7 support libraries (allowing for usage in versions greater than or equal to Android 2.1 / API 7).

Incidentally, virtually 100% of Android devices in use are greater than or equal to Android 2.1 / API 7; per Dashboard | Android Developer.

To ease into Material Design for Android, thought to first spin up on AngularJS's implementation of Material Design.
Angular Material - Introduction
https://material.angularjs.org/latest/#/
The comparable elements that are in the v7 support library are:
  • Theming
  • Toolbar
  • Tabs
  • Card
  • Toast (aka., Snackbar)
Some of the challenges in getting up to speed with Angular Material were:
  • It is important to understand AngularJS to start of with.
  • Knowing CSS media queries.
  • Angular Material is build upon the new Flexbox browser feature; which takes some getting used to.
The following is a basic implementation of Angular Material.
AngularJS: Material Design Demo - 5
http://jsfiddle.net/sckmkny/0far55wa/

Why Bother with Native (Android) Development?

Before I dive into my experience of picking up Android development after a five year pivot to writing web applications, thought to share how I thought this is a good idea.

When the Android operating system started to gain traction in 2009, I decided to take my Java skills (forged in the world of enterprise Java using WebSphere by IBM) to writing mobile applications for Android. Long story short, three key observations later I switched to writing mobile applications using HTML.

  • Building mobile solutions involves delivering three applications: Android, IOS, and Web. Writing three applications, however, is prohibitively expensive for many startup companies.
  • Solutions exist to wrap web applications as Android and IOS applications, e.g.,  Apache Cordova, that expose native functionality (i.e., hybrid applications).
  • Web JavaScript MVC frameworks made writing web applications manageable (and familiar to Android application development). While there are many such frameworks, I finally settled on AngularJS due to its widespread adoption and organizational (Google) support.
More recently, an opportunity at my current employment got me to revisit the seemingly endless debate between building native (Android and IOS), hybrid (wrapped web applications), and web applications. A particularly helpful take on this is:
Can We Please Stop Fighting The Native vs. Web App Wars?http://readwrite.com/2015/02/27/native-vs-web-apps-ceasefire
After thinking about this, I came up with some observations that justified my recent foray back into Android development. By the way, I did spend a couple of days awhile ago trying to pick up IOS development but it felt distinctly different than either web or Android development; enough so that I decided to stop trying.

  • While sufficient (maybe even required) for startup companies, using wrapped web applications for established companies is less appropriate.
    • Cost is less of a factor for established companies.
    • Difficult (to impossible) to write wrapped web applications that have the same look and polish of native applications; established companies are likely more concerned about brand.
  • Web views in native applications can bring in reusable (across all solutions) web content where appropriate; thus achieving some cost reduction benefit of hybrid and web applications.
  • While the performance of devices, e.g, computer, phone, and tablet, is making the performance difference between native, hybrid, and web applications less noticeable, new lower performance devices (e.g., watches) are being developed that reintroduces the performance gaps.