Only foreground 3rd party apps on iPhone - Intentional or Design flaw?

I read this post in Techcrunch which discusses on iPhone's limitation to allow only foreground 3rd party applications. 3rd party applications are the ones developed using the iPhone SDK.

While the Mike thinks that this is an intended restriction owing to the limited memory and resources, I personally do not think thats the only reason. And I know why I am correct for some reasons ;).

I believe the restriction is more of a design flaw of the iPhone SDK. I believe that Apple engineers haven't yet figured out a way (or most probably did not have time to do so) a way to switch between the native applications and the 3rd party applications. You would need a robust layer which will take care of remembering the 3rd party applications' running context and bring back the UI when the application again comes to foreground. Also, there might be scenarios wherein what about happens if a native background application wakes up and wants to use the UI. In which case, how would the 3rd party application behave. Would it be able to yield the user interface for the native application.

Most of the above use cases need lot of thinking and through integration of it into the SDK layer. I am sure Apple would later release an updated SDK which will allow 3rd party applications to run in the back ground as well.

There may be a work-around for this problem. The 3rd party application developer can care of trapping/getting notification from the OS/platform for exiting its own context and then saving the relevant context information in the memory. The next time you launch the application, it can read the previously saved context and bring itself back to the state of previous execution. Its very similar to playing the brick game in your blackberry.

Is Sun getting desparate not to lose mobile JVM market?

After Apple announced last Thurday of its intention to release the long awaited SDK for iPhone*, Sun has unveiled its intention to port JVM onto the iPhone.

Its looks like Sun does not want to waste any time bringing the mobile version of JVM (J2ME) onto the iPhone. Obviously this sense of urgency should be due to the fact that iPhone provides a very good platform for mobile applications and also because of the impending threat from Google's Android. Sun should already feel frustrated by Google's clever coup of replacing Sun's JVM with their own.

The way I see the future is that Apple and Google may be in a direct collision course towards mobile dominance. And Sun may want to be present in one of the camps.

What also remains to be seen is how would Sun JVM affect Apple's business model of trying to sell iPhone applications through their iTunes store (App Store as it may be called). With the JVM present on the iPhone, would mobile application developers like to leverage it or will they rather choose to directly use iPhone SDK. With Apple bringing in restrictions on the development platform (only Mac can be used has the host to develop and debug iPhone applications), it gives a point of leverage for Sun.

And what about performance! iPhone SDK is already a layer on top of the native iPhone OS APIs. Now JVM would be one more layer on top of it. Will the java applications written for iPhone in future have the same performance as other platforms?

The war for a mobile computing platform is going to get interesting as days go by. Keep watching this blog to see how this unfolds.

Useful Links:
* You may be interested in reading this coverage of the iPhone SDK Press Release by Ryan Block of Engadget.
- You can also watch Apple's official video on the iPhone SDK Press Release here. Note: You need quicktime player.

Are you writing Java Apps for Android ? Maybe and Maybe not

Lot of people who are aware of Android think that they actually write mobile applications using Java. This is only partly correct.

What many people miss out is the fact Google Android uses ONLY Java Syntax. The java code that one develops for Android is converted in to standard Java bytecode. This again is converted in a different bytecode format (which Google claims that is an optimized, minimum memory footprint bytecode).

Basically, Android does not use a standard JVM (it uses a non-standard JVM called Dalvik) . The SDK also contains android.* packages apart from the usual java packages.

I found this post from Stefano Mazzocchi very interesting. He claims that the reason for Google using a non-standard JVM is not really for just optimization sake, but instead to get around any licensing issues with Sun for using J2ME. Wow! I never thought of that.

Its natural. If I were to run the Android project (instead of Andy Rubin), then I would start using J2ME as a preferred virtual machine for obvious reasons that we have a huge group of developers who can be readily moved/attracted to developing applications on Android. And then when it comes to licensing, I would think of someway to circumvent the problem and the one smart way is to make sure the final bytecode is not the same of the one generated by the standard java compiler. Thats exactly what Google engineers have done by developing Dalvik.


Other interesting links:
http://wireless.itworld.com/4269/071116googlesun/page_1.html
http://www.oreillynet.com/onjava/blog/2007/11/dalvik_googles_tweaked_nonstan.html

[Article imported from http://mohasinz.blogspot.com/2008/02/are-you-writing-java-apps-for-android.html]

Opera Mobile 9.5 announced - But whats the big deal

Opera has announced the latest version of their Opera Mobile.

You can watch this guided tour of the Opera Mobile 9.5 user interface and features.

Now, most of you who have been using Opera browser on your phone should be confused between Opera Mini and Opera Mobile.

Opera Mini and Opera Mobile are different in many aspects. If you have been using Opera on your phone for a long time now, then you should be having Opera Mini.

Opera Mini is java based browser application, whereas Opera Mobile is written as a native application for a Symbian S60 or Windows Mobile operating system (Opera Mobile 9.5 also seems to be available for embedded linux).

An other difference is that Opera Mini uses an intermediate proxy server which converts the web pages to much lower sizes. Opera Mobile on the other hand directly downloads the web pages onto the mobile and then figures out a way to render it on the screen.

Last, but not the least.. Opera Mini is free, whereas, one needs to buy Opera Mobile.

Now, is it worth buying a browser for your phone. May be and May be not. I don't want to comment on it unless and until I try out the 30-day trial version of their previous version of Opera Mobile.