• Replies 19 replies
  • Subscribers 21 subscribers
  • Views 4165 views
  • Users 0 members are here
Options
Related

Odd makeWebRequest behavior with Widget vs App on F6 pro while connected to GCM 4.47.2

sabeard

I just updated my widget to consolidate two makeWebRequests into a single network transaction.  At the same time I released a app version of the widget which is based on the exact same code with the exception of a couple string entries to designate the widget from the app.  The web query is designed to check the device registration status and return the current expiration date of the trial or registration.  Yesterday I got a report that the widget was not recognizing the registration after saving the settings on a F6pro.  I tested on my own F6pro and was able to reproduce the issue.  I can see the issue in both my released widget and the beta test build, but my new full device app version is able to work properly.  Based on the behavior the widget is acting like it is not getting the response from the webserver, even though in the webserver logs I can see the query get returned with a 200 OK message.

After doing some testing in the simulator, I have verified that the code is working as planned.  I can see in the HTTP log in the simulator provide the query and the return response.  I also enabled some println calls to display the returned value and display the variable which were updated from the response.  I did a test build of my beta widget so I could enable logging on the real device.  After installing the beta widget on the device and adding the text log file, my theory was confirmed.  I can see in the log file the outgoing makeWebRequest URL where the request was sent.  I can see the 200 OK in the webserver logs.  I never see the callback method get called so the results can be parsed and updated on the device.  What make it more confusing is the full device app version still works fine.  So I know the code does work as intended.

I also tested the widget on a VA3m and both the app and the widget version worked just fine so I have to believe it is caused by something either with the device FW version, or with how GCM is interfacing between the watch and the internet.  My guess is something with the latest version of GCM is causing the problem because I had no problems with the widget on the F6pro when I first installed the test build of the widget on Sept 19 using GCM android 4.47.1.  Over the weekend I update GCM android to 4.47.2 and now thing are broke.  I also confirmed with the user reporting a problem that they to are running GCM Android version 4.47.2.  To make matters more confusing, the same widget on an F5pro, connected to the same watch works fine.

I don't understand how two different CIQ apps on the same device using the exact same functions can have completely different results when run.  One never sees the call back and the other works fine. 

Any recommendations on how to troubleshoot?

  • As a follow up, I am still experiencing the same issue, but have had 5 more reports of similar behaviors.  The two thing that seem to be common is all users have a device based on the F6 family (i.e. Tactix Delta, etc) of hardware and are using an android phone.  I am going to open a full bug report as I don' t know how else to troubleshoot this.

     any ideas?

  • in reply to sabeard

    Just to make sure everything is the same between the widget and app, have you tried changing the app type in manifest from widget to watch app? (or start with the watch app and make it a widget)

    Maybe something in jungles?

  • in reply to jim_m_58

    Jim, I did check that.  The part that is most confusing is that version of the widget in the store behaves differently on the F6 than on the F5+ on the same phone.  Every instance the F6 family of devices the on device println show that it is not receiving the response but the F5+ does.

  • in reply to sabeard

    My WU weather widget runs fine and does makeWebRequests on an F6 (non pro)

    https://apps.garmin.com/en-US/apps/f509fc4e-7f1f-48a5-b337-ed86668c5f6c

  • in reply to jim_m_58

    Your widget works fine on my watch too.  I don't understand what can cause one app to work, but another to get blocked.  

    Can you test this widget your F6?  On a brand new install the trial window is set for 24 hours until it reaches the registration server.  The server will send back the end date of the 21 day trial and the onrecieve method will update the expiration date with the new date.  When the widget loads the radar image, if the trial shows as oner in a couple days then the watch did not get the response from the server.

    https://apps.garmin.com/en-US/apps/9c692f27-57d6-4488-91ae-5dd846a4ad26

    My new radar app is literally a duplicate of the widget with the manifest updated to be an app and to change the appid.  The head scratcher is I have not experienced any of the same issues with the app version.  I would love to find a code issue, but don't get how the just the manifest changes would have the impact I am seeing.

    I appreciate the discussion.

  • in reply to sabeard

    Looks to me your widget is working fine on the f6 (non pro) with the 19.75 beta FW.  I tried a few different zoom levels and switched  to rain viewer as a source and back to Aeris. All seems fine.

  • in reply to jim_m_58

    Jim, thanks for your help offline.  It appears the F6 works fine as does my F5+.  I went back and looked at all my reported problems and they are either of F6Pro devices or Tactix Delta, which is basically a F6XPro device.  So far the only thing I can find common is they are all Pro devices, using GCM Android version 4.48 or 4.47.2.  IT does not make sense to me the same store version works 100% on one device, but on another makeWebRequests get blocked, but makeImageRequest work fine.  <confused>me</confused>

  • A little update.  Now going on 3 months trying to troubleshoot this issue.  I have now had 13 reports of F6 pro family of devices (Tactix Delta, Quatix 6, F6XPro, F6Pro, F6s pro solar) being affected by this bug.  The other thing besides being based on the F6pro device running FW 19.20 and above is the users all appear to be Android users running GCM version 4.47.2 through 4.49.1.  I am seeing this on my own watch and phone so I know it is still occurring.  The easy way to tell is when you install the widget on the device, the expiration date for the trial will be 2 days until it successfully communicates with the server then it will be "set" to 21 days from the first run.  The new date is returned to the watch in the server response.  No response, no expiration date update.

  • in reply to sabeard

    So probably problem is in widget - check memory in glance mode there is only 32768, and if you divide app to (:glance) annotate well code.

  • in reply to _psx_

    I appreciate the idea, however it is not a glance memory problem.  The only code run in glance mode is to display the widget name and that only uses 9.9kb, and is properly annotated. 

    The makeWebRequest only runs once the full widget view is started, and the code runs properly on all the F6Pro devices in the simulator.  On a real device, however the onRecieve method never gets called based on my beta build where I have enabled debug println logging.

    If it was a code issue, then I would expect it to occur on all F6pro devices and not just those connected to GCM android.  Unfortunately I don't have an IOS device to test with to confirm that IOS is not affected, but so far only Android users have reported the problem.  An it is really odd that the same code works fine on other devices (F5+) connected with the same phone and GCM version.

    I just don't know if this is a FW issue, GCM issue, or CIQ SDK build issue.  The release where things started was built with SDK 4.0.5, but I have seen the same issue with a beta build using SDK 4.0.7.  The last build that I know work was compiled with either 4.0.1 or 3.2.5.  I may try a beta build with one of those to see if it works properly.