03-26-2021, 05:48 AM
I'm not sure why you are seeing the issue with the database type being reported as 0. That sounds to me like some of the data is being garbled over bluetooth as I'm not doing any kind of integrity check on what is being sent. I'm not a big fan of bluetooth as I find it to be fairly unreliable. I don't have anything implemented in the sync functionality where it can request that data be sent again if it wasn't correct the first time around. That would require massive changes to the design that would most likely introduce all sorts of problems along the way. I'm relying on the messaging to be correct because I'm using TCP and it's supposed to just be on a local network (or over a short distance with bluetooth), so I didn't think that it would be necessary to add my own layer of reliability on top of that. I should mention that very little code changed for version 3.0.0 with the sync functionality. I had to add some new checks for the new annotation data, and I moved the database initialization to the start of the sync instead of reading things out piece by piece (as this is slower overall), but I didn't really change anything that would explain why you are seeing more problems now.
As far as the second issue you reported, that sounds like an issue with the OS and the bluetooth stack. I've certainly seen issues like that when connecting to other bluetooth devices with my phone (not related to MobileSheets), so I think that's just the nature of bluetooth. As I said, I don't find it to be particularly reliable and it can't handle large data transmissions at all.
As far as your feature request, the name that is listed on the leader device is obtained by combining android.os.Build.BRAND and android.os.Build.DEVICE, which is where the Onyx Max comes from. This is used for both WiFi and Bluetooth. On the client devices, since they have to list a name before they've actively connected to the leader, I use the BluetoothDevice.getName() from the device that is detected while scanning, so that's why you see the bluetooth device name you assigned. If you would like me to change the behavior so that the server lists the BluetoothDevice.getName() value as well, I can certainly do that. I have made that change in my code and it will be available with the next update.
As far as the future plans, the iOS version will come first, then the song versioning. Thanks for spreading the word to your fellow musicians!
Mike
As far as the second issue you reported, that sounds like an issue with the OS and the bluetooth stack. I've certainly seen issues like that when connecting to other bluetooth devices with my phone (not related to MobileSheets), so I think that's just the nature of bluetooth. As I said, I don't find it to be particularly reliable and it can't handle large data transmissions at all.
As far as your feature request, the name that is listed on the leader device is obtained by combining android.os.Build.BRAND and android.os.Build.DEVICE, which is where the Onyx Max comes from. This is used for both WiFi and Bluetooth. On the client devices, since they have to list a name before they've actively connected to the leader, I use the BluetoothDevice.getName() from the device that is detected while scanning, so that's why you see the bluetooth device name you assigned. If you would like me to change the behavior so that the server lists the BluetoothDevice.getName() value as well, I can certainly do that. I have made that change in my code and it will be available with the next update.
As far as the future plans, the iOS version will come first, then the song versioning. Thanks for spreading the word to your fellow musicians!
Mike