'James Terry - Software Developer

50 ways?
July 12, 2020

Why not listen while you read 😉.

Choosing how to implement a mobile app has become reminiscent of a Paul Simon song, but rather than "...slip out the back, Jack; make a new plan, Stan; you don't need to be coy, Roy" you can "code native, David; use a declarative style, Kyhle; or code cross platform, Norm" to name just a few. (Ok, my song writing career has a long way to go.) In fact, here is a list off the top of my head of the ways you could code an app:

• Native iOS
• Native Android
• Native iOS using SwiftUI
• Native Android using Compose
• React Native
• Flutter
• Wrap a web application (Cordova and alike)

And there are permutations of each of those choices. Should you use Swift or Objective-C for iOS native applications? Kotlin or Java for native Android applications? Not to mention that the list of languages and frameworks for a wrapped web application is probably approaching infinity. And now doing a web search (not just off the top of my head) there are even more – Microsoft’s Xamarin (I should have remembered that one), Salesforce based app, Amazon’s Honeycode just to name a few.

In the end, we probably could get to 50 ways to code our mobile app, but luckily for the author and reader we can focus on a shorter list and get our app (and blog posts) done and set ourselves free.

(And if this series seems of interest, please sign up for my mailing list here, just notifications of new articles – and no annoying popup on this screen either.)

In this series of posts, we’ll implement a small app using X different technologies. For what value of X? At least 7 as listed above but maybe more. Hopefully these posts will help developers choose which tools to use when they are tasked with writing an App. We’ll compare the ease of construction, flexibility and power of each approach as we review the X examples. Choosing a technology to implement a mobile app is most important for businesses investing in app creation. So, we’ll also dive into the long-term costs and tradeoffs of each technology. These larger considerations will be applicable to programmers creating their own app for fun or for profit but especially for business owners and product managers investing in mobile technology.

We won’t be covering “back end development” per se in these posts (we can save that for a future tome). We’ll use a common back end provider, the now open source Parse platform (https://parseplatform.org). Parse has an interesting history; it was a proprietary "back end as a service" that Facebook purchased in 2011 and eventually discontinued. But to give users a path forward it was released as open source in 2016. The open source community has kept it going since. It can do everything we need for our sample app. As a part of the necessary plumbing for our App we'll work on getting that set up in the next post.

Oh yea, so what app will we make? Well, I want something that’s real enough to make our research worthwhile but small enough to get done before the data being collected is outdated. Our app will be classified advertising for used cars. Users will be able to browse cars for sale near their location and list a car of their own for sale. I’ll call it "OK Car" – and like with any idea I have, the first thing I do is register a domain – we’ll go with okcar.xyz.

Getting Started

As soon as I have an idea (or client request) for an App I can’t help but get really excited. I want to fire up my IDE, generate a project and jump right into coding! (After registering a domain of course.) I can see the app in my mind and I want to make it real, right now! But, like most things in life, a little planning can help you reach your goal more reliably and safely in the long run.

So, before I fire up my IDE, I like to use a wireframing tool called Balsamiq. This process can be done with many different tools – even paper and pencil. One great thing about Balsamiq is that it’s output intentionally looks a lot like a hand drawn diagram. This is so that you, and clients you present your design to, focus on the functionality rather than details like color and font size. Not that those aren’t important, but that part of the design comes later in the process.

Going through the process of building the wireframe is useful even before you present to any stakeholders. When I was first thinking about OK Car I envisioned users being able to chat with each other. That would be a good feature, but I realized it would probably be a bit much for our sample app, so I cut that out. Going through the wireframe process helped me size the effort needed for that feature.

Here's a link to the PDF output by Baslsamiq for the app. This is a typical first draft – not everything is in quite enough detail yet to start coding, but it’s enough to show a client the direction we’re going in. When working on a real job for a client this is an important place to stop and get feedback. You want to make sure you’ve captured what they envision. I’ll sort of be treating you, dear reader, as a pseudo client. What do you think? Does this look like the right direction for our sample app? Since we’re just starting out, I don’t expect a ton of feedback, so I’ll also be passing this by a few friends and family for feedback.

In my next post I’ll refine the wireframe with the feedback I get (and my own review) and we’ll get Parse set up as the backend to use for the app. Don’t forget to sign up for my mailing list to be notified! See you next time.