The signature for the received DM callback is this:
static int device_method_callback(const char* method_name, const unsigned char* payload, size_t size, unsigned char** response, size_t* resp_size, void* userContextCallback)
The consequence of this is that you can only obtain the Method Name, no other DM data is passed to the callback (as opposed to the ll functions). Sometimes final result is delayed from time of receipt until processed and an answer can be sent.
At least, we need the "RequestId" of the DM to send a final report using D2C message, or we cannot match these in the Cloud.
Adding an extended version of this that contains the handle to the actual DM message struct would allow us to extract the relevant data. Even better is to also add a flag that makes the SDK delay the reply and an API call to send the reply later by passing the pointer to the DM struct (and it is deallocated at that time).
The signature for the received DM callback is this:
static int device_method_callback(const char* method_name, const unsigned char* payload, size_t size, unsigned char** response, size_t* resp_size, void* userContextCallback)The consequence of this is that you can only obtain the Method Name, no other DM data is passed to the callback (as opposed to the ll functions). Sometimes final result is delayed from time of receipt until processed and an answer can be sent. At least, we need the "RequestId" of the DM to send a final report using D2C message, or we cannot match these in the Cloud.
Adding an extended version of this that contains the handle to the actual DM message struct would allow us to extract the relevant data. Even better is to also add a flag that makes the SDK delay the reply and an API call to send the reply later by passing the pointer to the DM struct (and it is deallocated at that time).