It’s time to move on from the character-based visualisations of the board and the tiles, and create some views.
Each tile will be represented with a view, and the board will be a view. Placed tiles will be added as subviews of the board, which will simplify the drawing and positioning logic.
So far my
Boardmodel is smart enough to tell if a
Tilecan be placed in a specific location. Now I need to think about what happens when the player actually places the tile. How does the board update its model? What needs to happen here?
It’s time to think about some game logic. The first thing a player will do is try to place a
Board. How can I tell if the move should be allowed?
To solve this problem I ended up creating a
GeneratorType, which is the main focus of this part.
In part one I went through the process of building the Tile model objects for my Pentominoes puzzle app. In this part I will talk about making the Board, and what I learned about protocols and default implementations in the process.
My daughter and I are members of At-Bristol, a most excellent interactive science centre in Bristol. On a recent visit she was captivated by a “Pentominoes” puzzle. Pentominoes are the twelve possible tile shapes you can make using five squares, joined at their edges. They are a little like tetris shapes, but with five squares instead of four.
I wrote an article for the MartianCraft blog about the Apple Watch, and what makes a good or bad watch experience.
Over the last few releases of iOS, things got complicated. First, we were able to share storyboards between iPad and iPhone projects, thanks to autolayout and size classes. Next, it turned out that iPad apps could be shrunken down to iPhone size, stretched out and shrunk back again during multitasking. Apps had to adapt themselves to different sizes at runtime, making sure that they displayed relevant content, appropriate to the current size.
Apple’s solution to this is
UISplitViewController. On the iPad, this maintains a two-column interface, with a smaller “primary” or “master” view controller on the leading side, and a larger “secondary” or “detail” view controller on the trailing side. On the iPhone, only one view controller is visible. Before multitasking, developers could get away with copy-pasting a delegate method from the template code, maybe checking
UIUserInterfaceIdiomin a few places, and the split view would work nicely on both devices without anyone having to think too much. Since multitasking, more thinking is required.
I recently completed a project involving a WatchKit app. It was not a pleasant experience, so here’s a screed of vague complaints with some half-baked possible solutions, and a possible ray of sunshine at the end.
In my talk at RWDevCon 2016 I described a way to handle custom view controller transitions in a way that didn’t lead to messing up your view controllers and leaving yourself with a lot of horrible cleanup code.
The secret to painless custom transitions is to do a lot of snapshots. In the talk I mentioned some utility methods for making snapshots, but there wasn’t time in the session to cover the details. Instead, I’ve written about them here.
A major difference between making your own apps and making apps for others as a contractor or “professional” developer (a common step as people move from hobbyist or indie developers to perhaps more lucrative work) will be the web services you’re asked to interact with.
Nobody’s going to pay you to make a Flickr or Twitter client, which is inconvenient because that’s what most of the online examples seem to use. If you’ve never written code that interacts with a web API before, it’s hard to approach these things with confidence, especially if you’re expected to talk to the developers of that API to work out any issues, and if those APIs are being written and rewritten in parallel with the development of the app.
In this article I’m going to go over the basics of your networking code. I’m going to assume you’re working with an API from this century so we’re talking about JSON and REST1. If you’re hearing terms like SOAP from your web people then run away.
I’m not going to define REST to mean anything other than “things are at a URL”, have that argument somewhere else ↩