The world is moving to HTML 5
February 7th, 2010
I’ve always been annoyed by the hatred of Flash by the development world. I’d prefer to see it hated for real reasons (there are plenty) and replaced by genuinely better technologies, but the hatred comes from people who often don’t care to understand Flash and support poor solutions as the answer. Lately this hatred has been getting louder, and from a PR perspective Flash couldn’t be worse off.
I’ve tried to fully describe why this anti-Flash movement is, in so many ways, wasted energy, but I found another post instead. Here’s the best description of what role Flash plays on the Internet that I’ve read since the first Flash ad pissed off a JavaScript developer.
“The World is Moving to HTML 5″ and Other Flights of Fancy by Richard Leggett
Graduate
January 11th, 2010
My life has been chaotic these last few months, I keep feeling the urge to tie up all these loose threads and it’s distracting from what I should be doing. I graduated a few weeks ago and I’m kinda feeling my way around in the dark here, but I want a job. I think this blog might be a good place to mention it.
I’ve been a programmer for just about nine years. I am an expert in some things, taken plenty of advanced Computer Science coursework, and I’ve got Google internship under my belt. Most of my long-term experience is Flash related, but there’s also my more low-level knowledge including CUDA, assembly, C, C++, compiler design, computer graphics, high-performance computing and networking. If you (or somebody you know) might want my resume, my email address is static at brokenfunction dot com.
Mega Man vs Adobe AIR
January 6th, 2010
I’ve got downloadable versions of Mega Man vs Metroid and Mega Man vs Ghosts ‘n Goblins available here. They require Adobe AIR to be installed in order to work.
I couldn’t test them on OS X, so if anyone can try them and tell me if they work I would be grateful.
If you have any problems please email me or leave a comment. Be sure to include your OS.
Enjoy!
Adobe AIR and shared objects that aren’t shared
January 2nd, 2010
I have been using shared objects to share data between swf files, so that changes in one can affect the other. On a website it works great as long as they share the same localPath and name, but this model doesn’t quite apply to AIR applications. Despite the name “shared objects” when you’re using them with AIR they’re private to each application, making sharing data using shared objects impossible as far as I know.
I’m a little surprised each application gets its own shared objects folder. I’m guessing it’s because there’s no domain to keep things properly separated, but I’m disappointed with the alternative. The localPath of a local shared object could default to a path containing the id of the application instead. This would keep local shared objects separate by default while still allowing more freedom. Treating each application as it’s own domain instead of the computer itself is frustrating. The best solution I’ve found is to create a shared application storage directory, then save any files to that.
These are the usual application storage directories (I’m not sure about the Mac OS X one, since I can’t test it, but it appears to be correct):
Windows: %APPDATA%\Local Store\<application id> Mac OS X: ~/Library/Preferences/Local Store/<application id> Linux: ~/.appdata/Local Store/<application id>
So, if we resolve the directory up two levels (“../../”), we get the following directories:
Windows: %APPDATA%\ Mac OS X: ~/Library/Preferences/ Linux: ~/.appdata/
Which is probably the best place to put the shared application storage directory. When creating this folder I would recommend using the same naming convention as your program id (which generally is similar to package names, e.g. “com.somewebsite.project”). It should not be the same id as another application.
Here’s the code in action…
var appStorageDir:File = new File(File.applicationStorageDirectory.nativePath);
var saveFolder:File = appStorageDir.resolvePath("../../com.somewebsite.shared");
saveFolder.createDirectory(); // ensure the save folder exists
var fileStream:FileStream = new FileStream();
fileStream.open(saveFolder.resolvePath("savedata.bin"), FileMode.WRITE);
fileStream.writeObject(obj);
fileStream.close();
I create a duplicate of File.applicationStorageDirectory because it doesn’t allow you to resolve paths beyond the root of the directory.
It’s important to realize that this is ultimately a hack. If the application directory changes it could save the file somewhere unexpected. Still, it’s unlikely to change in the current version of AIR and it’s the best way I’ve found to share data.