Swift App Architecture - ios

Question

I'm building out an audio tour component of an app, and I've hit a rut on organizing and calling data. I'm totally green to iOS development; coming from a Ruby/Rails background.
Class names in bold: The goal is to trigger specific information at each tour Stop. Each Stop, will be an AudioClip and play a soundbite, or it launches a Trail to guide the user to the next Stop, or it will flash a Video modal with video, etc. And at each stop, there need to be callbacks once reached. For example, if I arrive at the art museum, I would hear a clip about the Mona Lisa and then an image of the portrait would display on the phone. But all stops are not created equal, so even though the art meseum stop has an audio file to play and an image, the stop at the park may just display a walking trail with nothing else.
I have the app set up like this:
class Stop: NSObject {
func execStop() {
// do stuff
}
}
class AudioClip: Stop { }
class Trail: Stop { }
class StopImage: Stop { }
All of these tours need to be triggered in consequential order, and the next tour stop shouldn't be shown if the current stop hasn't been reached. The best way I could come up with is something like this:
// Each stop defined as its own class
class Museum: AudioClip {
override func execStop() {
playAudio(name: "AudioFile.m4a")
showImage(name: "MonaLisa.jpg")
}
}
class Park: Trail {
override func execStop() {
addRoute([Array, of, coordinates])
}
}
class Tour: NSObject {
var stops: [Int: AnyObject] = [:]
func resume() -> Void {
let active = nextAvailableStopLookup()
let currentStop = self.stops[(active as Int)] as! Stop
return currentStop.execStop()
}
}
// Individual tours, i.e. Museum, Resturant, Hike
class MuseumTour: Tour {
var TourPoints = [
1: Museum(...)
2: Park(...)
]
}
And then in the ViewController, the current Tour would be activated and based on the last stop completed, the next one would be queued.
override func viewDidLoad() {
let queueStop: Void = MuseumTour().resume()
}
The problem
This seems like a terrible way to set up an app with a lot of overhead. Each stop is a new class, and there could be upwards of 60 stops, which is 60 separate classes. The callback is the kicker - inherited-class functions (like func playAudio on AudioClip) are unavailable in the MuseumTour class. And I'm such a novice, I don't know how exactly to trigger dynamic closures.
Is there a better way of organizing and calling this type of data?

Answer 1

What you are doing certainly seems very silly in any language.
As far as I can tell, and to the extent that I was able to stay awake through your description, a "stop" is just a sequence of things to do (along with a pointer to another "stop"? I can't quite tell from your description). So it seems to me that a Stop is an instance of the Stop class (or, in Swift, more likely a struct) and that's all it is; there is no need for all these classes.
Your "I don't know how exactly to trigger dynamic closures" is quite telling, since an array of functions is exactly, it seems to me, what you want a "stop" to have. Maybe your first step should be to "stop" (sorry) and learn Swift, where functions are first-class citizens and so an array of them is perfectly normal.
In my very annoying app "99 Bottles", which sings "99 Bottles of Beer on the Wall", at each line of the song, we perform one or more actions, such as taking down a bottle, or removing the bottle from the screen, and we have to know what line of the song to sing. In my app, therefore, a Phrase struct consists of what to sing along with a list of actions to perform along with it:
struct Phrase {
let sound : String // name of sound file
let actions : [() -> ()] // what else to do
}
The song as a whole is thus nothing but an array of Phrase instances. We pop the first Phrase off the array, sing the sound, and call the actions functions in sequence:
let instruction = self.stages.removeAtIndex(0) // a Phrase
self.player.play(instruction.sound) // sing
for action in instruction.actions {
action() // perform the action
}
This sounds quite similar to what you are after.
(Of course, you say you are from a Ruby background; everything I just said would be equally true in Ruby. The notion of a function as a first-class citizen should come as no surprise to you.)