Event Driven Programming
Thursday, July 30. 2009
Event Driven Programming... I always thought that event driven programming could still use procedural style programming, and use event-driven only when necessary. ...and although that may be the case, I'm finding that Adobe AIR is built primarily as a fully event driven model. I've tried to coerce it in to doing procedural things and it just scoffs at me. I'm sure there are ways to have it work procedurally, but I'm not versed well-enough in it yet to know how, as it apparently expects all actions to be asynchronous.
Here's what I'm learning I need to do in order to invoke a "setup" window prior to invocation of my main program for the first time.
...and that's just to get the app to open properly. I'm not even sure if I've thought it through well enough. It's currently all still in procedural spaghetti code with errors abound. I thought of this after leaving work...so who knows if this'll even work. Ha!
Here's what I'm learning I need to do in order to invoke a "setup" window prior to invocation of my main program for the first time.
- Invoke main application, hidden.
- Detect if the settings file exists (hey, procedural, sweet!), if not...
- Open a new window (hidden), set an event listener for its close.
- In the new window, retrieve optional settings choices from the server; in the "success" event listener, dynamically fill the window with the options/controls...in the "fail" listener, close the new window and application window after displaying an error message (initial setup absolutely requires communication from the server).
- Upon submit of the setup window, close the window, revert data back to the calling/parent window.
- The closed window event runs...we re-fetch data from the server based on the setup window's choices (or from the settings file, if it existed - but that's another path that reaches the same point).
- On success, we build the main window's GUI from fetched data and then set the window to visible. On failure, at this point in development, we also close with an error.
...and that's just to get the app to open properly. I'm not even sure if I've thought it through well enough. It's currently all still in procedural spaghetti code with errors abound. I thought of this after leaving work...so who knows if this'll even work. Ha!
Adobe AIR and its Security Model
Thursday, July 23. 2009
I hate it. Until you start working with it and messing around with it, the documentation is terribly confusing. I kept trying to find an example (for quite some time) of how to use AJAX from within the main application sandbox (the initial "window" that opens upon run) to an external server. Almost all examples kept referencing local files from within the application, or used Flex which has a different mechanism in going out and grabbing information.
Jonathan Snook recently mentioned a talk he had given about plain old HTML/JS development of AIR applications in his blog, and...knowing it was my golden opportunity, I had to ask him if he knew of any examples of how to use AJAX in the main application window on an external domain with regard to the obscurities of the sandbox security.
He simply told me (paraphrased), "There is no security restriction on the main application sandbox. It should just work." Oooooooh, boy. Don't I feel stupid when I went and tried it and it worked just fine. I tried to PayPal him $10 for his time in responding, but apparently PayPal won't let me send money from my own account unless I link my credit card or bank account. :(
Some of you may remember my Reference Statistics Tracker Application that I have discussed in the past; that is the Adobe AIR application that I needed this assistance with... I had that part of the project (Reference Statistic Tracker) on hold simply because I couldn't figure out how to make a remote call, which sort of hinged on a majority of the GUI since the GUI is dynamically built. Awesome. At least I can continue now - especially now that the Staff Site's authentication is done. Luckily, I found a better tooltip plugin to use for the GUI in the meantime.
I'll probably create either a GitHub account, or create a public SVN repository on a subdomain here that can hold different projects I'm working on, if anyone's interested once this gets closer to a usable state. Any immediate preferences?
Jonathan Snook recently mentioned a talk he had given about plain old HTML/JS development of AIR applications in his blog, and...knowing it was my golden opportunity, I had to ask him if he knew of any examples of how to use AJAX in the main application window on an external domain with regard to the obscurities of the sandbox security.
He simply told me (paraphrased), "There is no security restriction on the main application sandbox. It should just work." Oooooooh, boy. Don't I feel stupid when I went and tried it and it worked just fine. I tried to PayPal him $10 for his time in responding, but apparently PayPal won't let me send money from my own account unless I link my credit card or bank account. :(
Some of you may remember my Reference Statistics Tracker Application that I have discussed in the past; that is the Adobe AIR application that I needed this assistance with... I had that part of the project (Reference Statistic Tracker) on hold simply because I couldn't figure out how to make a remote call, which sort of hinged on a majority of the GUI since the GUI is dynamically built. Awesome. At least I can continue now - especially now that the Staff Site's authentication is done. Luckily, I found a better tooltip plugin to use for the GUI in the meantime.
I'll probably create either a GitHub account, or create a public SVN repository on a subdomain here that can hold different projects I'm working on, if anyone's interested once this gets closer to a usable state. Any immediate preferences?
