Wednesday, October 28, 2015

Learning a Whole New Tech Stack for Liftium, a Beautifully Simple Weightlifting App for Android

If you follow me on anything, you've been subject to multiple shameless plugs of Liftium for Android, a weightlifting tracking app. You'll have to forgive me for being a bit excited. I talked for years about publishing something to an app store, finally getting serious about learning iOS development starting almost two years ago. About a year ago, I had nearly finished a patient/ provider secure messaging app for iOS when the plug was pulled on the project. Go figure that after spending so much time on iOS, my first app is a collaboration on a project first targeting Android.

Lookin' good, Liftium!


It's been a thrill working on it and releasing, and since I (very infrequently) share technical bits here, I figured I'd describe some of the tools and how I learned to really enjoy working with them.

For my day job, a little over a year ago I become a full-time, full-stack web developer. I had worked on web services before, and even spent some time on an MVC app, but I had spent the vast majority of my career a) not doing full-time development, and b) most development I did in Windows client apps using a very vanilla Visual Studio configuration. I didn't have time to learn how a bunch of different technologies could work together, because my job didn't offer much time to research the right solution to the problem. If it wasn't first-party, strongly-typed, and it didn't work just by hitting a "play" button, I was afraid of it.

A big part of embracing development on Liftium was embracing a diverse technology stack that isn't available in shrink-wrap:

  • Cordova for taking a web app and compiling it into an Android APK
  • Angular.js as an MVVM-design-pattern-enforcing framework, providing guardrails around otherwise wild and messy HTML and JavaScript.
  • Grunt for "compiling" the web app, allowing us to use intermediate languages that make web technologies easier to implement, like SASS for CSS.
  • SQLite/ Persistence.js for storage. In this case, native database capabilities are exposed to our web app via a Cordova plugin, and wrapped with a nice API that tracks changes we make to objects and persists them to the database.
When doing, say, native iOS development, a lot of these things are right there in the base package. Apple gives you Core Data for persistence, Apple enforces that you'll use "the" MVC framework, Apple has ways of styling things. It's easier to get the base Apple package working because it's already there. But, even though I used to disdain un-opinionated frameworks because to me no opinion meant no guidance on how to make it work, I came to really enjoy what this toolset became, which was more like an un-opinionated federation of opinionated frameworks.

An obvious draw of Cordova is the ability to write cross-platform code. But, once you get there, the choices can be liberating, if you get over the initial feeling that they're bewildering. The web doesn't favor a particular MVC framework. I was lucky to not be struck by analysis paralysis, as my partner had already chosen Angular. But having gotten under the hood, I can appreciate how the app might work with React or Ember, and I think I could have been happy in any number of frameworks, because one nice thing about web development is, given some guardrails, JavaScript is really enjoyable to write. I wish I could write native iOS code in JavaScript (React Native is like this, but it's still young). 

I feel so bogged down opening XCode after having experienced writing a similarly-equipped client app in JavaScript. JavaScript is just so... light and fluffy. There's such little syntax to learn. I just need a text editor to write it. Once I took 15 minutes to learn promises and prototypical inheritance and such, I was off to the races. I no longer am afraid of code littered with anonymous functions. I'm kind of sad when it isn't, frankly. Compare this to how I feel when writing Objective-C block syntax. I will never, ever memorize block syntax, even if I become a full-time iOS dev someday. Even if I am writing Swift. I think Swift's block syntax replacement might be even more difficult to understand than Objective-C's.

So, the first big takeaway- you can write real client software in JavaScript, with less effort and head-scratching than the languages that you're "supposed" to do this stuff with, and it's a lot of fun. It's not that I hate Objective-C in comparison- I still like to brag to C# devs that I use pointers in off-hours- but I feel confident and capable in JavaScript, something I couldn't imagine a few years ago.

The second part is what you get when you make all these little pieces fit together. If you code regularly in an environment where everything is there for you in the IDE or someone else has put a nice API around the external dependencies and you just don't have to think about how they integrate, I recommend stuff like this. Try using SASS instead of CSS and having it build on the fly with Grunt of Gulp or Webpack. Integrate a 3rd party web service into something. Mix native and web. It's frustrating at first- it can be really, really frustrating the first time you try it and nothing fits together and everything is throwing cryptic errors on the command line. But out of these ashes come superpowers. Anything you integrate that actually works brings you closer to a place where you could write an API linking assembly code to a pizza. Going from being able to construct a clever algorithm to someone who could lay plumbing where none existed previously has been a game changer for me. It's absolutely changed what kinds of problems I feel confident taking on and the results when I do take on those hard problems that I previously thought were impossible.



No comments:

Post a Comment