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.
Related
The MyProjectName.app should be in the iPhone App structure directory as read-only, but in the project I have to join Test.sqlite and compile it, then I see the Test.sqlite in the MyProjectName.app.
I posted the project to the physical machine and inserted some data without issues. Is this the right way?
When I add the Test.sqlite and data on the iphone simulator, the Test.sqlite didn't appear to have any data. I have tried to copy the Test.sqlite to Documents. And then when I did it again, the data was displayed in the Documents's Test.sqlite. Do I need Test.sqlite to be copied to the Documents? thank you
The resources which are modified at runtime should be part of Documents directory. iPhone application creates a sandbox environment which is signed. If you try to modify any of the bundle resource, it will not allow. It works fine with simulator but not with device.
So, whatever resources are modified should be copied from bundle to documents directory.
Also, when upgrade is available, bundle is replaced with new version. However documents directory does not change. It remains same. If you want to carry any change with upgrade, you can modify data accordingly.
Hope it helps.
Check the Test.sqlite file is it read only or read/write.Change it into read/write.And if there is any lock for the project just uncheck it.
Does anyone know how iOS installs apps after they are purchased
The reason I ask is that I am going to modify a CoreData model and the existing unversioned model .mom file conflicts with the .momd versioned folder in a not clean install process with the usual "'Can't merge models with two different entities named 'Foo'' issue if using mergedModel...
No problem if I discard the app and start again but a big problem for Joe User.
I cant delete the original .mom file programmatically as that hits perms problems
So the question is , is an App Store upgrade a clean operation or is it a delta.
The new version of the application is completely downloaded. Once it is finished, the user files that are identified by the iOS documentation as persistent are copied to the same location in the new copy of the app. The old app is deleted and the application icon on the springboard will now launch the new version.
The answer below is great but also a solution to the actual problem is here
Core data migration failing with "Can't find model for source store" but managedObjectModel for source is present
a former coworker (artist) and myself (programmer) are currently developing a small game together in our free time. Since he is not at all interested in learning how to use XCode, save making his own builds (I don't blame him, he is a great artist, but with only little understanding for technical stuff), this is how we have been working so far:
We share a dropbox folder where we store all the ingame artwork
Once enough or important changes have been made, I'd create a build (ad hoc distribution) and send it to him
From time to time we'll meet and work together a couple of hours, maybe once a week since we live in different cities
This was ok for most of the time. However now we're busy finetuning the content and game mechanics. In this development stage, our workflow is just to slow and "disconnected". Whenever he is working on the artwork, he'll have to wait for me to make a build to be able to see the changes reflected in the actual context. Since we're not always working at the same time, this sometimes means he'll have to wait for days - not at all satisfying.
So, what I'd like to know..: What would be the best way to allow him to change the content without the need to rebuild the game?
I know the contents of an iOS app bundle cannot be changed once compiled. So here's what I was thinking about so far:
move the content to the documents folder during development so that it can be accessed via iTunes (handling propably awkward in light of the amount of files in question)
incorporate dropbox into the game, so that the content could be loaded right from our shared folder (extra work needed to implement this, dropbox restricted to 5000 API calls per day while not in production status)
load the content from a webserver (even more complicated compared to using the dropbox)
What do you guys think? Are there better and more comfortable ways to achieve smooth collaboration in our case? Am I missing something?
Thanks alot!!
Edit:
At the moment, I have no plans whatsoever to teach my artist how to make his own builds. You can seriously consider this to be an option only as long as you don't know him in person. He's a great artist, though.
So this question boils down to:
How do I modify files / get new files into an iPhone app after it has been built - as easily as possible and, again, without rebuilding the app?
This has to work during development only, by the way, so dirty approaches are welcome.
In some of the WWDC 2010 videos, Apple discusses this. They advise loading artwork from the web and applying it to UIKit elements or OpenGL contexts programatically.
This is complicated, but a good method, because then you make NO changes to your binary and then your artists can work freely, upload the art to a server and you're golden.
I suggest a good HTTP library, like ASIHTTPRequest, to make those requests easier.
Go with the Web server/dropbox option. You might be able to do this by subclassing or extending UIImage and using the subclass throughout your app.
Jailbreak your iPhone, Then you can ssh into the device using Cyberduck. That way you can navigate to the app's Resources folder (or) App's document folder and change files as you want.
You will have to make sure the folder permissions are proper, or else you need to change them.
Also in your game, in the first run, make sure all your resources are getting copied to the App's documents folder.
I would say that your first option is probably the best. You state the issue with transferring a large number of files through iTunes. To fix that I would to the following:
Create an app to create "package" files. It can take a folder of data and save it in a single in file in the following format:
int - length of name string
char[] - filename
int - length of data chunk
char[] - data chunk
Do this for every file in the folder, and you'll be left with a single image file. Copy that through iTunes, and have your game look at that same folder.
So now his workflow is as follows: 1) edit art 2) run your asset compiler 3) copy the asset file to the device 4) load the game
I hope this helps.
You could also do something like this:
modify the app so on its first start it copies the images into the document folder
load the images from the doc folder instead than from the bundle
with a tool like iPhone Explorer you can then overwrite the files in the document folder
it's a bit boring to find the actual app in the list that iPhone explorer gives you, but then it's just a matter of dragging and dropping the files into the right folder.
It may work also with some file in the .app bundle, but I didn't found any suitable app to try it from there.
Anyway if you want to keep the thing almost hassle free for your artist you may want to put everything in a Documents subfolder nonetheless :)
EDIT
I just tried to edit something into the .app folder and it worked OK, so you don't even have to change your code if you use iPhone Explorer to replace images.
Just remember to disable the PNG optimization if you're using PNGs. Look here for the explanation (search for "PNGs:")
good luck :)
I would say set up a CVS repository. When you're happy with what you have, you can commit your code. He can update his code and change the images however he wants. When he's happy, he can commit his changes so you also have the latest images (as long as he doesn't mess around with out files, it should be fine).
Teach him how to update the images, how to deploy to a device, how to commit to the repository and it should go smooth (albeit I think there'd be some teething issues).
I want the user to be able to access the files in the documents directory but am using core data and dont want the user to be able to access the store (the sqllite db), can i hide it from the user while still allowing file sharing, or can i put it in another directory where it will still get backed up?
The answer given by FrenchKiss Dev is not correct. The user will still be able to see the ".data" directory in iTunes and save that locally with all the files inside it.
Instead, store private documents in Library/Preferences
According to Apple:
In addition to the directories documented previously, the entire
/Library directory has always been preserved during
updates and backups, except for /Library/Caches.
Because of this, applications can create their own directories in
/Library/ and those directories will be preserved in
backups and across updates. To minimize the risk of name collisions,
we recommend that you name this directory carefully. For example, a
directory named Private Documents would be a good choice. You should
store any files you don't want to share to Library/Preferences.
In the documents directory, create a subdirectory which name starts with a dot. For example:
.data
EDIT: Please stop downgrading this answer !
This answer was correct at the time (remember that it was before the iPad was actually available! And there was a lot of confusion on the matter, we were still hoping for the iPad to appear in the shared devices in the Finder...).
Today (April 2012) it is still working on the Mac but not on Windows (starting a directory name with a dot means nothing in Windows).
Anyway, this Shared Document feature is a mess. Later they fixed it by saying that "Private Documents" should be stored in the Library Folder not in the Documents folder. But remember that developers were already using the Document folder before the iPad came.
Don't blame me for Apple mistakes.
Stack Overflow should have a way to mark an answer as obsolete.
API changes, get fixed, and it renders answers obsolete.
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.