A subreddit for the.
I am sorry if this has been covered before. Kraftschlag mp3 download. I am an old guy trying to learn some new skills. I used to program in Procedural (ie sequential) languages and then moved to other things in life. I'm enjoying Corona SDK and think I can get the hang of it. My main brain challenge is the whole event driven concept.I'm looking for some suggestions on how to get the hang of this thing.
Looking at all the sample code I can follow most but get lost a lot of the time as well. I'm considering getting one of the Corona IDEs with a debugger function so I can actually 'step into' code and follow the flow. Not sure if this would help me a lot but something to try.Any suggestions will be most appreciated. Thank you. The biggest conceptual change for me in event driven coding was understanding that my program doesn't control the big picture of flow, but the OS does.
Event driven programming turns your code into subroutines called at the whim of the OS, essentially.And the OS will only call your routines on very specific, well defined events. The trick is knowing which events your code will / can be called upon.There's the program startup for example - corona calls two of your routines, the main, and a system event is called as well (application start event).
After that, your program is not typically called again until exit (unless in your startup, you setup other events like a keyboard listener, or timers, or network requests, which will trigger yet more events where the OS calls your code).So, at most times while your program is 'running', it's actually not running - just waiting for the OS to call something.If the user taps on your menu, the OS will inform your app (If you've told it to by creating an event listener). Otherwise, your routines will just sit there, not running.
One of the biggest tricks is understanding what the events that call your code are.In the old days, I would have call it spaghetti programming. But the result from having everything driven by OS events creates 'spaghetti-o's' I think, independent twisted modules of non-portable code that is tied to the idiosyncrasies of the event system the OS implements. In our case, the idiosyncrasies (between iOS and Android event systems) are papered over by the corona API. (But this just ties us to corona, instead of ios or androids model).So all in all, my conceptual model is now that my app is a bunch of subroutines, patched in to various OS hardware type event 'hooks'. My challenge is to setup the display correctly at startup, and hook into the necc. OS places to trigger more code as the user does things. It's definitely not procedural, but thinking of my app as a collection of subroutines for the OS works for me.
Lua Ide Windows
@r.delia, great suggestions. Definitely need a debugger to keep track of what gets fired when. Print is starting to wear off on my terminal window! Will check out the videos asap.@ mpapas, thanks much for your detailed explanation. This makes sense.
OS is sort of like the old fashioned telephone operator at the switchboard waiting to connect functions to events when the events 'call in'. Guess the first thing to do is to get comfortable with the idea that I'm not in full control.
Well, I could still artificially fire events to get things going I guess. So at program launch you typically hook into the OS user input events - with your button/object listeners (screen background, widgets), where you want to take input and start some process off. You set up the first round of events to listen for starting from your main, and once you set up the event listeners. Your code just waits for the user to do something.However, you can also set 'timer' events to fire off every screen refresh, every few seconds, or at periods that make sense for your app. These come in from the OS at functions you tell it, so, yes, you can keep a code heartbeat going if your app desires. Additionally, you can fire off a 'network.request' when your app starts off, and this creates a little mini event later itself (a routine of yours is called back later when the download completes).
So in general, you set the events up, and the OS calls you back when the event actually occurs.But overall, the process in the event driven systems is to draw your screen / menu, hook up the 'touch' or 'tap' input events (and timer, or other events you want notification of), and then hurry up and wait. For something to get called. Think about events in terms of 'interrupts'.
You're program is going on it's merry way and then something happens that causes your program to stop and handle that event. Generally 'going on it's merry way' means sitting there doing nothing but waiting on events to happen.Events can come from input like touching the screen, some network operation that's fired off in the background waiting on completion, playing a sound or doing a transition (moving an object on the screen) that does something when that process is finished.
You provide some function to handle that interrupt and when it's done, it returns to what it was doing, again, generally waiting.Corona SDK doesn't really have this idea of a 'game loop' where you loop and loop and wait on keyboard input. That process is handled in the background for you.Now sometimes you need to do things in a looping fashion and there is a special event called the 'enterFrame' runtime event.
Basically once every 30th of a second (or 1/60th of a second depending on your settings) you get a function run that lets you do continuous things that you would typically do in your own game loop. In my space invaders type game, I use that method to advance my aliens on the screen, scroll the background a little to simulate movement. Hi guysWhat a great and timely post! Thanks for all the info on how to think about event driven coding. It is a great timing because, I too is looking at a bunch of OOP methodologies:- ArdentKid (Mouse Run template - paid)- JesterXL 's link listed above (great info!)- Glitch Games (jetpack game template which use OOP - Free)- MiddleClass- and some othersI really like all of them. ArdentKid seems to be the most complete but also more complex (at least for me right now) I also like Glitch Games OOP because it look easier but not sure if it is limited in some way.I would LOVE if Corona could come up with it's own OOP structure!
I have played with Codea recently and I love that they a class model (where each class goes into a tab) That's make programming so much easier!Thanks again for starting this thread!Mops: I am planning on making a survey about what OOP people are using with Corona but not sure if it is possible with this forum. Any ideas?.
Lua Glider Ide Crack 1
Just remember that you can't start and stop the indicator in the same code chunk. You need to start it when the process begins, and then queue a callback or other function to stop it when the process is complete.This was a moment of clarity, I thought I understood it but I still wanted to challenge it. Challenge was to simplify the ActivityIndicator sample to its barebones and then write it in a non-event driven, sequential manner. I was hoping to understand this more and along the way I managed to confuse myself some more.Here is barebones Activity Indicator code. This will just put up the background image and then count to 5 while showing the ActivityIndicator and then take it away.local numSeconds = 5local counter = display.newText( tostring( numSeconds ), 0, 0, system.systemFontBold, 36 )function counter:timer( event )numSeconds = numSeconds - 1counter.text = tostring( numSeconds )if 0 numSeconds thennative.setActivityIndicator( false );endendtimer.performWithDelay( 1000, counter, numSeconds )native.setActivityIndicator( true );display.newImage( 'aquariumbackgroundIPhone.jpg', 0, 0 )Then I wrote the following. I put in specific print lines in between to prove sequential execution.print ('line 1', os.time )local numSeconds = 5print ('line 2', os.time )display.newImage( 'aquariumbackgroundIPhone.jpg', 0, 0 )print ('line 3', os.time )native.setActivityIndicator( true );print ('line 4', os.time )local counter = display.newText( tostring( numSeconds ), 0, 0, system.systemFontBold, 36 )print ('line 5', os.time )local markTime = os.timeprint ('line 6', os.time )local timePassed = os.time - markTimeprint ('line 7', os.time )while timePassed. I am still trying to understand why the background image does not pop up before the native.activityindicator in my sequential code.
Verify that you have sufficient access to that key, or contact your support personnel. EventID11404 Product: McAfee Agent -- Error 1404.Could not delete key SOFTWARE McAfee Agent FirewallRules. System error. Verify that you have sufficient access to that key, or contact your support personnel.
I think this is because display.newImage is called on the 2nd line and this starts a thread to make this happen. The code control returns to my code and the 3rd line and onwards gets executed while the processor is trying to make my display.newImage thread happen. Because it takes considerably longer (in CPU cycles) to load and display a full screen image the code flies through the next bunch of lines and so native.activityindicator takes over blanking the screen. Am I on the right track to understanding this thing?The irony is how in the event driven example display.newImage is the last line in the code and yet it executes as needed.
In my sequential code it is right at the top and doesn't get the focus. I know I'm about to crack this mental block. Almost there.Final question. If you really really really must put some processes in order how do you go about making sure one will wait for the other? ExampleOpen DB,if not exist create DBdownload data from web into DBLoad SceneLoad widgets in the create sceneLoad data into widgets create sceneIn my app it takes too long to process the create db and populate it from the web so the app flies through the scene, widgets, load data part. Since the data is not there yet it sits there showing an empty tableview.
My current fix is to call a reload of the scene once my data download process is done. I work around it but I still feel its not the most elegant way to do this.Am I splitting hair on this? It works so I am happy.
Just want to understand. Sorry for being so stubborn. It's because your code doesn't do the actual updates, the OS does. It has no chance to update the screen during your 5 second loop there. I have broken your code up so that the OS is back in charge, and it basically does the same thing.
Just, in an 'OS is in charge of the display' sort of fashion.lua=auto:0- A little example of the event driven screen updates (done by the OS, not by the app.)-local counter = nillocal markTime = os.timelocal function showBGprint(' - ShowBG')display.newImage( 'Bg02.png', 0, 0 )- Lets initialize the onscreen countercounter = display.newText( 'Counter', 100, 100, system.systemFontBold, 36 )endlocal function doCountprint(' - doCount')local timePassed = os.time - markTimeif( counter = nil ) thencounter:removeSelfcounter = nilendif( timePassed. @ mpappas, thanks much for taking the time to help me. It is getting much clearer. Lets take your edition of the sample one more step closer to my real world challenge.timer.performWithDelay( 1000, function doCount end, 1)keeps calling back (is that the right term, callback?) doCount which does the job of updating the screen count and eventually calling off the ActivityIndicator.In my case I could have the dbUpdate function replace doCount and have a similar timer.performWithDelay keep throwing focus back at it. The dbUpdate could keep track of a variable to know if its done its job or not and if it has then it can call off the ActivityIndicator.Is this how you would do it in the event driven world? For my aging single line sequential mind it appears to be a waste of CPU ticks to do the timer thing but if this is how its done then so be it.I think I'm getting somewhere!Thank you very much!!!.
It's one way how onscreen timers / updates happen. But as far as loading / working with a db, there's differences in how those async / event driven systems work too.But overall, yes - You could keep a 'state' variable for the current state of your app/db, and display the current state onscreen in a display update routine (reading global vars on a timer, something like as above).But if you are using a server, and waiting for data from it, you'll have to do the event driven / async thing at the same time.The idea is, you send off a request for data with something like the network.request call, and in the call you include a callback pointer. Just before you called the server, you would change your 'state' variable to the 'waitingServerReply' state (and your screen display routines would pick it up and display that).When the callback happens (the server has replied), you would update the state to the next state, and your display routines would go from there (populating tableViews with the processed data or whatever).(Not sure if I'm making much sense here.). Making much sense. When you say ' you include a callback pointer' you are actually referring to setting up a listener right?
I need to read up on this a little more. Yeayy for weekend. Thanks much and wishing you all a great weekend.EDIT. This definitely helped me. I completely managed to get my activityindicator under control during a complicated startup routine.
Lua Glider Ide Crack Windows 7
Still lots of ways to go before I can say I am thinking event driven as opposed to sequential. Huge paradigm shift but slowly getting there. Yes, a listener it's called usually in corona. I usually call then 'callbacks' because my code gets called back when something happens. (Like in the network.request, your specified code gets called back when the request completes / fails).For the listeners, you usually have to install the listener first, then remove the listener later, as in:Runtime:addEventListener( 'enterFrame', screenUpdate )andRuntime:removeEventListener( 'enterFrame', screenUpdate )as opposed to the one shot deal like the network.request 'listener' (or callback, as I usually say for that one).But they both kinda cause the same thing to happen - a function of yours gets called when something in particular happens.