Why must the device be restarted after an application update? Does this indicate problems in the future?
After experimenting quite a bit, and posting a few questions, Mark Sohm from RIM (BlackBerry Developer Journal) has filled us in on the conditions that an application update forces a restart:
This can be a huge productivity issue, as some more loaded down devices require as much as 15 minutes (no kidding) to restart.
But a larger issue is looming.
This must mean that there is only one classloader in the RIM JVM. I can understand why the design decision was made (device capacity), specifically at the time it was first rolled out, but is this the way it will continue? Are there plans to revisit the classloader issue?
It indicates problems ahead if they aren't addressed.
As the devices become more powerful, applications will become more complex. This is happening today. With that natural progression, developers will move away from monolithic single codebases for applications towards composite applications, with commonly reused libraries. If any of you have attempted this, you will recall the class 'multiply defined' issue. Since there is no classloader isolation (such as in J2EE web applications), this causes a slew of issues.
For example, it is not far fetched to assume that developers will want to use a BlackBerry version of log4j. We certainly have ported it for use in our core libraries. In hopes that it will someday be well supported on the platform, we have left it in the org.apache.log4j packaging so we can essentially move to a community supported library when one is available (and we can contribute to). That is another discussion.
What if *any* other developer in the world has the same idea, or the community library is readily available and reusable? *Any* user in the world that happens to install applications from different developers will render one application unusable.
RIM's current answer to this would be to deploy the log4j as a 'library' on the device. Good idea, but what if Vendor A uses log4j 1.0 and Vendor B uses an incompatible version 1.2? The application installed last will win. Regardless, it means one application will NOT function.
Our company (Metova) has a lineage in J2EE, so entering mobile development, we naturally began developing reusable libraries for applications. We had no issues on the Windows Mobile environment (eRCP using the J9 JVM). In shifting our focus to BlackBerry, we were stunned that we can't reuse our core library on the same device unless we go through great pains to keep *every* application we have *ever* developed compatible with a readily available update for *every* user, *ever*.
I hope I have stressed *every*, *ever*, *world* enough in that last paragraph. This is NOT reasonable.
Developers know, cutting a release is more than just 'getting it to compile'. Testing is necessary for all releases. If you make a change to one of your core classes, are you prepared to put every application you have *ever* built into a testing/release process?
It is clear that this is a huge issue in the BlackBerry platform, as innocuous as it seems on the surface. The question is what will RIM do about it? Maybe they are already working on it?
As much as I hate to say it, until such time RIM addresses the issue, you will not be able to reliably, confidently reuse *any* community project with confidence that it will work reliably.
If someone from RIM could fill us in with a roadmap, it would make us much more comfortable. We would also be glad to meet with RIM to discuss how the problems are impacting us today and give our input on potential solutions.
- Kevin Ross
Kevin Ross is president of Metova LLC. If you have projects needing Blackberry Application Development, you may contact the author at Kevin.Ross@Metova.com, or make a general inquiry at info@Metova.com
1. The application is running or the library is in use.
2. The application has any open resources (ie: a library could be holding onto something).
3. The application has an active listener registered with the system.
4. The application has added menu items to any BlackBerry applications.
5. It is an auto start application.
6. The application is listening for incoming IO connections (this would also fall under the "application is running" reason).
7. The application makes use of persistent storage and/or backup/restore features.
This can be a huge productivity issue, as some more loaded down devices require as much as 15 minutes (no kidding) to restart.
But a larger issue is looming.
This must mean that there is only one classloader in the RIM JVM. I can understand why the design decision was made (device capacity), specifically at the time it was first rolled out, but is this the way it will continue? Are there plans to revisit the classloader issue?
It indicates problems ahead if they aren't addressed.
As the devices become more powerful, applications will become more complex. This is happening today. With that natural progression, developers will move away from monolithic single codebases for applications towards composite applications, with commonly reused libraries. If any of you have attempted this, you will recall the class 'multiply defined' issue. Since there is no classloader isolation (such as in J2EE web applications), this causes a slew of issues.
For example, it is not far fetched to assume that developers will want to use a BlackBerry version of log4j. We certainly have ported it for use in our core libraries. In hopes that it will someday be well supported on the platform, we have left it in the org.apache.log4j packaging so we can essentially move to a community supported library when one is available (and we can contribute to). That is another discussion.
What if *any* other developer in the world has the same idea, or the community library is readily available and reusable? *Any* user in the world that happens to install applications from different developers will render one application unusable.
RIM's current answer to this would be to deploy the log4j as a 'library' on the device. Good idea, but what if Vendor A uses log4j 1.0 and Vendor B uses an incompatible version 1.2? The application installed last will win. Regardless, it means one application will NOT function.
Our company (Metova) has a lineage in J2EE, so entering mobile development, we naturally began developing reusable libraries for applications. We had no issues on the Windows Mobile environment (eRCP using the J9 JVM). In shifting our focus to BlackBerry, we were stunned that we can't reuse our core library on the same device unless we go through great pains to keep *every* application we have *ever* developed compatible with a readily available update for *every* user, *ever*.
I hope I have stressed *every*, *ever*, *world* enough in that last paragraph. This is NOT reasonable.
Developers know, cutting a release is more than just 'getting it to compile'. Testing is necessary for all releases. If you make a change to one of your core classes, are you prepared to put every application you have *ever* built into a testing/release process?
It is clear that this is a huge issue in the BlackBerry platform, as innocuous as it seems on the surface. The question is what will RIM do about it? Maybe they are already working on it?
As much as I hate to say it, until such time RIM addresses the issue, you will not be able to reliably, confidently reuse *any* community project with confidence that it will work reliably.
If someone from RIM could fill us in with a roadmap, it would make us much more comfortable. We would also be glad to meet with RIM to discuss how the problems are impacting us today and give our input on potential solutions.
- Kevin Ross
Kevin Ross is president of Metova LLC. If you have projects needing Blackberry Application Development, you may contact the author at Kevin.Ross@Metova.com, or make a general inquiry at info@Metova.com
posted by Kevin Ross @ 9:45 AM
0 Comments:
Post a Comment
<< Home