Does Apple hate Adobe or Developers?

I was thinking that perhaps I should wait until tomorrow to make a post. April 12th is when Adobe is going to officially announce the Creative Suite 5 lineup. I am hoping that something big is going to be announced tomorrow but think that perhaps the iPhone OS 4 rumors may have dampened Adobe's plans. One feature that they were planning on having for Flash CS5 is an iPhone exporter that would convert Flash apps into iPhone apps. Sadly, the iPhone SDK license agreement (required to use the iTunes store) may be specifying that apps must be written in Objective C or C++ and that API features must not be accessed through third party libraries. This effectively rules out using Flash to develop iPhone apps. It also rules out other tools like Unity.

I think the real reason for doing this is to force developers to develop specifically for the iPhone/iPad. Flash being able to export to iPhone would circumvent this requirement making it easy to develop cross-platform applications. While Unity also allows this, it has a much smaller developer base as compared to Flash so Apple probably didn't even notice it yet. In other words, this attack against Flash isn't actually aimed at Adobe, but it is instead an attempt to make it much more work for developers to create cross-platform versions of their apps. Right now, the iPhone is in a dominant position, so developers pretty much have to support it. This is just like Windows is the dominant platform for PCs which is why there is so much Windows software.

With Android continuing to gain market share, one has to wonder if this is a good long-term strategy for Apple. Right now, the major player is the iPhone, but with all the hassle and inconsistencies with the approval process, how much market share will Android have to gain before it becomes the better choice for initial development? In the computer industry, Apple was the dominant player with the Apple II, but that quickly changed when IBM created an easy to clone PC that numerous companies copied (today's PC) resulting in Apple slowly becoming a niche player. When companies start developing for the Android and then deciding if they should bother porting their app to the iPhone,  we may again see Apple become the niche player but this time in the mobile market.

Trivia Bomb Sneak Preview

Over the long weekend (in Canada, at least) I managed to finish my Trivia Bomb game so today I posted a sneak preview at http://blazinggames.com/table/dozenDays/words/triviaBomb.php so readers can see the game early. It took me longer to finish this game than I anticipated with a final time of almost 20 hours. I actually like the game so may do additional episodes in the future, possibly adding more features.

In Android news, my entry is in a releasable state though I may add more game play modes before the deadline. I have some really neat ideas fore some of the game modes but finding the time to implement them is the key factor. For my first Android project I think it turned out good but prize winning is unlikely.

Crossword sneak preview posted

While I still have some fine tuning to do, the hint mode is not using the correct colors yet, and the final data for the game are not ready yet, a sneak preview of my crossword game is located at http://blazinggames.com/table/dozenDays/words/crossword.php for those of you who want to see it early. By the end of tonight (or this weekend if more than 12 hours of development time is needed) the final version that will appear next week will be ready.

My Android development is proving to be quite interesting and I have learned quite a bit about the Android operating system. While I doubt that my game has any chance of placing in the Google contest, I plan on entering it anyway if it is finished in time. I plan on also releasing the game on my site once the contest is over as well as porting the game to Flash for my website.

Dungeon Romp 3D beta released.

Work on my Android game is going well so I am continuing my 3 week site updates until after the Google Android Contest deadline at which point I will go back to either a fortnight release schedule or a weekly schedule with open source releases and articles being releases on odd weeks. Still, today is the beta version of Dungeon Romp 3D, which is a 3D version of Ultimate Retro Project episode 60. There are a few additional features that I am thinking about adding so there will probably be another release of the game.

Word Slide Official

The Word Slide game has now officially been posted. Bigger news, at least for those of you who are interested in RPGs, is the next game that will be posted July 3rd. My Dungeon Romp game is going from 2D to 3D. Of course, it is just a beta but I think it is fairly stable. I am sure a lot of you noticed that again I am going 3 weeks between releases, but this time it is Google's fault :-). Their second android application contest is starting and I am considering entering something into the contest so want to actually have some time to properly develop my android game. Sadly, their rules forbid releasing the applications that are being entered into the contest until after the contest is over so my game will not be released until after the contest is over if I actually finish it and enter it into the contest. I know my chance of winning anything is very low, but I think it may still be worthwhile to enter.

VMs are everywhere

One of the interesting things about Android is that Google is using their own virtual machine, called Dalvik, which is not the same as the Java VM but JVM code can be converted to Dalvik code using a tool included with the Android SDK. This started me thinking about how virtual machines have taken off. You have JVM, Microsofts CLR, and Flash forming the big three with many other's such as YARV (Ruby's upcoming VM) and Parrot (Perl 6s VM) also starting to take off. While VMs have the advantage of being processor and operating system independent, ultimately the code has to be converted to native machine language. There are three basic ways of doing this. Interpretation, JIC, and re-compilation.

