The app I'm developing has a custom file format for its files, and I'd like to be able to use the "Open In ..." feature of iOS which lets users e.g. email each other a file and then open it directly in the app.
I've gotten as far as adding the CFBundleDocumentType stuff in the Info.plist file, but the problem is the LSItemContentTypes. From what I've read, I need to provide the actual file
as a UTI, rather than just saying ".myfileextension", and I can't find a lot about how to create UTI's in a iOS app.
Anyone know?
You will want to read up on the following topics from Apple:
Adopting Uniform Type Identifiers
Introduction to Uniform Type Identifiers Overview
Declaring New Uniform Type Identifiers
From the documentation:
If your application uses proprietary data formats, you should declare them in the Info.plist file of your application bundle. Some guidelines:
Your UTI string must be unique. Following the reverse-DNS format beginning with com.companyName is a simple way to ensure uniqueness. While the system can support different UTI strings with the same specification, the reverse is not true.
If your code relies on third-party UTI types that may not be present
on the system, you should declare
those UTIs as imported types in
your bundle.
Be sure to add conformance information if your proprietary type is a subtype of one or more existing types. In most cases you should not specify conformance to a nonpublic type, unless you are also declaring that type in your bundle. For a list of public and Apple-defined UTIs, see "System-Declared Uniform Type Identifiers"
Related
I'm using a document picker to import data into an app. One of the files to import is a .GPX (it's actually an XML file of GPS data, but that's not relevant). I define a custom file type (as it's not covered by the standard file types covered within UniformTypeIdentifiers)
let documentsPicker = UIDocumentPickerViewController(documentTypes: ["com.sourceapp.gpx"], in: .open)
and register it in info.plist as a Document type, and include this in Exported type identifiers and, seeing as it is not a bespoke file type, in Imported type identifiers. These are all still required as the app target is pre-iOS 14 (for 14+ it's not necessary to add the items to info.plist).
This works fine in the simulator where it's a clean environment without any other apps installed. On a device however it doesn't work, and the file is greyed out and not selectable. I'm reasonably certain this is because a custom file type with the same extension is already registered by another app.
So how do I go about using a file type that has already been registered? There must be a "correct" way to go about this as it must be a common scenario.
My understanding was that this is what the Imported type identifiers was for, but I can't seem to get this to work. This may be because I'm not defining the imported type in exactly the same way as the first app to register it.
If so, how do I see what has already been registered, and reuse it? This would need to be a generic apprach as a scenario where a different app has already regsitered the file type but in a different way is highly likely for a common file type such as .gpx
As background, when using a pre-defined file type such as "public.comma-separated-values-text" for a CSV file all works fine.
UPDATE:
I've since seen as the bottom line of documentation that the exported type identifiers overrides imported type identifiers, so have tried deleting the exported one, butit makes no difference.
My application writes files known as ".nec", which are simply text files. I'd like them to open in my app if it's on the machine, or open in the default text editor if it's not.
There are surprisingly few examples of how to set these things in Apple's documentation. Do I simply set the MIME type to text/plain, or are there other things I should do as well?
Most computers / mobile devices will use the file extension to determine the file type rather than read the file headers so if you are using a custom file extension then the device won't know which application handles that file.
If you want your applications documents to opened by something outside of your application you will need to use a standard format for your file type.
For textual documents the most common are likely to be .txt, .rtf and .doc
If your documents are just plain text without any formatting (like a log file) then you would be best using .txt, you shouldn't need to change much (if anything) to write in this format.
After a quick google of the file extension .nec I found this:
NEC files are Uncommon Files primarily associated with Unknown Apple II File (found on Golden Orchard Apple II CD Rom).
NEC files are also associated with NEC JIS Encoded File, PIMS Notes for Windows CE Audio Record File (Nacetech Co. Ltd.) and FileViewPro.
If one of your files were to be (for example) emailed to a windows user, Windows would not know that this is a simple text file and would likely prompt the user to search online for a program that handles this file extension.
Not an answer as such, but as to date you don't have one here are some things to explore in the hope it is useful.
The old style type and creator of Mac OS have just about gone, first to replaced by just file extensions, and now there are UTIs.
If you read Apple's Uniform Type Identifier Concepts you will see your app can declare a UTI, say com.markowitz.nectext, which conforms to the standard UTI public.text. Now a UTI helps the Finder (Launch Services) locate the app to open a file, you could explore what happens if there is no such app available but the UTI declares it conforms to public.text.
[Just seen your comment on another answer re: right-clicking. At a guess this would be the UTI above.]
Another avenue to explore, getting into the undocumented side of OS X, is how the Finder's "Get Info" handles setting the "Open With" preference on a file. Try setting a plain text file to open in your app, then use the xattr -l <file> in the Terminal to see what was done. You should see an extended attribute com.apple.LaunchServices.OpenWith whose value looks like some form of plist.
Just remember this is undocumented, the API used by the Finder is private, but then its just an extended attribute...
Have fun.
If your app supports drag and drop and receives a drop with mime type subtype uri-list, is it possible to look for image-like suffixes in the uri's (e.g. .jpg) and then download the images? For example if your app is a drawing program?
Outline of solution in Qt:
Get a QMimeData in an event handled by dropEvent() handler.
Get a uri-list from the mimeData if it hasFormat('uri-list').
Iterate over the strings of the uri-list until you find one that satisfies:
Create a QUrl from the string.
Use QMimeDatabase.mimetypeForUrl(string) to get a QMimeType.
Is the mime type one that your app supports?
Use QNetworkAccessManager to download the url (in the background, with signals for completion.) Meanwhile, your app might display a placeholder or a busy cursor. It doesn't matter if the url is to a local file, the mechanism will still 'download' the url (just more quickly.)
Your app prioritizes mimetypes in a mimedata, and only looks at the uri-list mime type (a reference, or indirection) if a mime type format is not directly (embedded) in the mime data.
The whole process of drag and drop is highly dependent on platform and the pair of sending and receiving apps. One sending app may choose to embed a mime type while another may choose to send a url in a uri-list (url pointing to data whose content has the mime type, and url whose suffix indicates a mime type.) On a platform, most receiving apps may prefer a certain mime type (e.g. image/jpeg) and not accept similar mime types (e.g. image/png.)
Is it possible to define my own naming convention for iOS app splash/launch images as I can with Icon files (e.g. via an Info.plist entry), or must I stick to the ...#2x.png and ...-568h#2x.png naming?
You can change the root name (the “Default” bit) with the UILaunchImageFile key, which has been available since iOS 3.2, but in that case the suffixes—#2x, -568h#2x, etc.—are still fixed. To supply a set of arbitrary images, you can use the UILaunchImages array, but be advised that that API is iOS 7-only.
If you use an Asset Catalog (new in XCode5), you can use whatever file naming convention you like. The Asset Catalog takes care of mapping a logical name for an image resource to a set of files on disk.
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