Yes, I know. This question have been already replied in Where to store the Core Data file? and in Store coredata file outside of documents directory?.
#Kendall Helmstetter Gelner and #Matthias Bauch provided very good replies. I upvoted for them.
Now my question is quite conceptual and I'll try to explain it.
From Where You Should Put Your App’s Files section in Apple doc, I've read the following:
Handle support files — files your application downloads or generates and
can recreate as needed — in one of two ways:
In iOS 5.0 and earlier, put support files in the /Library/Caches directory to prevent them from being
backed up
In iOS 5.0.1 and later, put support files in the /Library/Application Support directory and apply the
com.apple.MobileBackup extended attribute to them. This attribute
prevents the files from being backed up to iTunes or iCloud. If you
have a large number of support files, you may store them in a custom
subdirectory and apply the extended attribute to just the directory.
Apple says that for handling support files you can follow two different ways based on the installed iOS. In my opinion (but maybe I'm wrong) a Core Data file is a support file and so it falls in these categories.
Said this, does the approach by Matthias and Kendall continue to be valid or not? In particular, if I create a directory, say Private, within the Library folder, does this directory continue to remain hidden both in iOS 5 version (5.0 and 5.0.1) or do I need to follow Apple solution? If the latter is valid, could you provide any sample or link?
Thank you in advance.
I would say that a Core Data file is not really a support file - unless you have some way to replicate the data stored, then you would want it backed up.
The support files are more things like images, or databases that are only caches for a remote web site.
So, you could continue to place your Core Data databases where you like (though it should be under Application Support).
Recent addition as of Jan 2013: Apple has started treating pre-loaded CoreData data stores that you copy from a bundle into a writable area, as if they were a support file - even if you write user data into the same databases also. The solution (from DTS) is to make sure when you copy the databases into place, set the do-not-backup flag, and then un-set that if user data is written into the database.
If your CoreData store is purely a cache of downloaded network data, continue to make sure it goes someplace like Caches or has the Do Not Backup flag set.
Related
net project as well as a setup project. I also have it so that during installation it asks the users to enter a file location to store their database. the plan is to have an empty .mdf file, with all the tables setup, copied into that folder and I store the folder path in a config file.
this is mainly because I am planning on having multiple separate applications that all need the ability to access the same database. I have it storing the folder path in my config file the only thing I'm having trouble with is
storing the template files I don't know if i should do this in the setup project or main project
how to copy said template files into a new folder
so far I have been unable to find a solution so any help is appreciated
Well here is what I do this in a few of my projects - something that has proven reliable enough for me over the years (which you may or may want to do as well):
I have the program itself create the database files in an initialization routine. First however, it creates the sub folders in which the database files will be stored, if they don't already exist.
To do this, the program just checks if the folder exists and if the database file exists and if they do not, it creates them on the spot:
If Directory.Exists(gSQLDatabasePathName) Then
Else
Directory.CreateDirectory(gSQLDatabasePathName)
End If
If File.Exists(gSQLiteFullDatabaseName) Then
Else
...
I also have the program do some other stuff in the initialization routine, like creating an encryption key to be used when storing / retrieving the data - but that may be more than you need (also, for full disclosure, this has some rare issues that I haven't been able to pin down).
Here too are some addition considerations:
I appreciate you have said that you want to give the user the choice of where to store their database files. However, I would suggest storing them in the standard locations
Where is the correct place to store my application specific data?
and only allowing the users to move them if the really need to (for example if the database needs to be shared over the network) as it will make the support of your app harder if every user has their data stored in different places.
I have found letting the user see in their options/settings windows where their database is stored is a good idea.
Also to encourage them to back those files /directories up.
Also to create automatic backups of several generations for the user.
Hope this helps.
I've read a few threads where this is discussed. Shai's response has always been that files can only be read, but not written into shared locations
Perhaps saving other type of files isn't so simple but shouldn't there be an option for saving pictures in CN1?
I haven't seen the Whatsapp Clone code, but if it truly is a clone shouldn't it have the option to share pictures (and possibly files). Or is it a simple text chat that perhaps shares pictures that can never be saved outside the app?
I also read somewhere (6 months ago) that Shai said that this should be a feature of CameraKit. Does this mean that this feature is in development? If so, that would be great. But having an ETA would also be great to align with our own devs
If it isn't being developed, can I at least know if this is something I can develop natively within CN1?
We expose the full file system so you can write to any place the native App can write to. Native apps don't have write access to the gallery directory and need to explicitly request it to put a file there. This can be accomplished easily in any external cn1lib (e.g. we could do it in camera kit) but haven't done it for camera kit or the whatsapp clone.
AFAIK there's no RFE open on this feature so I can't even tell you if it's assigned to a specific milestone.
I have an embedded C project which uses subversion for source control. I want to use Tessy for unit testing and have these tests archived in subversion too. However, it generates many small files which will make analysing diffs for the actual source code changes a real pain. Trying to actually look at the source changes when there are hundreds of Tessy related files changed will make it impossible.
Does anyone know if there is a setting to have these stored in a less problematic format or any suggestions for a viable solution? What would be ideal is if it could store everything as, for example, an xml file - this would make browsing directory diffs easier and would allow the actual content to be human readable as well.
Any ideas?
I know this is an old question ...
Does anyone know if there is a setting to have these stored in a less problematic format or any suggestions for a viable solution?
The TESSY recommended way is to do utilize the database save feature found under in File menu (and in a variety of right-click menu's). This creates a binary .tmb file which contains everything related to your tests. By default the .tmb file is stored in the backup directory in your Tessy Project folder. The config folder, backup folder and the PDBX file would then all be stored in SVN. See the Tessy Users Manual (Backup, restore, version control chapter) for more specifics.
What would be ideal is if it could store everything as, for example, an xml file - this would make browsing directory diffs easier and would allow the actual content to be human readable as well.
That would be ideal, but unfortunately is not really an option. Having everything stored as a binary file makes it impossible to do a useful diff. The other problem with this method is that it disconnects a change to the test from the file that is checked into SVN - unless the tester specifically performs a database save.
Yes I realize xUnit testing frameworks don't have those limitations, but Tessy has some features (like MCDC and DO178B support) that the xUnit frameworks do not have baked in.
So how do you work in this environment. Key word - Discipline.
We set up internal procedures for who and how tests gets updated. When the proecedures are followed we are able to deal with the limitations presented above. It is not optimal, but with some internal discipline it can work.
In our Silverlight business application, we need to cache very large files (100's MBs) into isolated storage. We distribute the files separately to be downloaded by users and then they can import those files into Isolated Storage through the application.
However, the Isolated Storage API seem to be very slow and it takes an hour to import about 500MB of data.
Given, that we're in a corporate environment where users trust us, I would like users to be able to copy the files directly into the physical location on their file system where Silverlight store files when using the API.
The location varies per OS, but that's ok. The problem however, is that Silverlight seems to store files in a somewhat cryptic way. If I go to my AppData\LocalLow\Microsoft\Silverlight\is, I can see some weirdly named folder that look like long Guid.
My question: is it possible to copy files directly in there, or is it going to upset Silverlight ?
From what I've been testing it will make stuff fail/act weird. We had some stuff we had to clear and even though we did delete the files to test how it worked the usedspace didn't drop. So there is some sort of register of which files are in IS and how big they are.
I think it would be paramount you find out why IS is so slow. Can you confirm its like that on all clients? Test some others. This should be brought up to Microsoft if it is the case. Possibly you can change your serailization schema and save smaller files? I would not advise trying to figure out Microsoft's temporary and volatile IS storage location.
We have a table in our our database that stores XSL's and XSD's that are applied to XML documents created in our application. This table is versioned in the sense that each time a change is made, a new row is created.
I'm trying to propose that we store the XSL's and XSD's as files in our Source control system instead of relying on the database to track the history. Each time a file is updated, we would deploy the new version to the database.
I don't seem to be getting much agreement on the issue. can anyone help me out with pros and cons of this approach? Perhaps I'm missing something.
XSL and XSD files are part of the application and so ought to be kept under source control. That's just obvious. Even if somebody wanted to catgorise them as data they would be reference data and so - in my book at least - would need to be kept under source control. This is because reference data is part of the application and so part of its configuration. For instance, applications which use the database to store values for drop downs or to implement business rules need to be certain that it holds the right version of the data.
The only argument for keeping multiple versions of the files in the dtabase would be if you might need to process older versions of the XML files. This depends on the nature of your application. Certainly I have worked on systems where XML files / messages came from external (third party) systems, where we really had no control over the format of the messages sent. So for a variety of reasons we needed to be able to handle incoming XML regardless of whether its structure was current or historical. But is is in addition to storing the files in a source control repository, not instead of.