OK, so if you know me personally, please stop reading for a moment now and imagine me singing to the tune of that Sting’s song:
Alien. I’m a total alien. I’m a Lisper in Java-laaaaand.
If you don’t know me, never mind. I’m weird.
Breaking news: the solution of the positioning problem works! I was a bit afraid that the code in the Runnable won’t see the right DrawingView object (and in fact, using this didn’t work), it turns out that lexical scoping saved my ass. Never thought that would happen. (Although after some googling it turned out that I had to declare the “outer” cariable final, since Java apparently does not support real closures! Come on, Java. Seriously? Scheme could do that in 1975 – twenty years before Java. The low-budget Lua could do that in 1993 – two years before Java. I knew Java wasn’t the best programming language ever, but I didn’t expect it to be that primitive and behind the times!)
Now that I have a working something, I have to stop for a moment and think. What should I do next?
My goal is not yet to support any actual programming, but to (more or less) finish the interactive drawing part.
- I definitely need to solve the positioning problem: the turtle has to start in the center regardless of the resolution. As I mentioned previously, this is easy.
- I have to rethink the datastructure I use for remembering the lines to draw. Since
canvas.drawLineis not enough – I will needcanvas.drawLinesinstead – I’ll probably have to store a series of polylines. It seems that the best way to do this will be to use aPathobject and thecanvas.drawPathmethod. (If I had known about its existence, I wouldn’t use theArrayListof lines, of course – but it’s actually good that I didn’t know about paths, because I could train using anArrayList. It’s a win-win.) This means I’ll no longer have to store the set of lines myself, but instead I’ll need a set of paths. (One path is not enough if we allow the user to change the line color or width – see below.) - I want to add a few buttons, to support more general drawings; in particular, I need pen-up/pen-down operations. While I’m at it, I might as well add controls for choosing color, line width and (maybe) line style (do we need dashed lines? I’m not sure…) And probably the most interesting setting at this moment: what happens when the turtle hits the screen border? In classical Logo, there were three settings: the screen could either be a view onto a much larger plane, where the turtle could go outside the screen (I don’t like this idea, since it’s easy to lose track of the turtle then!), or a “fenced” area, so that the turtle could not go outside (this might be a good idea for the default, since it might be the least surprising option), or a torus, so that the turtle going out to the left reappears on the right (which makes the most sense for me as a mathematician). Of course, I could reimplement all three, but why stop there? What if the top and bottom work like the “fence”, while the left and right are torus-like? And why stop with a torus when I can have a Klein bottle? And probably the most interesting possibility, where the turtle bounces of the walls? There are quite a few possibilities here, and some of them seem worth exploring. (Remember the name I gave that app? It was about geometry and exploring, after all!)
- And while I’ll modify the layout, it will a good moment to support a landscape layout on a tablet. And this in turn will be a good opportunity to explore what happens when the phone or tablet is rotated. I’m wondering what’s going to happen if I just leave at as it is (I’m pretty sure the drawing will be preserved, since I have it redrawn in
onDrawanyway). The problem is, does it really make sense? I mean, if the screen is only a view on a larger plane, why not, but what about the “fence” or “bounce” settings? For them, supporting rotation either does not make sense at all or is extremely counterintuitive. We’ll see. - Last but not least, I want to actually have a visible turtle. Currently it’s invisible, and it mustn’t stay that way. I think that I’ll go for simplicity (at least for now) and make it from a png bitmap saved into resources. (This will need some usual Android/Java juggling with classes, since there are probably two dozens of levels of abstraction to get from a png file to something that can be actually displayed, but I’m starting to get accustomed to it.)
- I currently do some coding, but I hardly do any design. And I mean “design” in the technical sense – design of the application itself, not graphical design. (The latter is trivial to change at any time.) This might hit me hard later, when I want to add more features. I guess it might be a good moment to read something on design patterns (I did read something about them some time ago, but now that I actually dipped a toe in Java, those ideas might actually resonate – they may be solution to concrete problems I encountered personally as opposed to some theoretical deliberations. Also, since keeping the structure consisting of quite a few layers of abstraction is hard (and I know what I’m saying, I’m a mathematician!), I need some notation to help me. While I’m quite fluent in mathematical notation, it won’t help me here. I guess it’s time to learn some UML… Also, in some Free Time™ I’m going to do a bit of research on tools facilitating creating UML diagrams. While I like the command-line-friendly, write-first-compile-then approach of LaTeX and friends, this doesn’t make much sense here: the whole point is to have instant feedback and be able to change the structure on the fly, so this is probably one of these 0.1% cases when it actually makes sense to use the mouse (though of course the more keyboard shortcuts, the better!)
And by the way, let me mention one thing I’ve learned recently, which is nice, but not important enough to deserve a separate blog post. It is the toString() method each object can have; very useful for debugging. It should return a “string representation” of an object, used when the object is used in a “string context”, like in
Log.d(TAG, "Object value is " + object);
Probably obvious for those Java veterans, but I didn’t know about it at first. This is really useful!