iOS opRaiseEvent -> customEventAction loss parameter passing NSData
Options
in Native
Hello,
I'm user of iOS SDK, and there is something strange. I send NSData as parameters:
But I see nil in eventContent on receive:
In the same time, NSString passed and received normally well.
Is there a way to send/receive just byte data, like a NSData?
I'm user of iOS SDK, and there is something strange. I send NSData as parameters:
func opRaiseEvent(_ reliable: Bool, _ parameters: NSObjectProtocol!, _ eventCode: nByte) -> Bool
But I see nil in eventContent on receive:
func customEventAction(_ playerNr: Int32, _ eventCode: nByte, _ eventContent: NSObject!)
In the same time, NSString passed and received normally well.
Is there a way to send/receive just byte data, like a NSData?
0
Best Answers
-
Hi @AlexeyZhukov.
NSData does not belong to the data types that are supported by Photons serialization.
You could add it as a custom type, if you wanted to, though.
The Client informs you about unsupported data types via an error level log message, if you assign an implementation of the EGBaseListener protocol to ListenerEGBase.Listener, like shown in -NetworkLogic::initWithOutputListener ()line 89 of NetworkLogic.mm from demo_loadBalancing_objc inside the SDKs demo folder.
Photons serialization supports the following types:
nByte
short
int
int64
bool (note: due to a bug in the latest iterations of Swift (not in Photon, but in the Swift language itself), there is currently no way to pass a bool to Photon from Swift code - as a workaround you can just store your boolean value in a variable of another type, i.e. nByte)
float
double
NSString
EGArray (a subclass of NSArray, which enforces that all array elements have the same type)
NSArray
EGDictionary (a subclass of NSDictionary, which enforces that all keys-value pairs share the same key type and the same value type))
NSDictionary
An NSData instance is just an array of bytes. You can just access the raw bytes of an NSData instance and use them to create an EGArray instance with element type nByte.
Example code for creating an EGArray with element type nByte:NSValue* valArray[10]; for(nByte i=0; i<10; ++i) valArray[i] = [NSValue valueWithBytes:&i objCType:@encode(nByte)]; EGArray* arr = [EGArray arrayWithObjects:valArray count:10];
5 -
Hi @AlexeyZhukov.
Yes, this is supported.
objective C: nByte - C++: nByte
objective C: short - C++: short
objective C: int - C++: int
objective C: int64 - C++: int64
objective C: bool - C++: bool
objective C: float - C++: float
objective C: double - C++: double
objective C: NSString - C++: JString
objective C: EGArray of type x - C++: x* - (i.e.: EGArray of type nByte - nByte*)
objective C: NSArray - C++: Object*
objective C: EGDictionary of keytype x and valtype y - C++: Dictionary<x, y>
objective C: NSDictionary - C++: Hashtable
objective C: EGCustomType - C++: CustomType
In fact the objective C client is just a wrapper around the C++ client.
Accordingly the objective C client does not have it's own (de-)serialization code, but converts all types to their C++ equivalents when passing them to the underlying C++ APIs for serialization and back to the matching objective C types when receiving deserialized data from the underlying C++ APIs.
Hence under the hood the objective C client and the C++ client run the exact same C++ serialization and deserialization code.
Therefor if you can successfully transfer some data between two objective C clients, then it already has been successfully serialized and deserialized by the underlying C++ client anyway and hence the C++ client for Android will understand it as well, as it shares the same codebase with the iOS C++ client.5
Answers
-
Hi @AlexeyZhukov.
NSData does not belong to the data types that are supported by Photons serialization.
You could add it as a custom type, if you wanted to, though.
The Client informs you about unsupported data types via an error level log message, if you assign an implementation of the EGBaseListener protocol to ListenerEGBase.Listener, like shown in -NetworkLogic::initWithOutputListener ()line 89 of NetworkLogic.mm from demo_loadBalancing_objc inside the SDKs demo folder.
Photons serialization supports the following types:
nByte
short
int
int64
bool (note: due to a bug in the latest iterations of Swift (not in Photon, but in the Swift language itself), there is currently no way to pass a bool to Photon from Swift code - as a workaround you can just store your boolean value in a variable of another type, i.e. nByte)
float
double
NSString
EGArray (a subclass of NSArray, which enforces that all array elements have the same type)
NSArray
EGDictionary (a subclass of NSDictionary, which enforces that all keys-value pairs share the same key type and the same value type))
NSDictionary
An NSData instance is just an array of bytes. You can just access the raw bytes of an NSData instance and use them to create an EGArray instance with element type nByte.
Example code for creating an EGArray with element type nByte:NSValue* valArray[10]; for(nByte i=0; i<10; ++i) valArray[i] = [NSValue valueWithBytes:&i objCType:@encode(nByte)]; EGArray* arr = [EGArray arrayWithObjects:valArray count:10];
5 -
Thanks you for reply.
BTW, aim is serialization into "some raw bytes" – to let iOS clients and Android clients to exchange the data. Is it possible? I mean, if I use iOS-types, like a NSArray etc, then android-programmer can understand transferred types with photon-android-sdk, is it right?
0 -
Hi @AlexeyZhukov.
Yes, this is supported.
objective C: nByte - C++: nByte
objective C: short - C++: short
objective C: int - C++: int
objective C: int64 - C++: int64
objective C: bool - C++: bool
objective C: float - C++: float
objective C: double - C++: double
objective C: NSString - C++: JString
objective C: EGArray of type x - C++: x* - (i.e.: EGArray of type nByte - nByte*)
objective C: NSArray - C++: Object*
objective C: EGDictionary of keytype x and valtype y - C++: Dictionary<x, y>
objective C: NSDictionary - C++: Hashtable
objective C: EGCustomType - C++: CustomType
In fact the objective C client is just a wrapper around the C++ client.
Accordingly the objective C client does not have it's own (de-)serialization code, but converts all types to their C++ equivalents when passing them to the underlying C++ APIs for serialization and back to the matching objective C types when receiving deserialized data from the underlying C++ APIs.
Hence under the hood the objective C client and the C++ client run the exact same C++ serialization and deserialization code.
Therefor if you can successfully transfer some data between two objective C clients, then it already has been successfully serialized and deserialized by the underlying C++ client anyway and hence the C++ client for Android will understand it as well, as it shares the same codebase with the iOS C++ client.5