I’m currently busy on implementing a new Text feature for the Reality Augmenter, it’s been a bit harder than I expected. I was expecting the actual OpenGL rendering to be the tricky part, but actually wasn’t too difficult. However, I hadn’t properly thought out the user interface, causing me some unexpected problems with the font system and how I was going to let the user configure the functionality.
Anyway, it’s nearly finished now, so a new update for OSX should be coming soon, and a new version for iOS a few weeks after that (depending on the review process).
Well I just finished rolling back all my new iOS features (images and custom masks) into OSX and generally cleaned up the code. I also did a lot of work extending my testing coverage over more of the core functionality after using XCode’s new code coverage feature.
Above you see my SCRUM Board, currently clear after finally consolidating the iOS app fully into my master source branch. I like having the board even though I work alone at home, it helps me to break down jobs and makes me think about exactly what each version will contain. It’s also a good reminder to work on the project.
TBH though, as it’s just me, I can get a little lax, I’ll put one note down for a new feature that’s actually about ten individual tasks for example, or I’ll suddenly start refactoring a huge bunch of code just to make one task simpler. The scrum board helps keep it all under control, especially for things like feature creep. As a sole developer, it’s quite hard to decide what features to include in an app for any release. You keeping getting ideas for new features and updates, and as you work on an app of your own making, it’s very tempting to just start working them in, pushing a final product or release ever back. Taking time to plan what you have for each release, making up all the tasks and laying them out on a board makes the whole thing look a lot more manageable. New features and updates can be put aside while still being considered in the coding of the current release.
I’m updating Unit Testing for the next OSX release and see a couple of new features in XCode.
Testing code coverage is nice, it was available before, but wasn’t the easiest to implement. It’s now built in and can be turned on from the Schemes editor, and reports turn up under the reports tab.
The actual code coverage report could be presented better, there doesn’t seem to be any order to it. My coverage isn’t too bad on the underlying model and rendering facilities, but I see some stuff I’ve missed. It also shows classes that I’ve forgotten altogether, while a couple are things I’ve overlooked or put off, A lot of them are to do with my User Interface.
Which brings me to the next added feature in XCode, UI testing. I know there are companies that provide UI testing for xcode, I didn’t see a free one… So I’d been testing manually, but finally it’s been added to XCode 7. I’ll be looking at implementing that too in the future if it looks like it’ll work.
Got rejected, but not because of the Binary, that’s good, they want a video of how to use it for the review, so I’m busy making that today. I was a bit scared they’d reject it straight away as the application is a little unusual for an iOS device, I was worried the fact it does nothing without a projector connected would just get it instantly rejected, but asking me for a video on how it’s used is encouraging.
Currently putting the finishing touches to the iOS version of the Reality Augmenter. It’s pretty much feature complete and reliable, just tweaking the user interface and adding final touches.
It’s taken a lot to get here, I wanted to share as much of the code as possible with the OSX version. I’d already stuck to an MVC design pattern which meant most of the iOS work was re-building the view aspect, and rethinking how that would work in an iOS environment. I found the storyboards very easy to pick up and good way to work, and once I’d got the hang of tab and navigation controllers, the basic app built up very quickly.
On the controller side, I’d implemented quite a few things in NSArrayControllers, which aren’t available in iOS, but there wasn’t too much going on in them so could implement some shared classes between iOS and OSX that plugged into the original array controllers and provided the functionality I needed in iOS.
The toughest part was upgrading openGL. Originally the OSX version used a legacy profile because of the Quartz Composer functionality. While there is a fixed function pipeline in ES1, I really wanted to be able to use later versions of ES, which meant upgrading the original to core profile. This means practically all of the openGL code is shared between OSX and iOS, with only different shaders supporting the differences between core and ES. I could probably work on a shader compiler to further reduce differences, but for now I just have different shaders for different versions.
Of course, now there is Metal, and Swift has been taking off too. Once I complete the iOS version, and migrate it’s new features into the OSX version, I’ll be looking to switch the code base over to Swift and Metal.