Best Practise App-Development — A Discussion Paper

For those who are not yet up-to-speed: cross-platform-app development is a reality. Sure, it may not (yet) have all the fancy-pants bells-and-whistles of native App development kits. But it’s really close. Unless your App absolutely requires a particular feature only found in a proprietary software-development-kit, consider XDK’s (cross-platform development kits).

Prerequisites

• Intel XDK or PhoneGap / etc.
• Research (complexity / competition / App-store policies)

Folder Pattern

Once the prerequisites are completed, create a sandbox of your App on your local machine. My folders follow this basic pattern:

— IntelXDK

— — SANDBOX

— — — ProjectName03

— — — index.html

— — — css

— — — js

— — — fonts

— — — images

— — — …

— — ProjectName01

— — ProjectName02

The Mighty Sandbox

My SANDBOX folder holds my ‘sketches’. The screaming upper case of the sandbox’s root folder name is purposeful. It can’t be missed.

Now follow these steps:

1. Build the user interface and as much functionality as is feasible that can be performed without the use of Cordova plugins. (Cordova plugins work on a smart-device, not in a sandboxy, webby environment).
2. Make a backup of the sandbox environment at least once per day. Generally, this can be done by zipping the project folder. The zipped sandbox project can then be versioned and copied to a cloud service as a further backup.
3. Once the sandboxed App is complete (and the last backup has been safely archived), I will then copy the semi-working to working file assets to a folder outside of the SANDBOX folder, but now directly under IntelXDK (I build in Intel-XDK’s development environment).
4. On an at least daily basis, I’ll create backups of the production-space project, same as the sandbox’s naming pattern. These zip files will be placed on the cloud, but in a production backup folder (and not in the sandbox’s backup folder).
5. Once the App is complete (and by complete, I mean for sale on App stores), I’ll then clean up the archives by deleting all of the old sandbox and production zips — except for the most recent zips. So, I’ll keep one sandbox version (the very last before moving to production), and the last production version. These are now renamed to ‘v01’ of the App. Should I create an upgrade, the last production zip will be where I start, and the user interface and code that doesn’t rely on Cordova will be placed into a sandbox location, where the cycle will start anew. The next released version will be ‘v02’. Probably.

What I’ve learned from this process

• Research is not foolproof. I’m using Web Audio API in my current App. What was working really really well in the sandbox is not working in the App builds. At all! Super frustrating, and it cost me a day of further research to figure out why. And a large number of JavaScript libraries.
• Toggles in fancy frameworks are not working for me — still! Buttons it is. Sigh.
• Apps can be moved back to the sandbox if necessary.
• Working code can be retrieved from any previous version, including from the sandbox. Yay!

What’s not perfect?

Do I make a backup every day? No… Shame, shame, shame. Seriously, don’t be tardy on backups.

Where is my code? I’ve got, like, 20 backups to choose from! (Six backups always feels like 20.) This scenario happened to me on my very first App. I’m sure it’ll happen again.

You know what? Finding working code in a couple of hours of hunting-and-pecking is heaps more efficient than building from scratch.

Got any tips or advice? Feel free to comment below!

This story originally appeared on creatureoftech.com.