In our app we have lots of photos that we need to read while using the app, we have to also orgenize them into groups/categories.
this option is to make a plist with their names, and just put them into the app and read the plist.
create folders inside the app, order them inside, and read the specific folder.
Option 2 took me days and I couldn't even make it work reliably, and it also seems not the right way to work for some reason.
Option 1, the problem is that if you have 100 files you have to edit your plist every time again for a new file you add.
Is there a way to make option 1 outside of xcode so I can put all files in a folder on my mac, get their plist, and put this plist inside Xcode ?
What's the right way to achieve this ?
plist is just a simple XML file. You can create the plist file and add to xcode as any normal file to the bundle and read it.
macOS comes with two command-line tools for manipulating plists:
/usr/bin/plutil can convert a plist between formats. You might like this because you could write your photo catalog in JSON using whatever tools you like, then convert it to a plist. Of course, then you could just use JSON directly in your app…
/usr/libexec/PlistBuddy (note that /usr/libexec is not normally in one's PATH) can modify a plist in place, adding, removing, or changing entries.
Both of these tools have man pages (man plutil, man PlistBuddy) and substantial built-in help (plutil -h, /usr/libexec/PlistBuddy -h).
First, you're making a false assumption. There is no need to use a plist file here. An ordinary text file listing the names will do just fine, and you can just make up your own format to dictate groups and suchlike. And that sort of file is trivially easy to maintain.
Second, your rather confused claim that "Option 2 took me days and I couldn't even make it work reliably, and it also seems not the right way to work for some reason" is just a cop-out. Folder references are not a difficult thing to use (you can configure them in the Finder, which is as simple as you can get), they do work just fine, and they are a perfectly reasonable solution here.
Related
I have created a plist file in the bundle, and I'm trying update the user's information into the plist. I know that I should copy the plist file from the bundle to the document directory, and edit it from there, but I still have a couple questions:
When I copy the plist file to the document directory, is it permanent? I mean, if I close the program and open it again, I can simply edit the plist file in the document directory, right?
If so, does it mean that I should only execute the code that copies the plist file to the document directory once the app is launched for the first time?
/main question/ Since I want a blank plist file for the user to update their data with, should I just simply create a plist file on the first launch? It'll be a lot easier without the copying around bundles and stuff.
I mean, what is the point of creating a plist file in the bundle in the first place? We will copying it into the document directory anyway, so why not just create one in code?
Yes. Writing a file is permanent, as long as you obviously don't delete/move the file somewhere else.
That is a valid option
Yes. If you need a blank file, you don't need it from the bundle. A better idea would be to create it when you need it (when there is something to write). Usually file creations are managed like so
Check if file exists
If not, create it.
Use the file.
If you need a template file (with already some stuff written in it), then a copy from the bundle is more appropriate. But even then, a lot of developers will like to do everything from code, it's not that heavy of a task, and it forces you to create/prepare the right objects and methods from the get-go.
Like Rooe N said, the NSUserDefaults IS a property list, so if you're talking about very simple data, say, like a username and a last-time-I-logged-In-date, you could store it there.
Note that NSUserDefaults are loaded all the way, every time you load the app, so you don't wanna use it as a database. But since you're going for .plist, I'll assume you've already ruled DBs out.
I'm not completely sure what you are trying to achieve, but you should think of plist as a place for global Constants not something that should be updated on runtime.
Maybe you should look at this:
NSUserDefaults
OK, so here's what I need :
I have a (rather big) binary .plist associated with my app, containing info that I wouldn't really like it if a user would access it and view the contents (as would normally happen with a regular un-encrypted plist file, binary-or-not).
I want to encrypt the .plist (using a pass)
Include the encrypted .plist in my app bundle
Decrypt the .plist at app launch
How would you go about it? Is there any built-in way to make it easier for me to achieve that?
P.S. I don't think it'll make much of a difference, but I'm interested in a working OSX solution, not an iOS one
I need to be able to configure my app via configuration file.
How do I go about it?
The first thing that comes to my mind is having a .plist file that stores values and to have an singleton class and ask that class for values whenever I create element in question in code.
Or is there any better way to do this?
Depends on the amount of content and size of the configuration file.
If it's a couple of key-value values, I would just go with NSUserDefaults.
If it's a bit more, arrays or more advanced data models, I would go with a .plist. But remember to move the default .plist into the /Documents folder, you are not allowed to edit files in the app bundle.
I'm attempting to make the values in a .plist Multi Value dynamic. Specifically, I want to download a list of options from a web site and populate the values with the returned data. I have read a couple of posts stating that changing the app bundle during runtime is impossible. Is it not possible to make the values refer to a data source outside the app bundle, for example if I put the alternatives in NSUserDefaults and read from there?
If this is totally out of the question, what alternatives are there?
What I do is copy the plist into a hidden folder in the documents directory and work with that copy
If the file does not exist, copy it entirely, and if it does, do some merging or overwrite completely, whatever fits your needs
Working with NSUserDefaults is also a possibility
I understand the basic of Document Interaction Programming and UIDocumentInteractionController and I've got it working in my app. However I'm having trouble with specific details of using custom file types. I can't find this addressed in the Apple docs anywhere.
My app uses it's own file types with unique extensions. The files themselves are just plists (xml), but I want the device to treat the files as only openable in my app. Originally I implemented the Document Interaction stuff to treat them as XML while I got it working, but now I want it to treat them as binary files that it needs to hand off to my app.
At the moment, if you have one of my files in an email attachment, iOS first shows the QuickLook (which just spews all the text content of the xml out) before you can choose to Open In. Similarly if one of my files is opened with Safari, Safari just shows the XML and doesn't give you the option to show it in my app at all.
So how do I get iOS to not treat my files as XML? I've changed the "Conforms to UTI" value and "public.mime-type" value in the info.plist, but it seems to have no effect.
Any tips greatly appreciated.
As far as i understand the UIT concept of Apple you cannot just change the file extension to change a potential UIT of the file. If the file contains XML-Data, other apps as well as internal apps might recognize your content and show it internally as XML.
Try to store your Plists with NSPropertyListSerialization NSPropertyListBinaryFormat_v1_0 (then you readble XML)
When you did that without success, why not trying this:
use zlib to compress the XML plists afterwards to a zipped file.
make a "unique" file extensions (<file>.myappname)
this should "hide" other apps and quick view.
Tell me if one of the ways did work for you.