So, this seems like it should be super easy, but i'm stumped...
I have an iOS application that I am developing where I am downloading video content from a server, storing it in a custom folder in the Documents, and upon a certain trigger, trying to play the video. I am experiencing some loading errors in my MovieViewController, so am trying to debug the NSURL that is constructed from the file path in a separate standalone application. It is worth noting that the same content works fine when added to the Bundle, but there's quite a lot, so can't afford to do that.
Anyways...
I have set breakpoints in my app and copied out the path of the NSURL that gets loaded into my movie player, and am attempting to hardcode it into an NSURL in my test app. But I can't seem to just assign it with a preexisting value... Eg.
NSURL *url = "file:///var/mobile/Containers/Data/Application/21078F3B-12C5-4D42-8B8B-3C85CB7A0A91/Documents/SecondStory/BloodAlley/MEDIA/copperthief.mp4"
(which is what I copied out of the Variables View of the Debug area).
It gives me the error:
*"Implicit conversion of a non-Objective-C pointer type 'char *' to 'NSURL ' is disallowed with ARC"
... which I cannot seem to track down on SO ....
Of course, I have the NSString representation of the file path before it gets converted to an NSURL, so can just try to reconstruct it, but this got me curious why I couldn't just assign a value...
As the error states, "file:///var/.../copperthief.mp4" is a char * not an NSURL.
To convert it to an NSURL, first you have to get the char *'s NSString representation by adding the # prefix:
#"file:///var/.../copperthief.mp4"
then convert the NSString to an NSURL using URLWithString::
[NSURL URLWithString:#"file:///var/.../copperthief.mp4"];
The first thing is that "..." is not an NSString. It's a C string. An NSString would be #"...", wouldn't it? And even then, if you wanted an NSURL, you'd have to convert from NSString to NSURL, wouldn't you? I mean, you can't assign a string of any kind to an NSSURL variable and expect it to work, can you? This is a computer language; you can't say just any old thing that comes into your head - you have to obey the rules.
Related
I've seen many questions on SO concerning converting between NSURL and NSString. They all involve using either NSString *path = [myURL absoluteString]; or NSString *path = [myURL path];. What is the actual difference between these methods? Is there a time when one should be used over the other? I tried consulting the Apple Docs, but I found it less than helpful.
I'm used to URL's only being mentioned in discussions concerning websites and other topics regarding sending information between different machines, and never being mentioned when dealing with just the file structure on a single machine. Perhaps this is where some of my confusion is coming from, since NSURL seems to be the preferred way of accessing files, regardless of whether that file exists on a network or on the local device. Or maybe that's a totally unrelated topic. I'm not even sure.
Question 1:
What is the actual difference between these methods?
Let's analyze this writing 6 lines of code - 3 for a local and 3 for http URL - and playing around with them a little bit.
Let's create an NSURL using the file:// scheme. If you ask yourself why there are 3 / after file: you should remember that a complete URL exists of a scheme (file:// and absolute or relative path (you can find more information on creating URLs in RFC 1808 on page 3). We use an absolute path which starts with a / so that we end up with ///.
NSURL *aLocalURL = [NSURL URLWithString:#"file:///Users/dennis/Desktop/"];
NSLog(#"absolute string: %#", aLocalURL.absoluteString);
NSLog(#"path: %#", aLocalURL.path);
Output:
absolute string: file:///Users/dennis/Desktop/
path: /Users/dennis/Desktop
So we see that absoluteString still knows its scheme whereas path doesn't have this information anymore.
Note: path is a file (directory) URL and as the docs state, the trailing slash it is stripped.
Now let's take a look at remote URLs. With these type of URLs most people are more familiar. We create it using the same procedure as for local URLs. Our scheme is now http:// and our path is www.apple.com/.
NSURL *anHTTPURL = [NSURL URLWithString:#"http://www.apple.com/"];
NSLog(#"absolute string: %#", anHTTPURL.absoluteString);
NSLog(#"path: %#", anHTTPURL.path);
Output:
absolute string: http://www.apple.com/
path: /
Again, we see that the absolute string still knows its scheme but path is now /. So path seems to be not an appropriate way when working with remote URLs.
However, when we have an URL like http://www.apple.com/index.html we get
absolute string: http://www.apple.com/index.html
path: /index.html
Reading the docs helps here, too:
Per RFC 3986, the leading slash after the authority (host name and port) portion is treated as part of the path.
So the path is everything beginning (and including) at the slash after the authority which is www.apple.com in our case.
Question 2
Is there a time when one should be used over the other?
From the docs: (method: path)
If this URL object contains a file URL (as determined with isFileURL), the return value of this method is suitable for input into methods of NSFileManager or NSPathUtilities.
In my opinion that sentence states clearly that you should use path when you work with NSFileManager or NSPathUtilities.
Conclusion:
When you work with remote URLs you (generally) use absoluteString, otherwise the result is not what you (generally) want.
When you work with local URLs use path.
Sources:
http://www.ietf.org/rfc/rfc1808.txt
http://www.ietf.org/rfc/rfc3986.txt
NSURL Class Reference
Adding to HAS' response -- the Apple docs mention that Path-based URLs are simpler in some ways, however file reference URLs have the advantage that the reference remains valid if the file is moved or renamed while your app is running.
From the documentation for "Accessing Files and Directories":
"Path-based URLs are easier to manipulate, easier to debug, and are generally preferred by classes such as NSFileManager. An advantage of file reference URLs is that they are less fragile than path-based URLs while your app is running. If the user moves a file in the Finder, any path-based URLs that refer to the file immediately become invalid and must be updated to the new path. However, as long as the file moved to another location on the same disk, its unique ID does not change and any file reference URLs remain valid."
https://developer.apple.com/library/content/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/AccessingFilesandDirectories/AccessingFilesandDirectories.html
One further note, and I've only tried this for Swift and URL not NSURL. The relativeTo form of URL:
URL(fileURLWithPath: aPath, relativeTo: URL)
generates a URL that behaves not fully like a remote URL (as in #HAS above) and not like a file URL.
So, for example:
let url0 = URL(fileURLWithPath: "/Foo")
let url1 = URL(fileURLWithPath: "Bar", relativeTo: url0)
print("\(url1.path)")
// Output: "/Bar\n"
(similar to results for a remote URL, but not a file URL).
If we use absoluteString, we get:
print("\(url1.absoluteString)")
// Output: "file:///Bar\n"
(not similar to either a file URL or a remote URL).
I am trying to update my app for WatchKit and I save a NSKeyedArchiver file to the NSDocumentsDirectory normally.
With updating to app groups I need to store it in the app groups folder. The issue I am having is I cant figure out how to just get the path, and not have it referenced as a file I am looking for.
The way it is set up now is to find the file it gives the path as a NSString
/Users/ME/Library/Developer/CoreSimulator/Devices/43F/data/Containers/Data/Application/5E/Documents/fav
but when I store to app groups, no matter which way I access the folder, it is returned
file:///Users/ME/Library/Developer/CoreSimulator/Devices/43F/data/Containers/Data/Application/5E/Documents/fav
What is the best way to just obtain the path to the shared group, rather than have the app looking for the direct file?
So coffee deprived me had forgotten about the .path for filemanager.
NSURL *fileManagerURL = [[NSFileManager defaultManager] containerURLForSecurityApplicationGroupIdentifier:#"group.com"];
NSString *tmpPath = [NSString stringWithFormat:#"%#", fileManagerURL.path];
NSString *finalPath = [NSString stringWithFormat:#"%#",[string stringByAppendingString:#"/Favourites2"]];
I was running into the same problem. I was going through the whole process of building a string to my save location and now I'm switching over to app groups and using the
NSURL *fileManagerURL = [[NSFileManager defaultManager] containerURLForSecurityApplicationGroupIdentifier:groupID];
Well, the problem is, now instead of a string to the location that starts with "/Users/yourname/Library..." you get "file:///Users/yourname/Library..."
Here's what I did. I created the NSURL. Then I called absoluteString on it.
NSURL groupPath = [[fileManager containerURLForSecurityApplicationGroupIdentifier:groupID] absoluteString];
I now have a string that I need to strip off the first 7 characters of, then my old code works just fine, except now instead of being in the Documents directory, it's in a shared app group that can be accessed by both my old code and my new watchkit extension.
Here's the code to strip off the first 7 characters (index 6 since you start with 0), you should be able to use either method...
NSString *newGroupPath = [groupPath substringFromIndex:6];
or
NSString *newGroupPath = [groupPath substringWithRange:NSMakeRange(6, [str length]-6)];
This just removes the "file://" from the absoluteString that was made from the NSURL and gives you back your older string path the starts "/Users/YourName/Library/Developer/yada yada yada"
Hope that helps you, I have spent 4 hours figuring it out.
It seems to work for me on the simulator, I haven't tried it on the Watch yet. But at least my app is now working the way it was before, just saving the data in a shared app group. (I have a singleton that manages all of my data throughout my app, and I want that same singleton to provide data to my watch app).
In my code I have to use URLWithString to play streaming(HLS) video and fileURLWithPath to play local video.
What is the difference between these two methods?
How should I use single method to play both videos.
Also I need to show last frame as still image when HSL video ends. Its now showing blank screen when it ends. How should i achieve this?
+URLWithString: produces an NSURL that represents the string as given. So the string might be #"http://www.google.com" and the URL represents http://www.google.com.
+fileURLWithPath: takes a path, not a URL, and produces an NSURL that represents the path using a file:// URL. So if you give it /foo/bar/baz the URL would represent file:///foo/bar/baz.
You can of course construct a file URL string manually and pass it to +URLWithString:, but +fileURLWithPath: is simpler to use when you already have a path, as you don't have to deal with escaping the string and coercing it to a URL format.
Similar thing happened in my app which use AVAudioPlayer. I tried with [NSURL URLWithString:path] and found out it fails to open certain mp3 files. I looked into error by a line like [[AVAudioPlayer alloc] initWithContentsOfURL:[NSURL URLWithString:path] fileTypeHint:AVFileTypeMPEGLayer3 error:&error], but the error was simply nil
However it was resolved by replacing the url with [NSURL fileURLWithPath:path].
In both case, the path path NSString * #"/var/mobile/Containers/Data/Application/4D96D4AE-2ED4-40B0-85D2-230E1AFA90E7/Documents/01-AudioTrack 01.mp3" 0x1457a8f0 Still I don't know the reason but now I should be careful using [NSURL URLWithString:].
PS. In NSURL Reference document, Apple said as below:
IMPORTANT
To create NSURL objects for file system paths, use fileURLWithPath:isDirectory: instead.
which clearly indicates [NSURL fileURLWithPath:] should be used for open file, though [NSURL URLWithString] also works for some cases.
Is there a recommended way of testing for CSS file type in iOS?
I am asking for the NSURLTypeIdentifierKey thus:
NSError *err = nil;
NSString *uti = nil;
NSURL *fileURL = [NSURL fileURLWithPath:path];
[fileURL getResourceValue:&uti forKey:NSURLTypeIdentifierKey error:&err];
This works for most filetypes that I've tried it on, and I get back one of the Uniform Type Identifiers listed in the System-Declared Uniform Type Identifiers reference. I can test for RTF, etc, like this.
I noticed that for a CSS file I get back a UTI of “dyn.ah62d4rv4ge80g65x” though. I thought perhaps my CSS file had some odd metadata, so I cut and paste its contents into a brand new file in VI, and the UTI for that file came back the same.
I then did "cat /dev/null > empty.css" and tested the UTI of that empty file and it too came back with “dyn.ah62d4rv4ge80g65x”, so clearly this UTI is being derived from the file extension.
I don't see any mention of “dyn…” UTIs in the reference. Can I rely on this odd string?
Usually this indicates a dynamic UTI, that is one that the system creates on the fly as it is not part of its database. In such case you probably have to examine other attributes like file extension or look inside the file.
I have this line of code, where I'm trying to assign a URL from an annotation on a custom MKAnnotation to a UIWebView controller.
webViewController.webViewURL = annotation.url;
Basically, I have an NSURL stored in annotation.url, and am trying to send this NSURL to webViewController.webViewURL.
When I try running this code, I get "EXC_BAD_ACCESS" in the console. Running the Allocations Instrument (with NSZombiesEnabled) didn't show any zombies... I can't understand why this is happening, especially since, if I change the line to use 'URLWithString...' and build a new NSURL...
webViewController.webViewURL = [NSURL URLWithString:annotation.url];
...it works without a problem, though I get the warning: Incompatible Objective-C types 'struct NSURL *', expected 'struct NSString *' when passing argument 1 of 'URLWithString:' from distinct Objective-C type
I ended up simply passing an NSString via the annotation.url, and converting that string to an NSURL in the method I was using above.
Oh well.