I got many properties for vCard # https://en.wikipedia.org/wiki/VCard
e.g.
BEGIN:VCARD
VERSION:3.0
PRODID:-//Apple Inc.//iOS 6.0.1//EN
N:;Test;;;
FN:Test
TEL;type=CELL;type=VOICE;type=pref:+1XXXXXXXXXX
TEL;type=WORK;type=VOICE:+1XXXXXXXXXXX
REV:2012-12-17T21:01:31Z
END:VCARD
BEGIN:VCARD
Here I would like to know is there any operating system specific properties are there or not. Means in above example we have PRODID property. How I'll get know that this property is supported by all operating system. Is there any clue to know few of properties not supported by Android, IOS or MS Outlook.
You won't find any up to date table listing all versions of all OS (and all clients on each OS), along with the properties supported by each.
If you look at https://www.rfc-editor.org/rfc/rfc2426#section-4 , only the VERSION, FN and N property are mandatory.
PRODID is very likely to be present as well.
vCard 4 (https://www.rfc-editor.org/rfc/rfc6350) has a cardinality for each property but most clients still use vCard 3 and in any case, that will not really address your OS related question either.
Related
There's a program called PPStream which is currently only available in Chinese, it allows for access to a myriad of ad-supported movies and TV series. The problems is that it is in Chinese and menus are indecipherable.
Is it possible to hook into the part of Mac OS's API that puts text on the screen so that it routes it through a wordlist first, translating the text into English? Would the API hook be able to differentiate the different applications calling the API?
I have no experience at all with Mac APIs, just pondering on if this is worth pursuing or not.
Thanks.
Edit: The reason I would like to do this at API level is that I need to dynamically dispatch HTTP queries with a list of strings to be translated (movie titles Chinese -> English), and the edit-the-i18n-file approach wouldn't do. Any other suggestions?
I haven't downloaded, installed or run PPStream myself so I'm speaking "out of my rear end" in a sense, but there are a number of ways to localize an app. But you really need to have access to the raw, uncompiled code and project to do it correctly.
The three most likely ways the string resources are saved are these:
1)
The app may have a strings file from which it fetches the strings to be displayed in the interface.
You may be able to make a copy of this strings file and set it to English or whatever language you choose.
2)
The strings may be baked into the code itself. This is generally a NO NO for commercial grade MacOS & iOS apps, but lazy and/or inexperienced developers can do this especially if they don't think their app will ever be used in other languages.
3)
The most likely set up is that there will be a folder hidden in the application package, inside the "Resources" folder, that has named like "en.lproj" or "English.lproj" or "de.lproj" or "zh_CN.lproj" or "zh_TW.lproj" (these last two are especially likely if this is only in Chinese).
Inside those folders will be localized XIB (or older NIB) files. And if you make a copy of this folder and then modify the newly made copy to add your new language.
Options 1 & 3 are ones you might be able to copy and then modify, but then again it might not work (especially these days when there's code & app signing). I've never tried this without an accompanying project, so if you have success, you should comment your question and/or this answer and let us know.
I need to rewrite a QuickTime reference movie, making it point to another set of files.
I'm working in Windows environment, so I don't have acces to the QuickTime API, and being the referenced files unaccesible, I can't also use the COM interface to load the movie because it can't resolve the referenced paths.
The documentation in the "QuickTime File Format Specification" says that the 'dref' atom can have a list of 'alis', 'url ' and 'rsrc' data references. In this case I need to parse the 'alis' elements. According to the reference, "Data reference is a Macintosh alias".
So long, I have not been able to see a declaration of the structure or any related information. Do you know the structure of an alias record? Where can I find detailed information about it's structure?
Thank you a lot for your help!
The format is very similar to the sort of alias that you could generate in the Finder by right-clicking an item, and creating an alias to it.
Aside: When the QuickTime format was originally specified, Apple intelligently chose to incorporate a number of other standards and paradigms that were extensively already being used elsewhere in the OS. This is one of the reasons why QT is (or was) able to do really clever things like reference movies. Unfortunately, there's also now a lot of cruft leftover from OS features that are no longer relevant (ie. AppleShare). Back in its heyday, QuickTime was slick, especially compared to its competitors; today, it's vastly underappreciated due to the buggy Windows port, and the relatively low processing power of the desktop systems of its time.
Back ontopic, unfortunately, the format for alias files is not an open/published standard, and there is precious little documentation on the topic on the 'net. There's one really old doc that deconstructs the alias format used in Mac OS Classic. Although the structure used in OS X is very similar, the alias files themselves tend to be much larger, as they contain numerous extra data strings at the end of the file that are not documented in the above-linked documentation.
Also, aliases created in the finder do look a bit different from the ones contained within the dref atom, although I've never run through them bit-by-bit to deduce the actual differences. If you want to take a peek at what those files, and have the OS X Developer Tools installed, you can run
setfile -a a [filename]
on a Finder-generated alias to strip the file of its alias-ness so that you can look at its contents in a hex editor (otherwise, the OS will just redirect you to the linked file - doh!). You can re-set the file's alias attribute, or arbitrarily designate any file as an alias by running
setfile -a A [filename]
Unfortunately, during my experiments, dumping the alis portion of a QT movie's dref atom has never seemed to generate an alias that Mac OS was able to interpret.
Fortunately (or not, as it was in my case), the functions that Mac OS allegedly uses to create/handle aliases are part of a public API called the Alias Manager, which is part of the very-low-level CoreServices framework. If you've got time to delve into this further, you can write some code to experiment with Mac OS's built-in alias-generating and interpreting capabilities.
Unfortunately, if you're dealing with an old/buggy file, you have no way of knowing if the file was actually generated by CoreServices' Alias Manager, or if that framework has changed/evolved/regressed since then. Because it's a closed format, 3rd-party developers who opt to not use the Alias Manager can only take guesses as to the format's "legal" structure.
You can use this Java program to see what is in the header, and extract data (it's a bit old, but may still work). What is more useful, though, is the thorough discussion by the author about the Quicktime header.
But I think you may just be looking for the Apple documentation, currently found here.
I'd like to store some additional information along with a document, but I can't use bundles or packages, and I cannot store it inside the document itself.
The application is a text editor, and I'd like it to store code folding and bookmark locations with the document, but obviously this cannot be embedded into the code directly, and I don't want to alter the code with ugly comments.
Can I use NSDocument to store information in the resource fork of a document? If so, how can I do this? Should I directly write to <filename>/..namedfork/rsrc or is there an API available?
First, don't use the resource fork. It's virtually deprecated. Instead, use extended attributes. They can be set programmatically at the BSD level via setxattr and getxattr. Extended attributes are used in many places... for example, in the latest OS X, the resource fork itself is implemented as a special type of extended attributes.
For example, the Cocoa text system automatically adds an extended attribute to a file to specify the encoding.
I thought NSFileManager and NSFileWrapper supported extended attributes since Snow Leopard, but I can't find any documentation :p You can always use the BSD level functions, though.
Does the state need to move with the file if it's copied to another computer? If not, you could do a lot worse than emulating the way Bare Bones handles document state with BBEdit. They store state for all documents in ~/Library/Preferences/com.barebones.bbedit.PreferenceData/Document State.plist.
The resource fork documentation is here. But it contains plenty of suggestions to not use the resource fork.
I have a class on my web site for reading and writing resource forks, which I have never got around to moving to my GitHub repository because, as Yuji points out, they are not really used any more.
I was going to say alias files and web Internet location file are the only places they are used, but I used and tested it on Mac OS X v10.7 (Lion), and they are not even used there any more; they may still be used for custom icons. I didn't test for that exclusively. I will have to see how that affect my NDAlias class on 10.7.
ndresourcefork
Any help? Now can get NSSize, duration and its all.
You can do this almost entirely using Spotlight's metadata.
For example, I do the following in one of my apps
MDItemRef fileMetadata=MDItemCreate(NULL,(CFStringRef)eachPath);
NSDictionary *metadataDictionary = (NSDictionary*)MDItemCopyAttributes (fileMetadata,
(CFArrayRef)[NSArray arrayWithObjects:(id)kMDItemPixelHeight,(id)kMDItemPixelWidth,nil]);
This code essentially asks for the pixel width and height for a movie file (to determine if it's the dimension of an HD movie or not is the reason).
The Spotlight Metadata Attributes Reference lists all the available keys for various file types by category. You can probably get the required data this way without doing anything significant, provided that the media type you're examining has a Spotlight plug-in.
This functionality may not be built in (I'm honestly not sure), but I do know of two third-party libraries which can tell you the information you need.
VLCKit, the framework being used by the newest beta versions of VLC for Mac.
libmediainfo, a multi-purpose library that can read practically any bit of information you need out of practically any media file.
I can go into more depth with how to use either of these, but I'd rather only do so if you end up needing me to. Let me know!
I want to retrieve the system language of a Macintosh in ISO-639-2 format (that is, in three character format).
Currently, I'm trying to use [NSUserdefault objectforkey:#"Applelanguages"]. This returns the Language code in 2 character format.
Whatever API I end up using, it should support MacOS X versions from 10.3.9 forward.
The relevant sections of the document are Internationalization Guide, another section of the same guide, and CFLocale reference. Unfortunately I don't think there's a standard API provided which convert 639-1 to 639-2. As explained there, OS X uses a mixture of both, and the canonical form used by the OS can be obtained by CFLocaleCreateCanonicalLanguageIdentifierFromString. But this is not what you want, unfortunately.
I would suggest you to process the table given here into an NSDictionary yourself.
For people needing this and don't want to process the table themselves, I created a category on NSLocale which should probably work on OS X also.