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.
Related
I use the extension News System to manage my newsitems and I need to add mp3 file to my records using [fal_media]. But in the list of allowed file extensions I don't have MP3.
And even if I downloaded an audio file (mp3), it disappears when I save the content.
I checked the [SYS][mediafile_ext] on the Install tool and I see that the MP3 extension is already there.
Why I can't see MP3 on the Allowed file extensions?
As you have checked the system configuration which enables mp3 files, something has restricted the use of mp3 afterwards (as Robert mentioned)
In general EXT:news (7.3.1) does not modify the available fileextensions (3rd and 4th paramter of getFileFieldTCAConfig() calls in Configuration/TCA/tx_news_domain_model_news.php for the fal_mediafield is empty) something else has modified the list.
You may check if mp3 is removed everywhere, checking the TCA for all tables (there should be some mentions for tt_content)
Then you might check the site extension or page_TSconfig for the origin of the removal.
I'd like to create a custom file type, say, .cstm, and be able to create .cstm files on the mac, and read them on the iPhone.
I want the .cstm file to contain XML data. Currently I've got the mac app to successfully make .xml files and the iPhone app to successfully read .xml files, but I'd like to create a proprietary custom file type.
How would I go about doing this? I know how to allow the iPhone app to open a custom file type, but that's as far as I know.
Thanks!
You don't need anything special per se. You can just save and load to the URL with the ctsm extension. To support your app automatically launching as an editor of that extension in OSX, you will want to add an entry to your Info.plist file CFBundleDocumentTypes array entry declaring your app as an editor of that extension
https://developer.apple.com/library/mac/#documentation/General/Reference/InfoPlistKeyReference/Articles/CoreFoundationKeys.html#//apple_ref/doc/uid/TP40009249-101685-TPXREF107
I am writing an application that needs to recognize my custom mime type so that when such file is downloaded from a server my application will be launched. I read the great article of Brad on how to write a mime type recognizer under iOS at How do I associate file types with an iPhone application? and it works well if and only if the extensions of the file is also specified in the UTExportedTypeDeclarations / UTTypeTagSpecification section of my plist and the server serves the files with the same extension. If the server serves the file with a different extension or if no extensions are specified in the plist but the mime-type is matching, the following happens:
The browser (or the application that received the file) shows the correct icon of my file type with the correct [Open in myApplication] button but clicking on the button does nothing, my application is not launched and if it is running, no application:openURL:sourceApplication:annotation: message is sent.
Is there any way to write a file type recognizer based only on the mime-type, without a specific file extension?
this has been answered, you'd want to use NSURLRequest, this will allow you to get to the mimeType which you can use to determine the file extension as needed. the full code and additional hints and tips are available at this post:
https://stackoverflow.com/a/1401918/728261
I am new to iPhone App development (I am using XCode 4.2) and I was wondering if there is a way to translate all the strings , caption etc ... internally without having to translate them one by one .
an idea I have in mind is to use NSUserDefaults to save the language as a global variable and translate everything accordingly
another option is to make a look up table (is it even possible in Objective-C ?)
Thanks
You can use NSLocalizedString(#"<#key#>", #"<#comment#>") and one file (named Localizable.strings( per language. If you use the above function you can use the App Linguan (available on the Mac App Store) to generate the Localizable.strings files.
There is also a command line tool called genstrings that will create the file for you, but believe me that Linguan app will pay for itself in minutes.
You should always add a comment to allow a better translation and to provide context about the key.
You can read a step-by-step tutorial of the process here:
iPhone Localization Tutorial
Here's a high-level overview of the basics (the above tutorial has details):
1) Change all your coded strings to call: NSLocalizedString(#"My text", #"Context for the translator")
2) Export all your strings using the genstrings Terminal command.
3) This creates a text file called Localizable.strings with all your English (source) strings. It looks like this:
/* Context for the translator */
"My text" = "My text";
You send that file to the translators. They'll translate the right side like this: "My text" = "Mi texto";
4) You place each translated Localizable.strings file in its proper language folder: en.lproj, fr.lproj, es.lproj, etc.
When your app loads on the iPhone it will check the user's language settings. If the user has chosen French as the system language, the Localizable.strings inside your fr.lproj folder file will load. If there are any untranslated strings, it just defaults to English (or whatever your source language is) for those.
It's worth following the whole tutorial and note that the file/folder names have to be exact!
Look up the documentation for NSLocalizedString. And how to localize your .xib files (you make localized copies in English.lproj, de.lproj, fr.lproj, etc.).
All you will have to create are the files with the key-value pairs for each language you want to translate and name them accordingly i.e. _en, _fr and so on.
Then all you have to do is send a message to this method:
NSLocalizedString(#"myKey", nil)
And this will return the localized String, in whatever language the current iPhone configuration is.
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.