I'm currently using *.plist files for my iPhone app to store information that is later read into strings as NSArray or NSDictionary equivalents. I will be updating these files periodically and downloading them to the application if a new version is found. I would like to use the <plist version="1.0"> string located in each *.plist file to make these comparisons since it won't interfere with the actual content of the plist file.
My question: is it possible to access this information and use it in the manner I describe, or is this version information describing the version of the *.plist protocol and not the actual file itself? For example, can I change this to: <plist version="1.1"> for a new version of the file, read this version info and update the file if newer? If this is possible, I haven't found a way to extract this information using the iPhone SDK (the comparison and update part will be easy).
I'm pretty sure you should'nt touch that. It's probably used by apple for future-compability (or future backwards compability, if you prefer). So that if/when they change the syntax of plists, old ones will still work.
Easiest would be to have the first entry contain the version number, or possible as a part of the file name. Or maybe even at a completetley different place, like in a database or as a part of a file structure on the server.
Related
I'm using Titanium.App.Properties to store user highly confidential data. So is it safe to store values here. Is it possible jailbreak iPhone's to leak this values. Is this values encrypted or stored as plain text?
Thanks in Advance.
Here is an update to this old question:
From Titanium 3.X docs:
As of Release 3.2.0, any application properties defined in the tiapp.xml file are stored in the device's secure storage, making them read-only. Additionally, external access to these properties is now restricted. Other iOS applications cannot access these properties and native Android modules must use the Titanium module API TiApplication.getAppProperties method to access these properties.
If you need to change the values during runtime, initially create the property with these APIs rather than defining them in the tiapp.xml file.
Prior to Release 3.2.0, application properties defined in the tiapp.xml file could be overwritten by these APIs and accessed externally by other applications and modules.
So, the answer to the question is:
If using SDK version 3.2.0 and above; Titanium.App.Properties is secure enough to store sensitive app-related data:
For storing constant values (cannot be changed at run-time); use tiapp.xml file.
e.g. <property name="app.google.api.key" type="string">key_here</property>
To get and set values dynamically at run-time, use Titanium.App.Properties.
You can also use this module for securely storing and reading app or user related data.
See this example code that defines security levels of each
operation.
Titanium.App.Properties are stored in a simple .plist file. It is in a compressed (encoded) XML file. So not encrypted, but also not technically in plain text (although any .plist reader, including the Mac itself, can present it in plain text.
Source: http://developer.appcelerator.com/question/130050/titaniumappproperties-is-it-safe
i make a localized iphone application and in run time i want to modify the property list, so i at the first run of the application i copied the plist file but i don't sure if the copy operation also copied the localized version which the system store in a folder like: lp.fr
my quetion is: what i must do for the system to recognise the two files? should i make two directory in documents folder like lp.en and lp.fr and copy the two files?
also also xcode make the two plist with the same name, how i can determine every version and copy it?
i am waiting for some one to direct me to write way.
thanks
Take a look at NSBundle's pathForResource:ofType. It clearly states that it will return a non localized file if it exists or else pick a file in the order of user's language preferences. As you wan't to copy a localized resource, don't create a non localized copy and this will return the path for the most suitable resource. You can just copy that file and make changes to it.
If you are interested in getting the path to a resource of a specific language, take a look at pathForResource:ofType:inDirectory:forLocalization.
Can someone help me find where CoreData is storing the SQL file it creates in iOS applications?
So far I've tried "Show package contents" on the .xcdatamodel file and also the .xcodeproj file...No dice!
Is there an editor for looking at the contents of these SQL files?
Cheers.
-A
The url parameter of [NSPersistentStoreCoordinator addPersistentStoreWithType:configuration:url:options:error] specifies the location of the file. Find this call in your code and see where you've stored it. XCode templates will put it into the top of your application documents directory, but you can put it anywhere you like.
Note that Apple considers the contents of this database to be opaque and non-user-modifiable. Playing with the data in your store is likely to cause issues with Core Data.
It's typically saved into your application's documents directory, with the name of your data model.
So, for example, if my data model is called AppData.xcdatamodeld, it will be AppData.sqlite inside my app's document directory. You shouldn't really need to touch the .sqlite file though.
Hope that helps!
Core Data editor --> http://christian-kienle.de/CoreDataEditor/
I would like to create my own data format for an iPhone app. The files should be similar structured as e.g. Apple's iWork files (.pages). That means, I have a folder with some files in it:
The file 'Juicy.fruit' contains:
Fruits
---> Apple.xml
---> Banana.xml
---> Pear.xml
---> PreviewPicture.png
This folder "Fruits" should be packed in a handy file 'Juicy.fruit'. Compression isn't necessary. How could I achieve this? I've discovered some open source ZIP-libraries. However, I would like to to build my own data format with the iPhones built-in libs (if possible).
Best regards,
Stefan
Okay, so there are three ways I am reading your question, here's my best guess on each one:
You want your .fruit files to be associated with your app via Safari/SMS/some network connection (aka when someone wants to download files made for your app or made by your app).
In this case, you can register a protocol for your app, as discussed here:
iPhone file extension app association
You want the iPhone to globally associate .fruit files with your app, in which case you want to look into Uniform Type Identifiers. Basically, you set up this association in your installer's info.plst file.
You want to know how you can go from having a folder with files in it to that folder being a single file (package) with your .fruit extension.
If that's the case, there are many options out there and I don't see a purpose in rolling your own. Both Microsoft and Adobe simply use a standard zip compression method and use their own extension (instead of .zip). If you drop any office 2007 document, such as docx or Adobe's experimental .pdfxml file into an archive utility (I like 7z, but any descent one will do), you will get a folder with several xml files, just like you're describing for your situation. (This is also how Java's jar file type works, fyi). So unless you have a great reason to avoid standard compression methods (I vote gzip), I would follow the industry lead on this one.
I can definitly appreciate the urge to go DIY at every level possible, but you're basically asking (if it's #3) how you can create your own packaging algorithm, and after reading how some of the most basic compression methods work, I would leave that one alone. Plus I really doubt that Apple has built in libraries for doing something that most people will just use standard methods for.
One last note:
If you are really gunning to do it from scratch (still suggest not), since your files are all XML, you could just create a new XML file that will act as a wrapper of sorts, and have each file go into that wrapper file. But this would be really redundant when it came time to unwrap, as it would have to load the whole file every time. But it would be something like:
Juicy.fruit --
<fruit-wrapper>
<fruit>
<apple>
... content from apple.xml
</apple>
</fruit>
<fruit>
<banana>
... content from banana.xml
</banana>
</fruit>
<fruit>
<pear>
... content from pear.xml
</pear>
</fruit>
<picture>
...URL-encoded binary of preview picture
</picture>
</fruit-wrapper>
But with this idea, you either have to choose to unpack it, and thus risk losing track of the files, overwriting some but not all, etc etc, or you always treat it like one big file, in which case, unlike with archives, you have to load all of the data each time to pull anything out, instead of just pulling the file you want from the archive.
But it could work, if you're determined.
Also, if you are interested, there is a transfer protocol intended specifically for XML over mobile called WBXML (Wap Binary XML). Not sure if it is still taken seriously, but if there is an iPhone library for it, you should research it.
In my Iphone application i have .plist file in which i am putting all the Input data. I will further use this data in the code: directly from .plist file.
The problem is that when i am going to open the .plist file in a windows machine, it is not showing its original content. It is just showing the Binary characters or junk characters.
Can any body help me out for how to open the .plist file in the Windows machine, so i can do my data entry in the .plist file in a windows machine also.
Any solution would be appreciated.
More likely than not, the plist is stored in a binary format for speed and size purposes (XML is bloated and slow to parse).
You'll need to explicitly save your data in a readable format manually or use NSPropertyListSerialization to serialize the property list into XML.
http://developer.apple.com/iphone/library/documentation/cocoa/Reference/Foundation/Classes/NSPropertyListSerialization_Class/Reference/Reference.html#//apple_ref/occ/clm/NSPropertyListSerialization/dataFromPropertyList:format:errorDescription:
Probably it's to late.
You can use xml editor,but not all of them can work with *.plist files. I use http://www.donkeydevelopment.com
PS
Apple use this document type definition:
< DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">