I’m writing this little issue I discovered today in the alchemy installation under OSX, in case someone else is having the same problem…
if echo $MACHTYPE | grep darwin &> /dev/null; then
if echo $MACHTYPE | grep -i darwin &> /dev/null; then
I’m writing this little issue I discovered today in the alchemy installation under OSX, in case someone else is having the same problem…
if echo $MACHTYPE | grep darwin &> /dev/null; then
if echo $MACHTYPE | grep -i darwin &> /dev/null; then
Some people asked about changing the default editing behavior of a Flex 3 Tree control so that item editing starts on a double-click event instead of the default single click.
Well, it seems that the upcoming flashplayer 10.1 (first half of 2010?) has been completely designed to fill the gap that the current flashplayer has with the smartphones world (multitouch, accelerometer, screen orientation, sleep mode, out-of-memory management, etc..).
I didn’t have the chance yet to try out Flash CS5, but I’m still a bit concerned about the new feature that makes users able to compile their own application into valid iPhone apps.
Things look really good if you look at the examples and if you talk with the people that already had the chance to try this feature out. But I must remember that usually the excitement for a new – and let’s say outstanding – feature usually cannot guarantee the final result to be acceptable. I fear that this feature might evolve the same – bad – way as Alchemy did: they started with a promising project that then felt down to a side project because many users shown that it was possible to achieve the same or better results by just using plain AS.
A few weeks ago I started spending my free time on experimenting with generating a valid iPhone app from a SWF file. I didn’t know anything about the fact that the Adobe would have put the same feature in Flash CS5.
My approach wasn’t too sophisticated: basically, as long as I didn’t have so much time to spend on writing a full binary converter, I was parsing the SWF and then generating static Objective-C/C++ (well mostly C++ and I’ve used Objective-C as glue where strictly required) code that then was compiled by Xcode to a working iPhone application.
I stopped once I figured out that Adobe was going to promote a similar thing (even if their approach is better and probably more powerful), but I had time to figure out a few issues that they may encounter (or maybe they already encountered):
What I fear most actually is that they’ll be able sooner or later to solve all the issues and create a good product, but probably that product won’t be suitable for complex applications, that will be always developed directly using XCode.
That said, I think that probably a better approach would have been to figure out a way for Adobe to include the Flash Player on the iPhone. It’s already ready and I really can’t understand why they don’t release it (it must be Apple, and probably because having a Virtual Machine on the system will break the basis the App Store has been built over).
Having the FPL on the iPhone will still limit us, but it will open up a brighter future for AS developers who want to release apps that runs on the iPhone too (Did you ever heard about compile once, run everywhere?).
So let’s wait and see what happens. What I’ve seen so far on the app store are really simple games that don’t use so much resources, so I can’t really say yet if they did a great job or not …
Well, it’s not true at all, but it’s something like that ( they enabled this by using the Low Level Virtual Machine (LLVM) compiler infrastructure).
iPhone applications built with Flash Platform tools are compiled into standard, native iPhone executable packages and there is no runtime interpreter that could be used to run Flash byte-code within the application.
We won’t be able to test our apps using the Mac iPhone simulator. And we cannot use the iPhone controls with actionscript.
Imagine you’ve made a very huge flash application and many users will play with it every day.