Interpretation is the slowest of these techniques, though when combined with specialized compilation (which is essentially what Hotspot does) can actually be the fastest. The idea is that the program converts the program to machine language by converting the code every time it is executed. Hotspot improves this by detecting the parts of the code that run frequently and compiling those sections into highly optimized native machine language. When you consider that most code runs rarely, this can be very efficient.

JIC, which stands for Just In-time Compilation, compiles the classes into native machine language as each class is needed. There is an initial delay when a class is first used, but once compiled the class will run fairly fast. This has largely become the way of creating virtual machines. Often optimization of the native code is not done due to the fact that the compilation is happening as the program is running so it has to happen quickly.

Finally there is re-compilation. This is essentially a compiler that takes virtual machine bytecodes as input and outputs native machine language. This could be a good way of distributing code as you could do the translation from bytecode to native code as part of the program's installation. In this particular case, when you install a program, part of the installation is compiling the virtual machines code into native code. There is no overhead when ran as the compilation was done before hand. While the initial installation of the program on the machine would take longer, most people wouldn't notice and this only has to be done once.

Fragmenting Java

One of the biggest issues with Android is the issue that it fragments Java. As Java ME is already different from Java SE one can argue that fragmentation has already happened. What I was originally hoping for Android would have been support for Java SE which would have made porting to Applets much easier. Right now, I am going about projects in a similar way to when I was doing C/C++ coding. Cross platform coding consisted of writing a lot of generic classes while putting platform specific code into it's own classes which can hopefully be accessed in a generic way. The problem with this technique is that when you are under a tight deadline, you suddenly stop worrying about cross-platform compatibility and just start writing for the biggest platform with plans on making the code cross-platform when you have time. Of course, you never have enough time and the code base gets more platform specific and your initial noble goals vanish.

The API for Android is very clearly for Android. All the android specific classes are in packages with the Android prefix, so people who are claiming that Google is doing what Microsoft did are quite mistaken. Microsoft's platform specific extensions were not clearly distinguished making it very easy to accidentally write code that was platform specific without realizing it. More to the point, with Android, you are not actually writing java code but are just using java as your programming language and generating Dalvik code instead of JVM code.

Android Decision

The big problem that I had with Java ME, which also happens to be the same problem with Android, is that the API used for the user interface is different. If it was just a subset of the standard edition, then things would be fine because you would only have to write code for the lesser API. Sadly, the drawing commands and user interface are kind of important for games, with a lot of code going into this. Still, I would probably be able to share between 70-80% of the code between an applet version and an android version and would possibly even be able to do a third application version that would take advantage of 3D hardware. In fact, one of the features Android has is OpenGL ES support. Despite it's many flaws, I've always liked the Java language so moving my development to Android and porting to Java SE might not be that bad of a move. While I am not likely to win money, entering their contest might not be a bad move exposure wise. If I am lucky enough to have my game win one of the 50 slots, then it was a really good move otherwise I still have the option of finishing off my entry and attempting to sell it commercially. I would also break the game into a bunch of chunks and release it episodically on the Blazing Games site for those who don't want to (or can't afford to) pay for the game.

Android SDK Released

Android has been released. My initial reaction was that the API was a modified version of Java ME and that the amount of work to write code that could work both in an android phone and as an applet was probably more than it was worth. Then I noticed that Google was giving away $10,000,000 to encourage Android development. The first contest runs from January 2 and submissions end March 3rd, with 50 winners getting $25,000 and a chance to get $275,000. While I am unlikely to win, even if I don't I'll have a bunch of code that can be pushed towards a commercial project and can be used on the Blazing Games site. Granted, applet versions will be a bit more work than I would like, but the potential payoff does change the factors a bit. I will be sleeping on this decision but will update you tomorrow.