Drawing in SpriteKit
Rewriting fluXpad as AUv3 … part 2
After setting up CoreData using the original data model using CoreStore. I’ve started looking into some easy iOS native way to do the drawing. In the original fluXpad version all drawing is done in Cocos2D. Another main reason to re-write everything was the choice of Cocos2D. While it might have been a good idea back in the days. Now it’s basically unusable in Swift.
An interesting resource for an approach of implementing drawing in SpriteKit is an example by George Lim. Not fully what I needed, but it lead me into the right direction. The current setup in fluXpad is a bit more complex because multiple colours need to be layered on top of each other.
Also the app now uses a clean swift setup. I was happily surprised to find that unit testing SpriteKit doesn’t give me any problems. Each drawing has its own view model and it can be passed to the drawing implementation to draw it. In the unit test one can just initialise a scene in an SKView and check that the nodes are as expected.
The entire drawing is now de-coupled from the main data model, having its own view model. Still, there hasn’t been made any connection between the two yet. The sketch below shows the current setup of the drawing on the SKView from the ViewController.
Here the touches are all handled by the DrawingGestureRecognizer and the coordinates are passed to the ViewController. These coordinates are then passed on to an implementation of DrawingSceneRenderable, which uses an SKScene on an SKView to tell the SequenceDrawer to draw. The SequenceDrawer can maintain multiple drawings. The actual drawing is a DrawSketch which is created by the SketchDrawer.
Once a drawing has been done, it is passed to the interactor, which eventually handles how it will passed to the main data layer. This is one of the main changes I have done for now: only process the drawing (hence the later musical data) once the drawing is finished. The finishing is marked by ending of the user’s touch.
