Hi all,
Sometime ago, I wrote a post about a weird platform’s behavior that we faced during the porting of one of our applications. This tricky behavior costed us many efforts hours, since it was hard to figure out, because it was related to a specific implementation of that platform. I am here today to tell you, one more chapter of this incredible odyssey of porting mobile applications. This new story, one more time, reinforce that WORA does not work very well for Java mobile development.
We have an app, which has been ported to many devices and platforms (e.g. Android, S60, Windows Mobile, etc.) along the past months. During all those porting, some minor adjustments were often done to get this app up and running properly. So far, no big deal! However, during the porting to Windows Mobile 6.5, which is powered by Smertec Jbed CDC JVM, we experienced a case of an unexplainable out of memory error.
This same app runs very well on other devices with less memory and power processing than this one powered by Windows Mobile+Jbed. However, the resolution is huge higher (480x800). That was our first investigation point. As you must know, image is a memory hog. However, we had 16MB free. During five minutes test, the memory was already gone.
From this point, we started investigating other app’s components in order to find the memory leak: no success! We also implemented a test app that loaded some images to see how the device manages the memory usage. For an unexplainable reason, the JVM had 11MB available in Java heap. So why is an out of memory raised with all this free memory? The first reasonable answer was that this device has another memory area, which is shared with the device, and the JVM uses it to store the image objects, instead of Java heap. Even thought it seemed to be guilty by the problem, in the end, it did not explain why so much memory was consumed. Be prepared to know the real guilty!
As this app is fully-canvas, of course, we use Canvas to implement the user interfaces. In fact, GameCanvas. There are no mandatory requirements for us to use GameCanvas. We have used it, since there are more features available, which could be necessary in the future. However, this Jbed seems to have some personal issues with GameCanvas. One teammate wondered why GameCanvas? At that moment, he had no specific objective with that question. Just brainstorming. However, based on that, other teammate had an idea to replace GameCanvas to Canvas. Just to give it a shot. As we had no tight dependence with GameCanvas, it was quite easy and fast to get it replaced. Bingo! You have no idea: problem solved! The app ran very well and memory consumption was very low. Incredible result.
Now, tell me why? Why is GameCanvas so heavier than Canvas to crash the app so fast? I do not see any reasonable explanation for that. Just what I see is an implementation bug on Jbed regarding GameCanvas. I confess I have not worked much with Java ME for Windows Mobile, so I do have much knowledge on Jbed. So if you have some comments on Jbed and would like to share with us, please let us know.
Just what I know is that a challenge like this makes our job fun, though we expend much time to solve it. Write once, port forever. :)
See you in the next post...
Showing posts with label workaround. Show all posts
Showing posts with label workaround. Show all posts
Nov 20, 2009
Sep 16, 2009
WORA: Really?
Hi all,
I believe most Java developers know that Java's slogan is "Write once, run anywhere", right? - I believed so! This slogan comes from the portability provided by Java platform, since any Java application is compiled to a intermediary code (platform independent), which is interpreted by a virtual machine specifically built for the underlying platform, i.e., JVM.
I also believe that most of developers have already witnessed situations where a certain Java application, which runs perfectly on Windows, for instance, does not go that well on Linux or Mac, right? - I bet so! It is always necessary, in some applications, some small adjustments to get them up and running properly. Most of times, those adjustments are necessary on applications that somehow use APIs that work with any resource from operation system (e.g. I/O, threads, etc.).
In mobile world the things are not different from any other platform. Actually, those incompatibilities are much more common. If you develop just for a certain line of devices, you are so lucky! Otherwise, be prepared (if you are not already), because even in devices from the same manufacturer, differences among devices can require many adjustments.
Today a witnessed an issue in a application that we are working on, that fortifies what I am writing about. The team was struggling to play a sound on Java ME application that already works perfectly on others devices from our client. However, for a specific device, the sound persisted in not working at all.
The team had attempted many imaginable ways to get a sound playing using JSR 135 - Mobile Media API. We also thought that it could be a platform's issue. But, when we were about to give up, We figured out something as a last resort: to play the sound is recommended to spawn a new thread to manage the player, so the application's main thread does not get blocked, right? We were doing that. What we did not know is that we should not spawn a thread, in order to play a sound, from a thread that was not the application's main thread. In our case, the parent thread was the accelerometer sensor's one (JSR-256). To sum up, to play a sound we had to spawn the player's thread from the application's main thread, instead of sensor's one. That's it! For some reason, the underlying implementation hanged the application.
Now, you tell me: where the heck could we imagine that? Even though on others platforms everything was working really fine. In the end, the most important, our client got very glad because we got the feature working and now he has the application ready to go. For us, that was one more lesson learned to be shared with our fellows.
Write once, run anywhere... tell me about it!!! Write once, adapt forever. :-)
How about you? Do you have any "freak" workaround to get a code working? Tell us!
See you in the next post...
I believe most Java developers know that Java's slogan is "Write once, run anywhere", right? - I believed so! This slogan comes from the portability provided by Java platform, since any Java application is compiled to a intermediary code (platform independent), which is interpreted by a virtual machine specifically built for the underlying platform, i.e., JVM.
I also believe that most of developers have already witnessed situations where a certain Java application, which runs perfectly on Windows, for instance, does not go that well on Linux or Mac, right? - I bet so! It is always necessary, in some applications, some small adjustments to get them up and running properly. Most of times, those adjustments are necessary on applications that somehow use APIs that work with any resource from operation system (e.g. I/O, threads, etc.).
In mobile world the things are not different from any other platform. Actually, those incompatibilities are much more common. If you develop just for a certain line of devices, you are so lucky! Otherwise, be prepared (if you are not already), because even in devices from the same manufacturer, differences among devices can require many adjustments.
Today a witnessed an issue in a application that we are working on, that fortifies what I am writing about. The team was struggling to play a sound on Java ME application that already works perfectly on others devices from our client. However, for a specific device, the sound persisted in not working at all.
The team had attempted many imaginable ways to get a sound playing using JSR 135 - Mobile Media API. We also thought that it could be a platform's issue. But, when we were about to give up, We figured out something as a last resort: to play the sound is recommended to spawn a new thread to manage the player, so the application's main thread does not get blocked, right? We were doing that. What we did not know is that we should not spawn a thread, in order to play a sound, from a thread that was not the application's main thread. In our case, the parent thread was the accelerometer sensor's one (JSR-256). To sum up, to play a sound we had to spawn the player's thread from the application's main thread, instead of sensor's one. That's it! For some reason, the underlying implementation hanged the application.
Now, you tell me: where the heck could we imagine that? Even though on others platforms everything was working really fine. In the end, the most important, our client got very glad because we got the feature working and now he has the application ready to go. For us, that was one more lesson learned to be shared with our fellows.
Write once, run anywhere... tell me about it!!! Write once, adapt forever. :-)
How about you? Do you have any "freak" workaround to get a code working? Tell us!
See you in the next post...
Subscribe to:
Posts (Atom)