Fitwatchr, 1 year later: $26,000 profit and 14,000 users

One year ago, David Lapekas and I released Fitwatchr, a mobile app that converts Fitbit activity into Weight Watchers points.  Following in the footsteps of other indie developers and entrepreneurs that I look up to such as Patrick McKenzie, Nathan Barry, and Pat Flynn, I’m very excited to share our experiences openly.

Humble Beginnings

The idea for Fitwatchr began after I bought a Fitbit device a few months after joining Weight Watchers.  I thought it would be useful if I could convert my Fitbit exercise into Weight Watchers activity points.  Activity trackers were just starting to take off, and so the more I thought about it, the better the idea sounded.  I decided from the beginning to create the app for multiple platforms and decided on a PhoneGap approach.  A few months of work during nights and weekends later (my front end skills were iffy at best, so this added time), I had a prototype built.  I partnered with Dave to handle all art and marketing efforts.

The Developer's Core Concepts 2014

Recently, I’ve been mentoring junior developers, offshore resources, and even answering questions about coding with friends that are just getting started.  It got me thinking - what concepts cover everything one needs to be a well rounded developer? 

• Version Control:  It doesn’t matter which one, as long as it’s used in the first place.
• Logging: Use a 3rd party library here; no need to reinvent the wheel. The idea is not how to log, but rather to learn which information is important to log, so that debugging in the future is easier.
• Storage: This can include the file system and eventually, databases.
• Connecting to external services: Many use cases require extracting data from 3rd parties and manipulating it.  Picking either a REST or SOAP API is a good start.
• Unit Testing: Even in 2014 this is ignored, but shouldn’t be.  Code coverage should be as close to 100% as possible.
• Inversion of Control (IOC) and dependency injection: These are a bit advanced, but should be covered as soon as the developer is familiar with the other core concepts.

• The Basics (HTML, CSS, JavaScript): These fundamental languages will always be used.  Furthermore, they are now being used in other platforms besides the browser, including server-side (Node.js), cars, smart watches (Pebble), and mobile apps (PhoneGap), making them highly valuable, reusable skills to have.
• HTTP: This includes understanding how the client-server model works and all the protocols that go with it.  You can’t truly become an expert on building websites, the DOM, and calling APIs without it.
• One design pattern: The current most popular one is Model View Controller (MVC).  Model View View Model (MVVM) is great too.

Open Source PhoneGap Build App Template Now Available

Sep 14, 2014 · 0 Comments
PhoneGapCordova

It started innocently enough: I built a proof-of-concept PhoneGap app that could connect to a Fitbit user’s account using OAuth.  Satisfied with the results, I kept going, adding feature after feature until I had a completed app.  Unfortunately, despite the relatively simple codebase that PhoneGap apps consist of, I still ended up with a monster on my hands!  It was time to refactor.  Through this process, I completely rethought how to separate concerns (UI, API, storage, plugins) in a PhoneGap app.  Here’s the complete breakdown - I’ve open sourced the template too!

Root

First, create a new root directory for the app (or just pull down my starter template, of course!).  In this example we’ll use “app” as the App name.  Within here will be everything related to the app, including code, tests, and app platform certificates:  

\www: All assets of the app, including code, image icons/splash screens, and PhoneGap Build configuration files.  You don’t have to name it “www” or separate the app code from tests/certificates/other metadata, but if you do, there are three benefits:

• You can zip up the folder and upload it to PhoneGap Build without unnecessary bloat being added to the compiled app.
• Should you decide to move away from the PG Build service and wish to compile the app manually using a specific platform SDK, you’re all set - PhoneGap/Cordova files are always placed into a “www” folder.
• It will automatically be ready for use with the PhoneGap Developer App, a great tool that allows you to debug your app locally on a real device.  Each time you save a file from within this folder, the files get reloaded on the test device.  This is a lot faster than uploading to PhoneGap Build, waiting for the app to build, then reloading it!

.cordova: PhoneGap App configuration files.  This can be ignored if you don’t intend to use the PhoneGap Developer App. 

\tests: All JavaScript unit tests.

\certs: All the app platform keystores and certificates that are used to digitally sign your app.

\www folder contents

index.html:  This is the single page app itself.  It should contain only HTML and CSS, and link to separate JavaScript files.  You may have a bit of initialization code, though.  For example, using KendoUI Mobile:

var app = new kendo.mobile.Application(document.body, { transition: “slide” });  

// other initialization steps, such as reloading previous app state from localStorage, etc.  

config.xml: The one file that PhoneGap Build uses for configuration when creating your app.  Included in this are the platforms to build for, deployment preferences, icon/splash screen image references, permissions required (Internet access, location awareness, etc.), and plugins used.

icon.png: You can create many icons for each device resolution, but there must always be an icon in the root of the app code directory at 512x512 pixels.

splash.png: Similar to icon.png, if you use splash screens in your app a root image must reside in the main directory.

\icons folder: This contains all icon sets, neatly arranged into separate folders for each platform (\android, \ios, and on).

\splash folder: Exactly like the icons folder, but for splash screens.

\img folder: This contains all static images used in the app, from loading gifs to other custom pics.

\styles folder: This contains all CSS files.

\scripts folder: This contains all JavaScript code libraries.  Within here, I have the following:

• \kendo folder: While technically containing both CSS and JavaScript, this is the open source Kendo UI Mobile framework used for creating a single page application.
• controller.js: The main app controller that ties all app dependencies together, including UI interaction, user management, and data storage (localStorage, databases).
• phonegapAppPlugins.js: All PhoneGap plugin helper code. This IIFE encapsulates plugin API’s here rather than incorporating them directly so that you can test/run your app in the browser (where they are not available of course).  I built this with extendability in mind, making it easy to add other plugins as necessary.  Check it out on GitHub.
• dataRepository.js: This encompasses any data source.  In my case, it was the Fitbit API calls.  Using dependency injection in controller.js, I can now use any 3rd party API that I wish or test locally by not calling any external service.
• viewModel.js: If you happen to use a MVVM style when building an app, it’s helpful to split the view model code into its own file.
• Other JavaScript files: Any other code libraries.

Finalized structure: (generated using ‘tree /F’ cmd)

This is how I structure my PhoneGap Build apps.  If you have any ideas on how to enhance this, please let me know in the comments or submit a pull request on GitHub.

• ««
• «
• 18
• 19
• 20
• 21
• 22
• »
• »»