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.

Blue Ocean or Red? The Personal Finance Market and Another Way

I have a budgeting system that's worked pretty well for a few years and I think it's been improving. It started as one Google spreadsheet with one page born out of desperation, when we kept hitting the bottom of the barrel on our checking account. This sheet just gave me a general idea of how cash flow would look for the month- would I have enough in our checking account or not? Later I took all of the "set in stone" expenses from that sheet, combined them with the typical set in stone stuff on our credit cards, took the difference between that and our monthly income, and that became a monthly budget for everything else. The last two years have been just keeping an eye on what comes out of that last number and otherwise just copying over the columns month to month on everything else.

I was really excited when I heard about You Need a Budget (YNAB), as it seemed to encode into software what I thought was the most distinctive feature of my spreadsheet system- the separate budgets/ accounts, or, as I called them, "pots," for different types of spending. Like, say, allocating $100/ month to home improvement or a vacation fund. When the app went on sale at the end of 2014, I scooped it up and coded as much of my system in it as I could.

So far, it's working, and it isn't. The pots are mostly fine- I like that money rolls over into the next month but it shows how we're performing against what's currently in the pot. Entry is quick and easy and works well on computers and phones. But now I see what really was distinctive about my system. It wasn't the pots, but the handwaving I did over most of the budget. YNAB allows transactions to be automated, but I don't want to think at all about my monthly mortgage payment, other than initially subtracting it from what money I actually have to work with. If I want to get that same sense of cash flow, I need to time up these automated transactions exactly and add in my previous credit card balances. I can't really do my monthly divvy up on the quarterly water bill. I need to add credit card payments in the same place where I put the spending transactions I care about.  I've taken to just paying attention to the pots and ignoring the checking account and total values, because they look nasty and I'm not sure I trust them, and event less sure I care about them.

So, for now I think I'm keeping YNAB for entering transactions we track in detail and I'll continue with at least my monthly cash flow model. The whole ordeal has me wondering about the value of a different kind of budgeting app. The value of a budgeting app like YNAB or Mint or Quicken that strives to keep your entire financial picture by either pulling in your accounts or having you enter everything is just that- you give it everything, it should provide a perfectly picture of expenses and cash flow. But the cost is high- entering everything isn't easy, and pouring over a computer's interpretation of your credit card statement is tedious.

I want an app that just lets me hand-wave over the parts of my budget that I'm not concerned about. The mortgage payment will not change all year, nor will city taxes. I can estimate the electric bill for the year and come within $100, so I don't care about that, either. Assume that my salary is constant for the year. Ah, this is where YNAB really gets me- I can't really project anything, because I can't count on a paycheck until I get it. I get the idea that people shouldn't spend cash that isn't there, particularly for those who may have overspent or have an unstable income- key audiences for finance tracking apps. But I'm responsible enough to revise the equation if I lose my job. If I can assume I'm going to be gainfully employed for the year, I can do things like preallocate for big expenditure so I am underspending before then, and see how cash flow is affected when I will take the hit.

My working theory is that there's generally only about 25% of your budget (stuff after fixed bills, taxes, regular savings, etc.) that is really worth tracking for anyone who is not in a desperate situation cash-flow-wise. Tracking 25% should take me 1/4 of the work of tracking 100%, right? So, given an alter ego with 40 extra hours a week, I'd like to make that app. Financial tracking for lazy people who don't urgently need a financial tracking app. Probably not the best idea because it seems like there are already plenty of such apps that are well-geared towards the people who need or want them the most, but maybe it isn't a terrible idea because perhaps there are others like me who want to a bit of control without all the extra work.

A messaging app where you talk to yourself

One silly idea I've been playing with lately is what I call "Introvert Chat." The idea started when I was working on a real two-way iOS messaging app that used the excellent JSQMessagesViewController, and I was trying to think of other contexts for using the control. When you write a messaging app with such a control, obviously you accept input from the user and wait for new messages from a server for the other half of the conversation, with your app processing the output of each source in a similar way, just plopping it on a different half of the screen. Around the same time, I had read something about the deep internal conversation that introverts have with themselves at the expense of talking to others (I am personally familiar with this), and then I thought, "what if both sides of the conversation accepted input from the keyboard?"

So, it was the pairing of a technical possibility with a practical reality that is actually quite productive. The conversations inside of our heads are at least as important as those that happen with our mouths. In fact, a conversation with yourself is an oft-used writing technique (I've always enjoyed Terry Pluto's columns where he asks himself questions and answers them). The app can add something to these conversations that perhaps the average general-purpose note-taking app cannot- the guardrails of an internal conversation. As my data "schema" has sorted itself out so far, Introvert Chat enforces organization of answers under questions. The questions generally go in chronological order, but you can tap on a question to bring it to the front, and your next answer will go under that question.

The other part of the schema is topics- just as one can switch to a different question in the conversation view, one can flip between different topics- essentially other conversations with yourself. In fact, one of my next moves is to ditch the menu drawer setup and just go with a simple messaging UI a lot like Apple's texting/ iMessage app.

Tap on the "Ask" button to type out a question, then the app switches to "answer mode," waiting for your answers. Tap on a question that's already on the screen to add to it.

Tap on a question in the drawer menu to open the current topic on that question, tap a topic to switch to a different conversation with yourself.

A big part of this app is making something that I would consider using. For me, that means it syncs to the cloud so it's saved safely and is accessible from other devices. At the moment, the Evernote API looks like a great way to do this. I don't think it makes sense to sync changes in Evernote back to Introvert Chat, but formatting Introvert Chats into Evernotes for reading later makes sense.

There's a whole additional level of smarts that is needed to make this really useful- a lot of our internal conversations don't start with a question. Or maybe they start with one question and the dialog just goes on, but still has logical subdivisions that aren't necessary "the" question. This could be a whole new level of the data hierarchy, or perhaps the app could just "ask" a question at the right time. In my daily standup example above, perhaps Introvert Chat just adds the day heading automatically and I start typing under that day.

At a level beyond that, perhaps Introvert Chat could initiate conversations by asking a question out of the blue at the right time. Ask me once a week to describe a good book I'm reading, or a new app idea, or ask me what's one thing I love about my wife.