Changing app settings from Garmin Connect Android app causes app to crash

I'm new to the Connect SDK and I've built a datafield app to start. I'm currently having an issue with my app where I if I change the app settings from the Connect Android app and then try to run with the custom data field, it crashes. It doesn't matter what I change my settings to (valid or invalid). I can however, change settings using Garmin Express and everything works fine. Even when the settings get busted from the mobile app, I can just go change the settings to whatever I want with Garmin Express and all is well again. I'm checking all settings types before using them using "instanceof" and verifying I'm getting what I expect. Everything works fine in the emulator and as I mentioned with Garmin Express and my 520. If I try changing the settings via the mobile app and not running and plugging the device into the computer and checking the log, I see this warning:

WARNING: Unable to serialize app data
STORE_ID: da79ef76eb9248baa360dd4dd1519b03

If I open the the .SET file, I can see in the binary data that the settings changes from the app seem to be persisted to the settings file. Given the only way for me to really test out code changes to my settings code is by publishing to the app store, I'm looking for a bit of help on how I might debug this. The emulator has proven to be completely useless when it comes to settings as things always seem to work in the emulator and then crash on a device. Even when I was not checking data types completely, the emulator runs great as does side loading to my device. It's only when I use the mobile app that I'm getting a crash now. Any help would be appreciated.

Thanks,

Rob

ChubbyCrusher over 8 years ago

I figured out that the issue was caused by a setting (not app property) that I was trying to save to the object store not getting saved and apparently causing issues with the app properties or crashing the app. I've removed settings I was saving to the object store because they don't seem to save correctly when changing settings from the mobile app no matter what I do. It's a shame that the only way to test changes to my app with regards to settings is to upload it to the store and then pull it down to my device. I can't really test my app with out uploading it and causing heartache for end users. Given there's no way to debug on a device from Eclipse, it would be very helpful if the logging of crashes issues were much more verbose in the crash log so that I could chase down issues more quickly.

On a side note, the monkeygraph app seems to just crash with I give it a fit file and my app. I guess that's to be expected?

travis.vitek over 8 years ago

It's a shame that the only way to test changes to my app with regards to settings is to upload it to the store and then pull it down to my device. I can't really test my app with out uploading it and causing heartache for end users.

You can create a test version of your app and publish it to the store with the DO NOT SUBMIT prominently posted in the app name or description. That way you can test the final end-user experience without affecting users.

Travis

jim_m_58 over 8 years ago

I figured out that the issue was caused by a setting (not app property) that I was trying to save to the object store not getting saved and apparently causing issues with the app properties or crashing the app.

Just noticed your post.. In the last couple days I noticed that the ObjStr in one of apps isn't saving with the same error (the Serialize) on a 520. (I don't do anything with app settings in that one...)

ChubbyCrusher over 8 years ago

You can create a test version of your app and publish it to the store with the DO NOT SUBMIT prominently posted in the app name or description. That way you can test the final end-user experience without affecting users.

Travis

You're saying that if I put that in the title, the app won't be available for users to download or it will, but users will see that and know not to download it? Just want to make sure I understand. Thanks for the info either way. :o

travis.vitek over 8 years ago

Read carefully. You need to make a test version of your app (with a unique UUID in manifest.xml) and upload that to the app store with a comment indicating you don't want it to be approved. As long as the app is not approved, it will not be made available to the public but can be downloaded from your account.

Travis

ChubbyCrusher over 8 years ago

Read carefully. You need to make a test version of your app (with a unique UUID in manifest.xml) and upload that to the app store with a comment indicating you don't want it to be approved. As long as the app is not approved, it will not be made available to the public but can be downloaded from your account.

Travis

Travis,

I appreciate the help, but I don't think it's my reading comprehension that's the problem. You now mention that I need to added a unique UUID to my manifest file as well as change the title. That's another detail that was not in your first post. I've read the documentation a few times and I don see any mention of uploading a "test" version of the app to the store, so this appears to be inside baseball information and before I upload another broken version of my app to the store, I'd like to fully understand it. By "test" version of my app, does that mean adding "--unit-test" when I build it or is there some other hidden feature a new developer wouldn't know about and is expected to just figure out? The docs are really light, the SDK is super buggy, and the emulators don't even remotely act like the real devices, so forgive me for coming off a bit dense here, but I'm just trying to figure out how to use this stuff properly. Again, I appreciate your help.

travis.vitek over 8 years ago

I appreciate the help, but I don't think it's my reading comprehension that's the problem.

I wasn't implying that you were unable to read my original post. I was trying to point out that you need to read the following text carefully because I was trying to spell out exactly what you need to do.

You now mention that I need to added a unique UUID to my manifest file as well as change the title. That's another detail that was not in your first post.

Again, the second post was written to clarify what I wrote in the first. I did say that you need to create a test version of your app and publish to the store, and I meant exactly that. You need to create and publish a new app (from the app store's perspective), and you need to tag it appropriately so it will not make its way through the approval process.

I've read the documentation a few times and I don see any mention of uploading a "test" version of the app to the store, so this appears to be inside baseball information

This is not in the documentation or the FAQ, but has been written about in these forums and used successfully by others. This post is where it all started.

By "test" version of my app, does that mean adding "--unit-test"...

You are simply uploading an app that you can tweak without affecting users. It can be a completely new app, or it can be a build of your existing app with debugging code in it. Nobody will care other than you since nobody else will have access to it. The only requirement is that it have a unique UUID so that the app store treats it as a unique app.

As for the app you've already got in the app store, you have a few options. You could...

Add a comment to the description of the app to indicate there are problems with settings and GCM.
Send an e-mail to [email][email protected]

Delete the app from the app store entirely. You will lose download stats and reviews, but you can immediately take it down so nobody else is affected, but the change will take effect immediately.

I'm not sure how long your app has been available or how many downloads it has. If it hasn't been long or you don't have many downloads, I'd just delete it and upload a new version once you've got the kinks worked out. Otherwise I'd probably just add a comment and hope people read the documentation.

travis.vitek over 8 years ago

Additionally, the problem you're seeing seems awful similar to problems that were found a while ago relating to GCM on Android. I posted some code to this thread with a wrapper class around the app settings system. It validates settings and tries to ensure that you never get a null or garbage value back from the object store. I'm using it in all code I write anymore.

Travis

jim_m_58 over 8 years ago

And there's also a mention of the GCM/A things with settings in the "New Developer FAQ #2" at the top of the forum.

One other odd thing I've seen with GCM/A (it's been reported), is let's say you have version 1 of your app on your watch, and put a new version 2 in the store.

If you then go to settings on GCM/A, you'll likely see the settings for version 2, so you want to be careful to make sure it won't cause problems with the version 1 on the watch.

ChubbyCrusher over 8 years ago

Thanks for the help guys. It's much appreciated. I seem to have worked out all the bugs in the simple app I posted to test out the SDK and I've got about a dozen friends that have been using it the last few days that have confirmed it's working as expected on different devices. In the end, I wrote a function that does all kinds of validation of the properties before getting/setting them and all the bugs seem to be worked out.

With regards to uploading a test app: thanks for the very clear instructions and sorry for my last response. At the end of the day, I have a pretty good idea of what I can/can't do with the SDK now and that was the goal of this exercise, but it's good to know if I decide to move forward and create a real app, I'll have a solid avenue for testing on the app store without affecting my end users.

Rob