BlackBerry Forums Support Community               

Closed Thread
 
LinkBack Thread Tools
Old 09-05-2008, 02:49 AM   #1 (permalink)
Knows Where the Search Button Is
 
Join Date: Jun 2008
Model: 8100
PIN: N/A
Carrier: Vodafone India
Posts: 39
Post Thanks: 0
Thanked 0 Times in 0 Posts
Default Stored data gets lost on upgrading the application

Please Login to Remove!

Hello mates,

When I upgrade the application to the latest version, all previous data get deleted from the handset.

Is there any way by which all data/ persistent storage would remain stored for the new version which were used in previous version?

Thanks,
Alpesh
Offline  
Old 09-05-2008, 03:29 AM   #2 (permalink)
CrackBerry Addict
 
Join Date: Apr 2005
Location: hamburg, germany
Model: 8900
Carrier: o2
Posts: 838
Post Thanks: 0
Thanked 0 Times in 0 Posts
Default

persistent store is related to the application, if you remove the app the store gets deleted, too.
you could either use the j2me storage (rms) - which is a bit difficult to handle.
or you could make an own project for data storage that does only get replaced if there are changes in the data structure.
__________________
java developer, Devinto, hamburg/germany
Offline  
Old 09-05-2008, 03:52 AM   #3 (permalink)
Knows Where the Search Button Is
 
Join Date: Jun 2008
Model: 8100
PIN: N/A
Carrier: Vodafone India
Posts: 39
Post Thanks: 0
Thanked 0 Times in 0 Posts
Default

Hi Simon,

Thanks for the input.
Quote:
you could make an own project for data storage that does only get replaced if there are changes in the data structure.
Application frequently uses storage, so I think this would be complex way of doing.

RMS is also not recommended for my application, as I need to store objects.

What else I can do?

Thanks,
Alpesh
Offline  
Old 09-05-2008, 04:31 AM   #4 (permalink)
Talking BlackBerry Encyclopedia
 
Join Date: Apr 2008
Location: Germany, BW
Model: -
PIN: N/A
Carrier: -
Posts: 310
Post Thanks: 0
Thanked 0 Times in 0 Posts
Default

Normally my application keeps its data during an update. This means if I install a newer version without deleting the old one.
Otherwise all persistant object which belong to your application will be deleted, too as Simon already said.
Offline  
Old 09-05-2008, 05:39 AM   #5 (permalink)
Knows Where the Search Button Is
 
Join Date: Jun 2008
Model: 8100
PIN: N/A
Carrier: Vodafone India
Posts: 39
Post Thanks: 0
Thanked 0 Times in 0 Posts
Default

Thanks, Ivanov

I am not explicitly deleting the previous version of the application.

My application checks for the update, and New version will be downloaded and installed if update is available. (During download process older version of the application is still running)

After installing the latest version, prompt will be displayed to reboot the handset and after restarting the device, only latest application is available. All storage data gets deleted. So, I have to do all configuration settings again and I do not want that.

Thanks,
Alpesh
Offline  
Old 09-05-2008, 06:39 AM   #6 (permalink)
Talking BlackBerry Encyclopedia
 
Join Date: Apr 2008
Location: Germany, BW
Model: -
PIN: N/A
Carrier: -
Posts: 310
Post Thanks: 0
Thanked 0 Times in 0 Posts
Default

Which API version are you using and how do you replace the running instance of your application with the new one? Is the "updater" a separate application?
Offline  
Old 09-05-2008, 06:54 AM   #7 (permalink)
Thumbs Must Hurt
 
Join Date: Apr 2006
Location: Boston
Model: 8900
Carrier: AT&T
Posts: 98
Post Thanks: 0
Thanked 0 Times in 0 Posts
Default

Hi!

My team went through a great deal of challenges in discovering the ways and means of upgrading-applications-and-migrating-persistent-data. It was all kinds of fun.

There are several ways to handle persistent-data migration. One is to have your application set up to back-up your data to a BES - this will only work if your users have a BES that they are connected to, and so this may not be appropriate for your solution.

My team discovered that data stored in a Persistent Storage mechanism will not be maintained if there is no class type available that matches the object class-types stored in Persistent Storage. So if your application is storing an object of type com.myapp.Settings in Persistent Storage, and you delete MyApp from the device, the com.myapp.Settings data will be removed. However, if your application stores its data in Persistent Storage using class types that are guaranteed to be around (i.e., standard class types such as java.lang.String, java.lang.Integer, any of the RIM types, etc.), then the Persistent Storage mechanism will maintain the Persistent Storage of those objects placed there, even if your application is deleted. So if your application is storing information contained in com.myapp.Settings as String, Integer, or other "standard" types, then the persistent storage data will be maintained across an upgrade and/or even removal/re-installation of your application.

