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.
Saturday, March 8, 2008
Only foreground 3rd party apps on iPhone - Intentional or Design flaw?
Labels: Application Development, iPhone, Mobile Computing, Mobile SDK
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.
Labels: Android, Apple, Google, iPhone, Mobile Computing, Mobile SDK, Sun