Before you start developing a bigger application you should plan, how the whole project’s classes should talk to each other. You should take a sheet of paper and draw the schema, describing the most important classes

I don’t want you to draw the flowchart describing every single algorithm, every if statement or loop like this one below.

When I started programming, every next view (UIViewController) of any application, was allocated by previous view and there was no simple way to return from the last one to the first one. Either I had to start programming the app from the beginning to fix it or had to call dealloc method which should be called only automaticaly when the application is quited.

Since few months I’ve new idea, I would like to show you. Below is the schema – the frame of most my new apps:

Legend:

• A – App Delegate, the first objective-c file, autmatically allocated when the application starts.
• B – Main Controller – this is the “application central unit” that is responsible for displaying some part of the menu, receiving messages from any classes it allocates and delivering them somewhere else.
• C – Settings – class that provides an interface to adjust the volume of sounds / music, way of steering (arrows / accelerometer) etc.
• D – heart of the sounds and the background music.
• E – in this case, the funniest part of app, the hardest to code, responsible for loading a level, tracking the game progress, check for collisions and more.
• F – provides a form for entering new high score
• G – displays the best times / scores for any level.
• H – other simple views that almost every application has.

How does it all work?

Let’s start with arrow #1. In fact, my App Delegate [A] has one single task - to allocate a next view, in this case the Main Controller [B] and I never use it again.

Once MainController [B] is allocated the Main Menu it provides is visible on the screen. Any function user presses is allocated and/or displayed via transition or not – it’s up to me.

#2, #3, #9
When users changes the volume in the Settings [C], the Main Controller [B] is informed about that change and it’s passed to the Sound and Music Engine [D] to perform necessary tasks. If it was other option, for sure Main Controller [B] now, how to deal with it.

#4, #5, #6
When users starts/load/continue the game, Game Controller [E] is checking each parameter of the game. When the game is canceled it returns to Main Controller [B], when the game is over, it checks, if the score is enough to appear on the high scores list. If yes it tells the Main Controller [B] to display the form – New High-Scores [F]. Once form was compleated, #6 Main Controller [B] updates the list of high scores and displays the records High-Scores View [G].

#7
User can easily visit the High-Scores View [G] and quit to Main Controller [B] without any difficulties.

#8
Any instructions, information are simply more or less polished views, so one class is enough to handle them all. It’s easy to navigate from Main Controller [B] to Others [H] and vice verse.

#9
Whatever user does in the application, Main Controller [B] tells the Sound Engine [D], if it should play a simple button pressed sound or change the background music.

I’ve just shown you my idea of programming bigger applications. Of course it doesn’t mean that whatever I do, is made with only eight classes. For example Game Controller has many other classes it includes to help him checking what is going on in the game and they talk only with Game Controller and it decides if it should send a message to Main Controller to finish the game or continue it.

Hope this helped.

• Previous Entry: Tables
• Next Entry: chris-software.com # Logo