I have a Blackberry app that stores an object in the persistent store. After updating the app, it is supposed to read the existing value from the persistent store, if any, and continue to use that value. This works on some devices, but does not work on others. I tested on several devices running OS version 7, all of which work as expected. However on a device using version 5 and another using version 6, the object is no longer readable in the persistent store.
This is the case even if I don't change anything about the app other than the version number. Same exact class/object being saved & loaded from the persistent store, and same object ID used to access it.
The process I'm following to reproduce this is:
Completely delete the app & all it's data using the command line.
Load a version of the app, by downloading a .jad file from a browser, verify that it stores data in the persistent store.
While the app is running in the background, load a later version via browser download of the .jad file.
After downloading the later version, the system asks if I want to replace the previous version, and I confirm that I do.
The system loads the new version, and prompts that I must reboot for the change to take effect. I select "Reboot".
Device reboots. The later version is running but cannot read the object from the persistent store.
A device on which I can consistently reproduce this issue is a Blackberry 9800 (Torch) running 6.0 Bundle 2647.
As mentioned above this only happens on some, not all, devices, which makes me think something other than a coding bug may be going on here.
Anyone have ideas about this issue or how to debug it further?
Peculiar case.
Are you sure the persistent storage is being committed? Something similar generally occurs for me when data has been stored in the storage but not committed. If that is the case, and you load the older version, store some data and reboot your device, the data will not be stored in persistence.
You mentioned that the app is still running in the background when you load a later version. You may want to check whether commit() gets executed or not.
Related
I have been working on an app in Xcode (not submitted to the App Store or anything like that) that has a lot of very important data whose loss is insurmountable. The app has recently started crashing on startup; therefore, I have tried to update the code to Swift2 so that it works.
After having Xcode automatically update this app to the new version of Swift, I have been having a major issue: When I re-download the app using a cable plugged into the iMac and the iDevice, the new version of the app does not replace the old one––it adds another app to the device. Why would this be happening, and, more importantly, is there any way to fix that?
The point of this is to retrieve the data which was saved in UserDefaults to the previous version of the app. Hence, I'll do pretty much anything to get that data back.
It is absolutely imperative that I retrieve the data stored in UserDefaults; the data is not stored anywhere else.
You are correct that the key is the bundle ID. We have a main bundle ID for production and a second target with a different ID for testing. Pretty convenient to have different versions of the app on the same device.
The second thing you can check is that the version number in the new project is greater than the version on the original project.
To see what apps and versions are installed on your phone, go to Devices (Shift-Command-2). Select your phone from the list on the left and the manually installed apps will be listed near the bottom. Sometimes this gets covered by the Console messages so you might need to scroll down.
Here's what the Device Manager looks like--I deleted my console logs...
Here is the Installed Apps view. It is behind the console logs so you need to scroll down in the top area...
At one point there was an AIR bug (3.5) that changed the location of the LSO storage, causing local SharedObjects to be "lost" after an app update. Apparently this issue was resolved in 3.6 and life goes on.
At this point I don't have 100% confidence that any user data stored in a SharedObject on an iOS device will persist after an AppStore update, and I would like to be able to test this out prior to actually submitting the update to Apple.
However, my experience has been than whenever you test/debug your app and a new IPA is generated, the old app is completely wiped, including all of its data. So there's no way that I know of that I can test an update of the app against an older version to ensure that the SharedOjbects remain accessible and working fine.
Are there any solutions? Or can anyone who's using LSO for persistent App data storage confirm that they've pushed an update through the App Store and retained saved user data?
I have a development distribution of an app out on a couple of devices.
Turns out my export functionality causes a memory leak - meaning I can't get that screen to open without reinstalling the distribution of the app.
Is that data totally lost? I'd really like to be able to save it.
Some ideas:
Write a second helper app that could grab the data
Write some sort of shell script that could retrieve the data plugged into a comptuer
Plug in the devices to a computer... do something in Xcode... no lost data?
Is there any hope?
UPDATE
There was hope!
First - Your data is accessible via Organizer in XCode.
Second - New versions in iTunes do not overwrite core data. BUT you're going to want to make sure the version # increases as iTunes was somewhat finicky about sending over the new version. Your testers might be tempted to delete the app - replacing it in iTunes and re-syncing is all they need to do.
If you update the app without deleting it first, the data is not removed by the OS. So the new version of your app has the opportunity to read the old data.
I am new to iOS development so my question may be n00bish.I am working on an app for iPad which downloads PDFs and stores on the device(iPad) in the Documents directory so the user can still read them if he isn't connected to WiFi. My question is:if a newer version of the app is available and the user installs it, will it delete all the data(documents,in this case) from the device? If yes,how do I prevent the old data from being deleted? I am using CoreData in this app(if this helps)
When a user installs an updated version of any app, the app's sandbox is kept intact. Only the app and its resource bundle are replaced. So basically, anything you have stored in Documents or Library will be kept intact after the update process. There is no guarantee that files in Library/Caches or tmp will be kept but those should only have transient files anyway.
We need to test our app in the context of an iOS upgrade (e.g., 5.1 -> 6.0). Unfortunately, Apple doesn't allow downgrading devices. We thought of doing it in the simulator, but different versions of the simulator are different environments in themselves. I think we can copy the bundle from one simulator to the other, but that won't migrate the keychain (will it?).
Thanks!
To test a transition from one state (before) to another (after), you need a way to put the app in the before state.
Your app surely won't be running while the OS is being updated, so you really only need to worry about the app starting up and discovering that the OS has been updated. There are a couple options:
Copy all your app's data files from a device running the "old" iOS version (5.1 according to your question) to a device running the new (6.0) version. The organizer in Xcode will let you easily copy your app's "container" from a device to your Mac or vice versa.
Make your app write it's data in the "old" format. It's not uncommon for an app to have methods for reading and writing data in different formats depending on the environment, so it's often easier to get your app to write data out in the old format than to actually copy from an old device.
Whichever path you choose, think about any other places (like user defaults) where you might made OS version-dependent changes and set those back to values that correspond to the previous OS. This applies especially to keychain items, which aren't stored in your app's sandbox.
Unit testing frameworks (like Apple's XCTest framework) generally have a setup mechanism that you could use to reset your app to the before state, including copying files, adding and removing keychain items, setting defaults items, etc. You can then add unit tests that run whatever code might be involved in an update and test the results. With a set of easily repeatable tests you'll be able to debug any problems more easily.
However you approach it, the goal is to put the app in the same state that it would be in if it were running for the first time after an OS update occurred. You don't have to worry about simulating the actual OS update, you only need to trick the app into thinking that the update has just happened.
For now, you can still install iOS 8.2. When a new version is released, Apple leaves both versions open for installation for a short time. While that "signing window" is open you can upgrade a device, test, and then restore it from an image of the older version. So you could do some intensive testing while the window is open, but obviously that's not a long-term solution (it typically lasts only a few days).
If you have the budget for it, you could install 8.2 on a device, put a big sticker on it saying "do not upgrade", and keep it on 8.2 for as long as it's relevant. Install your app on that device and take a backup (with backup encryption enabled so that keychain entries will be included), then restore that backup to another device that's on 8.3 - this is basically the same procedure you'll go through when doing an upgrade/restore through iTunes so it should be pretty close. It won't be exactly the same as an OTA update on-device of course, but for that, see option 1 above (and see it soon).