I have an iOS app that has a boolean declared in a model as:
var leader :Bool = false
later, I update it with:
listener.leader = true
let dataStore = backendless.data.of(Listeners.ofClass())
dataStore.save(
listener,
response: { (result: AnyObject!) -> Void in
},
error: { (fault: Fault!) -> Void in
let msg = “Save Listener Clip Error: (fault.faultCode)”
let code = “code:(fault.faultCode) detail:(fault.detail)”
notificationCenter.postNotification(NSNotification(name: “saveListenerErr”, object: nil, userInfo: [“result”: msg,“code”: code]))
})
This seemed to be working fine in all of our tests. Then a user tried the app on an iPhone 5C (a 32-bit device) and I get the error code 1007 - unable to save object - invalid data type for properties leader. So, we began more extensive testing and on all 64-bit devices it works fine, but on 32-bit devices it does not. What should I do to fix this?
Hi Tom,
Thanks for the clarifications, the internal task BKNDLSS-13240 has been created to investigate the issue.
Hi Tom,
We cannot reproduce this issue with our sample project (see in attachment). It works for us on all our 32bit devices and simulators. (It shows an application architecture in the log).
Could you try it with your devices, how will it work for you?
If you will get an error, please tell us about device model and its iOS version.
Regards,
Slava
TestS3NumericSave.zip (19.31MB)
I did, and here’s the log info:
APPLICATION ARCH -> 32 bit
info props (1) -> Optional([AnyHashable(“logic”): 1, AnyHashable(“count”): 10, AnyHashable(“real”): 27.7, AnyHashable(“afloat”): 0.78])
Info has been saved: true
info props (2) -> Optional([AnyHashable("__meta"): {“relationRemovalIds”:{},“selectedProperties”:[“created”,"___saved",“count”,"___class",“logic”,“real”,“ownerId”,“afloat”,“updated”,“objectId”],“relatedObjects”:{}}, AnyHashable("___class"): TestNumerics, AnyHashable(“objectId”): B1DA2AE9-DAE1-6DAF-FFC3-943FF5B54A00, AnyHashable(“real”): 89.5, AnyHashable(“created”): 2016-09-25 15:11:27 +0000, AnyHashable(“logic”): 0, AnyHashable(“updated”): <null>, AnyHashable(“count”): 18, AnyHashable(“afloat”): 4.23, AnyHashable(“ownerId”): <null>])
Info has been updated: false
I’m assuming that last false is a bad thing. However, I didn’t get the 1007 error. I did have to lower the iOS version to 8.0 so that I could run it on the device. How can we diagnose what’s going on with the error I’m getting?
–tom
Tom, you wrote: “I’m assuming that last false is a bad thing”. Why?
See the code: info.logic is set in false, then info object is updated. See on app dashboard - this BOOLEAN property is “False”. So, all right!
func saveNumerics() {
if backendless!.is64bitHardware() {
print("APPLICATION ARCH -> 64 bit")
}
else {
print("APPLICATION ARCH -> 32 bit")
}
let dataStore = backendless!.data.of(TestNumerics.self)
var info = TestNumerics()
info.logic = true
info.count = 10
info.real = 27.7
info.afloat = 0.78
print("info props (1) -> \(Types.propertyDictionary(info))")
// save object synchronously
var error: Fault?
info = dataStore!.save(info, fault: &error) as! TestNumerics
if error == nil {
print("Info has been saved: \(info.logic)")
}
else {
print("Server reported an error (1): \(error)")
}
// update object asynchronously
info.logic = false
info.count = 18
info.real = 89.5
info.afloat = 4.23
print("info props (2) -> \(Types.propertyDictionary(info))")
dataStore!.save(
info,
response: { (result: Any?) -> Void in
print("Info has been updated: \((result as! TestNumerics).logic)")
},
error: { (fault: Fault?) -> Void in
print("Server reported an error (2): \(error)")
})
}
And you don’t get any errors, OK? So, you cannot reproduce this issue?
I cannot reproduce the issue with the code that you sent. My code, however, which is nearly identical in concept to this most definitely fails. How do you suggest we test this? What version of the SDK are you using? How can I check? Maybe there’s a version difference?
First, upload the latest Backendless SDK (pod 3.0.41 release), and check if the problem persists.
Second, can you change my code so it will reproduce the problem?
Or give us your code which reproduces this issue (you could upload it to Dropbox or Google Drive and send its url to support@backendless.com).
OK, so updating to the latest release did fix it. Apparently, the version I was using was a bit older. So, it seems to be all good now. We’ll do more in depth testing over the next few days, but it seems fine. Thanks for your help!