Development diary week 03 - GideonPARANOID/olandroid GitHub Wiki

This week has felt like things have progressed a little slower than previous weeks, but no doubt some valuable work has been done nonetheless!

Towards the end of last week, I submitted my project outline specification - a document detailing the problem I'm trying to solve with this project, predicting tasks to be done & formalising the deliverables (one of which is this development diary). The final version is available in the doc subdirectory.

The main focus this week has been refactoring & UI development, rather than working on the visualisation. As usual, it's been a worthwhile way to spend time & the design has evolved again, delivering something which effectively solves the problems I've encountered.

Before I get onto that though, I want to discuss the idea I had last week to build an array of vertices for a manoeuvre from its constituent components so it can be constructed in one simple matrix operation after its initial construction (instead of the usual draw component, shift to component end, draw component etc.). On having a go at writing this & getting a prototype working by the end of the weekend, I realised that it was going to be basically useless as it relied on how components were currently drawn (currently a very spartan, single straight line), so I threw that idea out. I also prototyped a way of doing curved lines, having derived the equation in lecture on Thursday. While it worked, it looked kind of weird, & resulted in some curves coming to abrupt stops & generally wasn't very satisfying, so I dropped that support for the while. That'll most likely be something I'll come back to though.

The main refactor of the week involved separating out the model & view in the shape class & its child classes. The component class, which inherits methods from the shape class to draw it previously initialised its drawing setup on instantiation. Components play a crucial role in the model of the application as part of manoeuvres, & by initialising draw functions (like getting shader references) on creation meant that it would kick up a right panic if the renderer wasn't ready yet & that is only initialised when the visualisation activity (best described as a page of an Android app) is opened. This reliance meant that it was constraining the flow of the app, so I deferred the graphics initialisation until the draw function is first called, which fixed the problem & allowed the design to be more flexible & clean!

On the subject of the user interface design, this week has been pretty active. I've created an activity for the input of OLAN strings (not yet functional), & created a class to adapt a manoeuvre catalogue into a scrollable item list, which displays the OLAN for figures, descriptions & a button for adding them to a string you can build for a flight. It shouldn't be too hard to implement that button into working & do a rudimentary string parse to build a basic flight. This will provide a platform to expand upon.

It's been a pretty productive week, despite the experience of using the application not changing a lot, there's been some major changes under the hood. In the coming week I plan to finish off that interface just mentioned & expand on the visualisation, making it generally a bit clearer as to what it going on (orientation of the craft in terms of roll really).