I'm trying to write a String to an NSOutputStream in Swift. Writing Strings that way with Objective C usually works by passing it as NSData
NSData *data = [[NSData alloc] initWithData:[mystring dataUsingEncoding:NSASCIIStringEncoding]];
[outputStream write:[data bytes] maxLength:[data length]];
This does not work with swift
var data: NSData = mystring.dataUsingEncoding(NSUTF8StringEncoding)!
outputStream.write(data, maxLength: data.length)
this yields the error
'NSData' is not convertible to 'UnsafePointer'
for the line that writes the data to the stream.
How would you write a String to an NSOutputStream in Swift?
In recent Swift it should be even easier and NSData is no longer needed.
let s = "String to encode"
let encodedDataArray = [UInt8](s.utf8)
outputstream.write(encodedDataArray, maxLength: encodedDataArray.count)
Arrays can be accessed as buffers of the correct their type (see withUnsafeBufferPointer). I think the array is necessary because the utf8 view is not actually instantiated as a full array but just a view into the original string.
In production code you should check the return value of the write to the output stream and depending on your scenario check there is space before the write but the focus of this answer is the encoding of the Swift String so that it can be written.
There are two issues here. The first is that you're passing data to outputStream.write() and not data.bytes (like you passed [data bytes] in your Objective-C code). The second issue is that data.bytes returns an UnsafePointer<Void>, but NSOutputStream.write() takes an UnsafePointer<UInt8>. Luckily, UnsafePointer has a way to convert between types:
/// Convert from a UnsafePointer of a different type.
///
/// This is a fundamentally unsafe conversion.
init<U>(_ from: UnsafePointer<U>)
Putting those things together makes your code look something like this:
let data: NSData = mystring.dataUsingEncoding(NSUTF8StringEncoding)!
outputStream.write(UnsafePointer<UInt8>(data.bytes), maxLength: data.length)
Hope this example helps out. It writes a string to document directory. Note that outputStream is tested using Swift 1.1 with failable initializer.
var myString = "Hello world!"
var docPath = NSSearchPathForDirectoriesInDomains(.DocumentDirectory, .UserDomainMask, true)[0] as String
var path = docPath.stringByAppendingPathComponent("doc")
var outputStream = NSOutputStream(toFileAtPath: path, append: false)
var data: NSData = myString.dataUsingEncoding(NSUTF8StringEncoding)!
var buffer = [UInt8](count:data.length, repeatedValue:0)
data.getBytes(&buffer)
outputStream?.open()
outputStream?.write(&buffer, maxLength: data.length)
outputStream?.close()
Regards
Related
I have getting data from plist to NSString, in result I see something like this "{{1848,594},{154,176}}". What is the best way to convert every single number to separate NSInteger?
NSString *frame = [myPlistKey objectForKey:#"frame"];
How to convert frame to 4 separate integers?
In this specific case, it looks like you are trying to parse the string representation of an NSRect, in which case you can just use NSRectFromString() from the Foundation framework.
Edit:
Since you are not much specific, I will try to cover your situation. If i count with the fact you have NSString *frame filled with {{1848,594},{154,176}}:
NSString *stringWithoutLeftBracket = [frame
stringByReplacingOccurrencesOfString:#"{" withString:#""];
NSString *stringWithoutRightBracket = [stringWithoutLeftBracket
stringByReplacingOccurrencesOfString:#"}" withString:#""];
NSArray *frameArray = [stringWithoutRightBracket componentsSeparatedByCharactersInSet:[NSCharacterSet characterSetWithCharactersInString:#","]];
Then you can access objects with indexes like:
NSInteger integer = [[frameArray objectAtIndex:0] integerValue];
But also you could use a for loop like this:
for (NSInteger integer in frameArray) {
// Do something
}
In my opinion you have a string made from rect, means you could convert it.
According to Apple documentation, the class method
+datawithBytesNoCopy:length:freeWhenDone:
inherited from NSData
Creates and returns a data object that holds a given number of bytes from a given buffer.
But
NSUInteger len = 1024;
char *buffer = malloc(len);
NSMutableData *data = [NSMutableData dataWithBytesNoCopy:buffer length:len freeWhenDone:YES];
char *dataBytes = data.mutableBytes;
NSLog(#"%#", dataBytes == buffer ? #":D" : #":(");
prints
:(
The method seems to actually make a copy, where I expected it not to.
Am I using this the wrong way?
The equivalent NSData method works as expected.
How would I create an NSMutableData object pointing to an already existing buffer without taking any ownership?
I would guess that you just can't do what you want to do. After all, if you have an NSMutableData and append some more data to it, then the buffer would need to be reallocated, and no longer use the pointer you supplied.
Apple's Binary Data Programming Guide says that in the case of NSMutableData, the bytes are copied anyway.
Basically, the question is - are the following essentially the same?
NSString *value1 = ...;
NSString *value2 = [[NSString alloc] initWithString:value1];
and
NSString *value1 = ...;
NSString *value2 = [value1 copy];
Conceptually, yes. However, there is one difference: alloc always creates a new string, whereas copy may return the same string.
In particular, immutable objects, such as immutable strings, are likely respond to copy by returning themselves rather than creating and returning a copy. (After all, if you can't change anything about the original, why would you really need a copy?) Mutable strings will respond to it by creating and returning a copy, as you'd expect.
initWithString: is in the middle: It may release the receiver and return the string you gave it, similar to how copy may return the receiver. However, if that happens, it means you wasted the creation of the string you created with alloc. With copy, you may not need to create any additional objects at all.
About the only reason to use alloc and initWithString: is if you have your own subclass of NSString and want to make an instance of it from an existing string. copy won't use your desired subclass. Since subclassing NSString is practically never warranted in Cocoa, the same is true of using initWithString: (or stringWithString:).
So the bottom line is, just use copy (or mutableCopy). It's shorter, clearer about your intent, and can be faster.
Non-mutable strings are treated a bit special, compared to ordinary objects, so in this case, yes, the two operations are the same.
To wit:
NSString *str1 = #"string";
NSString *str2 = [str1 copy];
NSString *str3 = [[NSString alloc] initWithString: str1];
NSLog(#"str1: %p, str2: %p, str3: %p", str1, str2, str3);
Which gives me the following output:
str1: 0x108a960b0, str2: 0x108a960b0, str3: 0x108a960b0
Since the pointer addresses are the same, we are talking about the same object.
I often use Transformable for Core Data attributes, so I can change them later.
However, it seems like, if I want to use NSPredicate to find a NSManagedObject, using "uniqueKey == %#", or "uniqueKey MATCHES[cd] %#", it's not working as it should.
It always misses matching objects, until I change the attributes of the uniqueKey of the matching object to have specific class like NSString, or NSNumber.
Can someone explain the limitation of using NSPredicate with Transformable attributes?
Note: I'm not sure when/if this has changed since 5/2011 (from Scott Ahten's accepted answer), but you can absolutely search with NSPredicate on transformable attributes. Scott correctly explained why your assumptions were broken, but if Can someone explain the limitation of using NSPredicate with Transformable attributes? was your question, he implied that it is not possible, and that is incorrect.
Since the is the first google hit for "Core Data transformable value search nspredicate" (what I searched for trying to find inspiration), I wanted to add my working answer.
How to use NSPredicate with transformable properties
Short, heady answer: you need to be smart about your data transformers. You need to transfrom the value to NSData that contains what I'll call "primitive identifying information", i.e. the smallest, most identifying set of bytes that can be used to reconstruct your object. Long answer, ...
Foremost, consider:
Did you actual mean to use a transformable attribute? If any supported data type -- even binary data -- will suffice, use it.
Do you understand what transformable attributes actually are? How they pack and unpack data to and from the store? Review Non-Standard Persistent Attributes in Apple's documentation.
After reading the above, ask: does custom code that hides a supported type "backing attribute" work for you? Possibly use that technique.
Now, past those considerations, transformable attributes are rather slick. Frankly, writing an NSValueTransformer "FooToData" for Foo instances to NSData seemed cleaner than writing a lot of adhoc custom code. I haven't found a case where Core Data doesn't know it needs to transform the data using the registered NSValueTransformer.
To proceed simply address these concerns:
Did you tell Core Data what transformer to use? Open the Core Data model in table view, click the entity, click the attribute, load the Data Model Inspector pane. Under "Attribute Type: Transformable", set "Name" to your transformer.
Use a default transformer (again, see the previous Apple docs) or write your own transformer -- transformedValue: must return NSData.
NSKeyedUnarchiveFromDataTransformerName is the default transformer and may not suffice, or may draw in somewhat-transient instance data that can make two similar objects be different when they are equal.
The transformed value should contain only -- what I'll call -- "primitive identifying information". The store is going to be comparing bytes, so every byte counts.
You may also register your transformer globally. I have to do this since I actually reuse them elsewhere in the app -- e.g. NSString *name = #"FooTrans"; [NSValueTransformer setValueTransformer:[NSClassFromString(name) new] forName:name];
You probably don't want to use transforms heavily queried data operations - e.g. a large import where the primary key information uses transformers - yikes!
And then in the end, I simply use this to test for equality for high-level object attributes on models with NSPredicates -- e.g. "%K == %#" -- and it works fine. I haven't tried some of the various matching terms, but I wouldn't be surprised if they worked sometimes, and others not.
Here's an example of an NSURL to NSData transformer. Why not just store the string? Yeah, that's fine -- that's a good example of custom code masking the stored attribute. This example illustrates that an extra byte is added to the stringified URL to record if it was a file URL or not -- allowing us to know what constructors to use when the object is unpacked.
// URLToDataTransformer.h - interface
extern NSString *const kURLToDataTransformerName;
#interface URLToDataTransformer : NSValueTransformer
#end
...
// URLToDataTransformer.m - implementation
#import "URLToDataTransformer.h"
NSString *const kURLToDataTransformerName = #"URLToDataTransformer";
#implementation URLToDataTransformer
+ (Class)transformedValueClass { return [NSData class]; }
+ (BOOL)allowsReverseTransformation { return YES; }
- (id)transformedValue:(id)value
{
if (![value isKindOfClass:[NSURL class]])
{
// Log error ...
return nil;
}
NSMutableData *data;
char fileType = 0;
if ([value isFileURL])
{
fileType = 1;
data = [NSMutableData dataWithBytes:&fileType length:1];
[data appendData:[[(NSURL *)value path] dataUsingEncoding:NSUTF8StringEncoding]];
}
else
{
fileType = -1;
data = [NSMutableData dataWithBytes:&fileType length:1];
[data appendData:[[(NSURL *)value absoluteString] dataUsingEncoding:NSUTF8StringEncoding]];
}
return data;
}
- (id)reverseTransformedValue:(id)value
{
if (![value isKindOfClass:[NSData class]])
{
// Log error ...
return nil;
}
NSURL *url = nil;
NSData *data = (NSData *)value;
char fileType = 0;
NSRange range = NSMakeRange(1, [data length]-1);
[data getBytes:&fileType length:1];
if (1 == fileType)
{
NSData *actualData = [data subdataWithRange:range];
NSString *str = [[NSString alloc] initWithData:actualData encoding:NSUTF8StringEncoding];
url = [NSURL fileURLWithPath:str];
}
else if (-1 == fileType)
{
NSData *actualData = [data subdataWithRange:range];
NSString *str = [[NSString alloc] initWithData:actualData encoding:NSUTF8StringEncoding];
url = [NSURL URLWithString:str];
}
else
{
// Log error ...
return nil;
}
return url;
}
#end
Transformable attributes are usually persisted as archived binary data. As such, you are attempting to compare an instance of NSData with an instance of NSString or NSNumber.
Since these classes interpret the same data in different ways, they are not considered a match.
you can try this way
NSExpression *exprPath = [NSExpression expressionForKeyPath:#"transformable_field"];
NSExpression *exprKeyword = [NSExpression expressionForConstantValue:nsdataValue];
NSPredicate *predicate = [NSComparisonPredicate predicateWithLeftExpression:exprPath rightExpression:exprKeyword modifier:NSDirectPredicateModifier type:NSEqualToPredicateOperatorType options:0];
I have an NSData object which I am trying to turn into an NSString using the following line of code:
NSString *theData = [[NSString alloc] initWithData:photo encoding:NSASCIIStringEncoding];
Unfortunately I am getting the following result, instead of my desired binary output (can I expect a binary output here?);
ÿØÿà
I'd appreciate any help.
Thanks. Ricky.
If you want to transform some arbitrary binary data into a human readable string (for example, of a series of hex values) you are using the wrong method. What you are doing is interpreting the data itself as a string in ASCII encoding.
To simply log the data to a file or to stdout, you can use [theData description].
What you mean by "binary output" is unclear. If you're expecting the string to contain text along the lines of "01010100011110110" or "0x1337abef", you are mistaken about how NSString works. NSString's initWithData:encoding: tries to interpret the data's bytes as though they were the bytes of a string in a particular encoding. It's the opposite of NSString's dataUsingEncoding: — you can call initWithData:encoding: with the result of dataUsingEncoding: and get back the exact same string.
If you want to transform the data into, say, a human-readable string of hex digits, you'll need to do the transformation yourself. You could do something like this:
NSMutableString *binaryString = [NSMutableString stringWithCapacity:[data length]];
unsigned char *bytes = [data bytes];
for (int i = 0; i < [data length]; i++) {
[binaryString appendFormat:#"%02x", bytes[i]];
}
You cannot parse binary data with the initWithData: method. If you want the hexadecimal string of the contents then you can use the description method of NSData.