This may or may not be good, depending on your application. For instance, I would be a little concerned about passwords and credit card info being stored as Strings in a persistent manner - granted, an attacker with access to my device (either physical or through a Trojan app) would have to know the particular long ID value assigned by the application to reference its particular Persistent Storage data block, but it's still a little worrisome.

Another approach my team and I discussed, but did not implement, was a "two-stage" upgrade: a user would install a separate application, while the prior version of the application we wanted to upgrade was still in place, read the persistent storage data block of the "old" application (which would be possible since we already know its ID), create a new persistent storage data block containing "serialized" versions of the "old" information, delete the "old" application, and then install the "new" application which would load the serialized data into its own persistent storage block. This mechanism requires that the data in the "old" persistent storage block already be accessible via a "toString" method, since the "transitional" application cannot use the same class types to read the contents of the "old" persistent storage data (class conflict would result).

Sorry to be long-winded. Hope this helps.

Cheers,

karl
__________________
Karl G. Kowalski
---------------
Owns a RAZR
Develops for BlackBerry
So next phone will be........an iPhone 3G!
Offline  
Old 09-05-2008, 08:40 AM   #8 (permalink)
Knows Where the Search Button Is
 
Join Date: Jun 2008
Model: 8100
PIN: N/A
Carrier: Vodafone India
Posts: 39
Post Thanks: 0
Thanked 0 Times in 0 Posts
Default

Hi Ivanov,

My application is invoking browser during update process and as soon as user agrees to upgrade the application, older version may be removed from the handset before installing the latest version and at the same time data stored in the form of com.myapp.Settings may also be removed.

Karl,

So nice of you in being more elaborated.
let me try and apply the approach discovered by you.
Will get back to you on this.

Thanks,
Alpesh
Offline  
Old 09-05-2008, 08:47 AM   #9 (permalink)
Thumbs Must Hurt
 
Join Date: Apr 2006
Location: Boston
Model: 8900
Carrier: AT&T
Posts: 98
Post Thanks: 0
Thanked 0 Times in 0 Posts
Default

Good luck! May The Force be with you!

I think my greatest issue was the lack of a message along the lines of "by the way, when your app is deleted, all app-specific objects in the persistent store will be deleted as well" somewhere in the docs. We learned a lot about a variety of things in our project related to upgrading and migrating. Two rather challenging points we also discovered, in addition to the above:

1. If your MyApp v1.0.5 is sitting on a device and it has stored objects of type com.myapp.Settings in the Persistent Store, and - using Desktop Manager - you attempt to "upgrade" to MyApp v1.0.6 but this new version does not have a class of type com.myapp.Settings in its COD file, Desktop Manager will download MyApp v1.0.6, and then fail with an obscure error.

2. If you have two classes, com.myapp.Settings and com.MyApp.Settings, the pre-verifier stage of the rapc build will fail with an obscure error. This is actually a problem with Sun's pre-verifier tool (RIM's pre-verifier is just Sun's). Now, you may ask, why would anyone ever have a package segment name in capitals? Sure, I can follow the "Sun Microsystems' Bible Of Java Coding Practices" but someone (not me, I swear!) didn't do so in this particular project, once long ago. My issue is that since Java is supposed to be case-sensitive, why is the pre-verifier *not*? The only guess we could come up with is that when dealing with non-UNIX-based systems, since the package naming implies a particular file hierarchy, since the folder names in the non-UNIX-based filesystem are case-insensitive, the package naming conventions imposed by the pre-verifier require the package name segments also to be case-insensitive. Which makes the pre-verifier unhappy because effectively, com.myapp.Settings and com.MyApp.Settings are identical classes and cannot co-exist. I'm sure it makes sense to *someone*.
__________________
Karl G. Kowalski
---------------
Owns a RAZR
Develops for BlackBerry
So next phone will be........an iPhone 3G!

Last edited by holy3daps : 09-05-2008 at 08:58 AM.
Offline  
Closed Thread


Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On





Copyright 2004-2014 BlackBerryForums.com.
The names RIM and BlackBerry are registered Trademarks of BlackBerry Inc.