Storyboard Purging and Removing Functions

Wow Paul

I wish I understood what you just wrote because it sounds like something I need to know.

I will look up the meaning of “the observer pattern in lua” and “implement the listeners as direct methods”

and “event dispatcher” and “reduce dependency with listeners” and “dependencies on events rather than dependencies on methods”

It’s all jibberish to me but I am intrigued by the event dispatcher method, I think that might help clean up my code.

I’m prepared to re-write all my 3500 (and climbing) lines of code as many times as it takes until it’s lean and clean.

Ah :slight_smile:

The observer pattern is the official name of the ‘sending events’ thing that Corona has - you listen for an event, and it sends a message, and you react to that event. 

(The problem with doing this is that the thing sending the message has to know about the thing it is sending a message to, and if you don’t forget this (removeEventListener) then there is still a reference there - so it may not ‘clear up’ the memory)

What I would suggest is two things - one write some code in lua (or anything) outside Corona SDK, so you are comfortable with tables and so on. Corona is event driven , when you are new to programming it is much easier to learn skills without events.

Secondly is don’t try anything too complicated if you are a newbie - go for something simple - just Pong, or Breakout, something with one basic screen, before trying anything too serious. I’ve been coding for near on 40 years, but we all start with Print “Hello World” or something similar. 

Structure and organisation is important - for simple things it doesn’t matter, but anything complicated can end up with umpteen interconnected bits of code. Try and break things up into separate bits. Try to make your functions do one thing or one closely knit group of things and do them well.

Once you’ve done this you will get a feel on how to engineer more complicated projects. Good luck :slight_smile:

Something else that’s perplexed me is using the Storyboard, I have read extensively on this subject.

I presumed that in my bare bones main.lua module I would have the following lines of code:

storyboard.gotoScene(“menu”)

storyboard.gotoScene(“level1”)

storyboard.gotoScene(“transitionScreen”)

storyboard.gotoScene(“level2”)

storyboard.gotoScene(“transitionScreen”)

I have found myself putting the gotoScene in each module so each module moves directly onto the next.

I’m an old school basic programmer so my logic is to be able to goto where I like using routines and I’m finding object orientated programming a tough nut to crack.

Just FYI, not all eventListeners are the culprits:  http://coronalabs.com/blog/2013/04/02/cleaning-up-display-objects-andlisteners/

What About Event Listeners?

There are two types of event listeners. One type is attached to  display objects  and the other is attached to the  global Runtime.

When you create an object and add a touch handler to it, you’re attaching a block of code via reference to the table. That is, you’re not adding the code to the table, but a  pointer  to the code. Code is in its own memory and it’s not something you allocate and dispose of. The code persists and there’s only one copy of it.

Once an object is removed, there is no way to trigger events against it, so in effect the event handlers are removed for you. You do  not  have to remove these if they are attached to an object that’s in a scene-managed group.

Runtime  listeners, on the other hand, must be removed because they’ll continue to run after the scene is taken out of memory and the functions that are executing are likely going to reference an object that is no longer around. This can cause your app to crash.

I’m new myself and so I’m not offering advice but just comparison.  I’m using Composer and not Storyboard (though have tried Storyboard briefly) and I have not put all my gotoScenes in main.lua.  I just put one that goes to my Menu screen.   In menu.lua I have 3 gotoScenes tucked inside functions since I have 3 areas the user can choose to go to.  If user picks “area1” then within area1.lua I have 2 gotoScenes - one that leads back to the menu (i.e. a Home button) and one that leads to area2.  

So, it seems we can include within each module the gotoScenes to the other modules we want to lead the user to.  I have not needed to put them all in main.lua

Thanks for that rshanlon, that makes me feel better.

Great advice from both you and Paul, cheers.

To answer Pauls suggestion that I should start off by writing simple code to begin with.

I did a little while I was reading various  tutorials, I even bought an exercise book and took notes, but learn’t very little.

After 2 months of continuous learning, reading and writing I was still none the wiser so I decided to jump straight in and learn as I went along, trust me, my code may not be pretty but it works and I’ve learn’t so much more using a hands on approach.

We are probably in similar boats.  My wife and I are reading Dr. Burton’s book “Learning Mobile App Game Development” as well as taking tutorials at Jay’s website (http://masteringcoronasdk.com).  

And in the process, we have two projects we’re working on to employ the things we’re learning.  This seems to be advice we’ve heard more than once: do an actual project that you can release in an app store and in the process you’ll get better.  After a month+, I’d say we’re more familiar and a little better…but overall we still suck.  ; )

Good luck. 

QuizMaster, that’s absolutely the best way to learn.  Jump in and start coding things. Your first few apps will probably be a bit ropey, but I’m sure you’ll learn fast :slight_smile:

Once you’ve got a bit more comfortable, it might be worth looking at some Computing theory - object orientated code, data structures, design patterns and similar. These sorts of things will help you organise and manage more complicated programs.

Thanks for the advice Paul