Spreadsheet web app questions
Long ago I implemented the Google spreadsheet synchronization in my app. I start to wonder if it has ever worked, i.e. if end users really get updates made on the Google drive. In addition, I don't know how to verify if the settings are correct and I don't understand what will happen if I upgrade the web app. There are a number of questions involved in this, so I'll try to explain everything.
I believe I followed the correct procedure when I implemented the web app, but don't know how to verify that. If I I go to the script and open the publishing window, I get a very different URL than what I have in Unity right now. Do that window show the URL the app has right now or the URL it will get if it is re-published? (...don't really know what will happen if I publish an app that is already published). Do the difference in URLs mean that it has never worked? Or do I need to look somewhere else to see the current URL for the app?
If I in Unity use the Refresh button I do get a complete list of spreadsheets available on Google drive so there seems to be a connection even though my URL seems to be wrong.
The script I have implemented do not have the password parameter, so I guess it is not the latest version.
- How do I know which version I have implemented?
- How do I know which version that is the latest?
- My script is Version 5 but I have seen screen dumps on this forum with Version 5 scripts that look different (e.g. having the password parameter)
- If I use the Verify button it momentarily says that it is verifying the web service, but I get no result. Does that mean that everything is OK? If so - why doesn't it indicate that there is a newer version of the script available?
- If I Use the Install button, what will happen? Presuming that there is a newer version of the script, will it overwrite the currently published version? If so - what will happen with all current users that has an old client without any password? (...assuming that it by some reason works today)
If you get a different URL, it means the script was not the same than the one you are installing now or that the script was unpublished before.
If I I go to the script and open the publishing window, I get a very different URL than what I have in Unity right now.
Every time you publish the script and get its URL, the URL should be the same. Google Scripts allows to change the script and every redeploy is just a change to the already published service without changing the URL so that clients already using that URL can keep working.
If you don't see the password field in either Unity or the WebService, then you have an older version of them (mabe one of the old betas).
To be sure you have the latest:
- Download and install the latest I2 Localization.
- Click Install in the Google tab, so that a new copy of the WebService gets added to your Google Drive.
- That copy will have the latest v5 with the password field.
- change the password (if you want to password protect it, or leave it if you don't)
- Follow the steps again to publish the WebService.
- Paste the new URL in Unity.
- Click verify, a green checkmark should show next to the URL saying everything went fine (or a red x if there was an error)
* another way to verify that the integration works, is by importing or exporting to a Google Spreadsheet, that uses the WebService.
If I Use the Install button, what will happen?
Clicking Install in Unity, just copies the latest version of the WebService from my server and copies that to your Google Drive.
Presuming that there is a newer version of the script, will it overwrite the currently published version?
No, it will create a copy next to that one.
The old is kept, so that if your players are using the URL from that WebService, they can still access your spreadsheets.
New versions deploy to a separate URL, so your existing users will still use the old webservice.
If so - what will happen with all current users that has an old client without any password?
And given that the I2 Localization they have built into the game they are using, then, it will work fine. Once they update the game, they will have the new I2 Localization which will point to the new WebService, and so, will use the password.
Nonetheless, if the password is not changed in neither Unity and the WebService (i.e. has the default value "change_this") then, the password protection is ignored.
Hope that helps,
Everything works as expected in the Unity editor. I have updated the script URL and access to the spreadsheet is OK. But when the app runs on a device, nothing happens. I have made minor changes to the spreadsheet (that is not downloaded to Unity Editor) just to see if an update is performed when the app is installed and run. It is not updated.
I have added a call to force an update when I tap a button in the app and I catch the Event_OnSourceUpdateFromGoogle callback. Nothing happens when I call I2.Loc.LocalizationManager.Sources.Import_Google(true, false); No errors, no call back. Nothing.
I have tried with and without password. When the password is wrong I get a clear error message about this in Unity Editor, when the password i correct I have no problems in Unity Editor. Apparently the password in the app is OK (since the app is built when Unity has the correct password configured).
The web app publishing was done with anonymous access allowed. Though I don't know how to verify this...
When debugging in Unity (not on the device) I can see that Google_SpreadsheetName is wrong - I have changed the name since I otherwise had multiple spreadsheets with the same name which was confusing. When I select the I2Languages object in Unity, the spreadsheet name displayed is wrong, but as soon as I click Refresh the correct (renamed) name is displayed. If I click Open, the correct (renamed) spreadsheet is opened so it seems to have the correct reference. Still, the name when the app is run is incorrect. There is a Google_SpreadsheetKey but I don't know how to see these keys on Google drive.
I get no error messages anywhere - not in my app and not in the GSuite developer hub. How can I troubleshoot this situation?
I have trying to reproduce an issue in the Google Live Synchronization but it seems to be working fine in my devices as well.
Things to check:
- When you installed the game in your device you accepted the Internet Access permission
- When building, the Update Frequency was set to ALWAYS not DAILY or WEEKLY (as the default), otherwise you will only be albe to do a test per day/week
- There is a new setting next to the Update Frequency that defines when the update is applied after its downloaded. It can be OnSceneLoaded, Manual or AsSoonAsDownloaded.
If you have it set as OnSceneLoaded, then, it will only be applied when you start loading into a new scene (to avoid a lag/hitch while playing).
So, for testing, be sure is AsSoonAsDownloaded or that you are switching levels/scenes for testing that it works.
- If nothing seems to be working anyway, try checking the Android Console (logcat), If you are using Unity 2019.1, I think they even linked it to the Untiy Console, but in previous version you have to run the logcat separately.
In that logs there will be a line for when it start downloading, for when it finishes and for when it applies it. If it doesn't do that flow, there should be a warning saying what happened
Hope that helps,
This is rather strange I think. Obviously at least one scene must be loaded when the app is started, and in my case it is actually three scenes that are loaded in sequence during the startup. It's odd that none of these scene loads trigger OnSceneLoaded.
As I mentioned I added a call to manually trigger an update with a button in my app - that call also failed when it was set to OnSceneLoaded. Shouldn't a direct call to Import_Google() trigger an immediate download regardless of the Update Frequency setting? I kind of thought that was the purpose of that method. When I changed to AsSoonAsDownloaded , the call to Import_Google() immediately triggered a download.
When I had OnSceneLoaded and synchronization failed (at start and when calling Import_Google() ) there were no traces of any download attempt in the logcat.