Doug has already discussed the ‘why’ for DataLocker. I’m going to write a few posts on the development of DataLocker.
We only had a small team working on the development of DataLocker, and when you are writing native code for each platform, it can get complicated. AppSense has an incredible wealth of experience when it comes to writing software for the Windows platform. We have deep levels of knowledge on pretty much every aspect of the Windows stack; from low-level drivers, all the way up to the top. Couple this experience with a continued drive to develop our skills, and it is no surprise that many of the AppSense developers are (often in their own time) expanding their skill sets on non-Windows platforms.
For me it all started when my dad bought an Amstrad CPC 464; for anyone that remembers this had a tape-drive. I mainly played games on it and wrote little BASIC programs, but he also bought a word processing application. After a while, we added a 3” external disk drive. Getting the disk drive was great, but unfortunately the word processing application still loaded from tape and saved files back to a tape. After a bit of playing around, I managed to update the word processing application to run from disk, and also load and save files to it. It was a great feeling, and I’ve never looked back.
I’ve been intrigued by the Mac for a while, so when my wife sold her car (*) to buy me an iMac for my 30th birthday a few years ago, I jumped at the chance to teach myself Objective-C, and the Cocoa and CocoaTouch frameworks. Picking up a new language, a new framework, on a new platform, and using new development tools can be a bit daunting to start with. But, as you spend more time, you become more fluent; until you find you are no longer translating every new thing back to your ‘native’ tongue.
(*) I paid for the new one ;-).
There are some similarities between the Microsoft / Apple development methods, but there are also many differences. The most fundamental difference I’ve noticed is more about the evolution of a project than the tools themselves:
When developing for Windows, there seem to be a million different ways of achieving the same thing. Often you are not quite sure if you’ve picked the right approach until you get about 90% through, you hit a roadblock, and you have to go back to the start and try a different approach. Windows is a fantastic platform to create software on, and Microsoft has a long track record of bending over backwards to all developers to do stuff, but sometimes this flexibility gives you too many options.
When developing for Mac / iOS, there seems to be only a single way of doing things. You can be completely stuck right at the start. There is no handholding, and until you figure it out, you are completely blocked. But when you do, everything slots into place such that when you get to the end, everything feels right. If, however, you can’t get past that initial hurdle, then you may as well give up.
One example of this was when we modified the UI code in the iPhone app. To display the files and folders in the app we use a table view UI control (basically, given a list of items and a bit of logic, it will create table cells with text – i.e. what you see). We originally wrote the code such that every time we get new information from Dropbox, we had to update our list of items, instruct the table view to re-draw itself, and then provide the details for each item that the table view wanted to show. This all worked fine, and there is nothing particularly wrong with this, but there is a mechanism called ‘bindings’ that means you can achieve the same thing, but with vastly less code – and any engineer will tell you, the less code you use to solve the same problem, the better.
We added the binding code, and removed our update/instruct logic. All looked good, and we’d prove it worked in a sample application, but with these changes in place, every time we launched the application, it crashed immediately. No matter how much logging we added, or how we used the debugger, the app just kept crashing – essentially all we got from the debugger was ‘something went wrong’, and no indication as to why, or where we needed to look to solve it.
After many hours of head scratching, re-reading the Apple developer documentation, and drinking coffee, we luckily managed to identify the problem. It turns out that there was a very subtle left over UI association that had been added when we’d developed the original update/instruct solution. The connection was so slight and so buried away in the developer tool, it was almost impossible to spot. But, as soon as we’d made this minor tweak, everything sprang to life and it all worked perfectly. I’m sure I’ll never make this mistake again, but I’m also sure there will be more situations like this.
Hope you’ve enjoyed this post and you’ve like the DataLocker releases. We will be following up with a few more posts, so stay tuned.
And, we’d love to hear your feedback.