I'm gonna release a new version of my app. The previous version used some files which in the newer version are changed and need to be processed. I want the older files to be automatically deleted when the user updates the application, otherwise the application sees them and will process them (resulting in an error because the format of the files changed).
Is there an option to do that?
Thank you.
Since you are processing these files, one option is to somehow put the format version in the files or in folder path. Bake that version into a constant in the app.
The app can either always look for those files by appending the constants to the path where you get these files, or look into the data of the file to get the format version and handle it properly (delete, redownload etc...).
Another benefit is that if you release your app and the format version does not change (likely - you just fixed bugs), you don't have to delete and re-download those files. You also don't have to change anything or update any routines - simply don't change the file format constant and it won't change your files. If you change the format of the files, update that constant and it just works.
It's always a good practice to get the version of your app from the bundle in code and perform necessary changes as needed:
NSString* versionString = [[NSBundle mainBundle] objectForInfoDictionaryKey:(NSString *)kCFBundleVersionKey];
Then you can compare this string (or float version of the string) to determine what changes to make to the data. You might delete the old data (as in your case), or extract some of the old data and create new data (the usual way), or the app may need no changes at all.
The BIG thing to keep in mind is you may upload/release several versions of an app and some users may not have downloaded the newer versions. Because of this, it's good practice to have methods update the data based on the version string, instead of expecting it to be the last version of the data.
Related
I am currently using Google cloud storage to store some files. From the PHP side, I am able to use these files just fine. Now I want to extend this functionality to store 4 good versions of these files so that I can change the file path through symlink(or any other alternative way is that's not an option) on PHP side in case the latest set of files get corrupted. I am wondering how to go about this.
I appreciate any suggestions that you might have.
Cloud Storage offers a versioning system as a feature that you need to enable. Versioning allows for you to save a file with the same title and the system archives the previous version and displays the new one. In this case, if there was a corruption, you would have to go into the Cloud Shell and retrieve the previous copy.
If you do not wish to go that route, I can suggest save 4 copies with distinct names(ie: fileName[number]). This way, you would take the newest file, retrieve a substring containing the number, and creating your new file based off the substring.
In both methods, you are able to roll-back to a previous version.
Cloud Storage does not allow for symlinks.
I'm working with a designer friend on an iPhone app and he likes to refine all sorts of images relating to the project we're working on. All these images have been added to the project previously (and added to the project folder by xcode) and then are modified in their new location. When I preview the images in xCode, the updated images show up but building and running in the simulator or on a device doesn't pick up the new image. In fact, if I do a clean build it seems to ignore the image all together and blank spaces appear where images should be.
Now, I can delete these files from the project and re-add them and everything works peachy again. But there are a lot of them and I'd rather not do that every time an image is updated. Is there a way to get xCode to review and "learn" about these modified images? Is there a good reason for why it's not doing that automatically?
You didn't specify how you're including those image resources into your project, but I'd guess you're including them directly. So unless there's an underlying process that's changing the file in-place (are you using an SCM like Subversion or Perforce?) you're going to be forced to manually overwrite the files whenever your artist friend updates them.
You should include art assets in the project using a folder reference instead. (I'm still assuming you have some sort of SCM set up to handle exchanging data -- if you don't, set one up ASAP.) However, there are still some outstanding Xcode bugs related to picking up changes to files in a nested folder hierarchy included by reference, but at least you can work around that by doing clean builds when necessary.
I'm working on an update for an already existing iphone app. The existing version contains a .sql database file which is used in the app.
I would like to use a new version of this file in the update of the app. On the first startup of the existing app the .sql file is placed in the caches directory of the users iphone. From what I can understand from Apple's documentation the files in the caches directory might get copied from the old app to the new versions caches directory when the user updates the app.
Does this mean that for being sure my new file is used in the updated version I should use a different name of the file?
And what happens with the old file? Do I have to manually delete it from inside the app? Which means I have to check if it's there at every startup of the app?
Thanks
Michael
Yes, you could use a different name, or you could use the same name, and do an "upgrade" (delete and replace) on the first time the user uses a new version.
This does imply checking at every app start, but that's not a bad idea anyways. Having some code that checks versioning at app start lets you put any data upgrade stuff in one place.
One technique is to use NSUserDefaults to keep around two pieces of information: the originally installed version of the app, and the most recently run version of the app. You check these at startup. If they're not there, write both of them. If the most-recent version is lower than the running app version, run your upgrades and bump the version. You could use the first flag to know conditionally in other places whether to expect certain data to be sitting around or not. Having versioning stored explicitly lets you know which version you're upgrading from, too, which might not be obvious if the user hasn't downloaded say 5 intervening updates.
I've written an app that uses some of the user's camera roll images, and while it does so it stores them in the application root directory. The problem I have is that whenever I re-compile my application it changes the folder to which the application is installed.
Is there any way I can specify which folder it should build to, so that any path information stored during it's last run will still be valid?
I don't think that this is something you can stop Xcode from doing unfortunately. It should be copying the data from the old location to the new one but sometimes that just doesn't happen.
The answer suggested in this question looks like the solution you are after.
We (occasionally!) have to issue hot fixes for our product and do this by reissuing the affected files directly rather than with a new installer. The product has a large number of pieces, some managed code, some unmanaged.
Currently development flags which build artifacts (exes, dlls) need to be shipped in a hot fix. We'd like to be able to identify these automatically by comparing them to the previous build. A simple binary diff doesn't work since the version numbers on all the files have changed as stamping the files with a new number if part of the build.
Are there any tools that will do a more intelligent comparison and decide which files should be included? We'd still have a developer check the list, this is more to catch files the developer didn't think of than the other way around.
(Note: changing the hot fix/build process is not an immediate option, whether or not we should be shipping individual files is a different discussion!)
These are the options I see:
On your build machine get a report of the files that were changed and use the directory structure of the file path to determine which dlls were really updated. Not sure if this breaks your "no build process changes" rule or not.
If you want to wait until after the build I would recommend using a binary file diff tool like http://www.romeotango.com/Downloads/FileCompReadMe.txt. Using that you can get back a set of diffs so you just need to get your script that uses the tool to ignore the diff that occurs as a result of the version number. You can figure out the pattern to how the version number appears by using a controlled scenario where you know the two binary files are the same except for the version number and note where the differences are. Do that for a few of your dlls and hopefully a pattern emerges enough so that you can script it.