Hi, I wanted to use Unity Analytics in certain scenarios. For that Service Environments seem to be right fit for it
https://docs.unity.com/ugs/en-us/manual/overview/manual/service-environments
// Use 'test' as new environment
InitializationOptions options = new InitializationOptions().SetEnvironmentName("test");
await UnityServices.InitializeAsync(options);
// However in log I see different environment name which is set in Player settings
Debug.Log(EnvironmentsApi.Instance.ActiveEnvironmentName);
So InitializationOptions.SetEnvironmentName seems not to do what I expect. Or I don’t understand this method. In fact, I can set any string name here which has no equivalent in Cloud Dashboard and Unity still will not complain. I would expect an error message here, something like “Environment does not exist”
Also, I wanted to use EnvironmentsApi to print current set environment name directly in UI to make sure the right one is used. But as stated in code above, it only prints the value from Player settings. Furthermore, this class is in Editor namespace (why?). So building the project I get
error CS0234: The type or namespace name 'Editor' does not exist in the namespace 'Unity.Services.Core' (are you missing an assembly reference?)
So apparently I’m only supposed to use EnvironmentsApi in Unity Editor only. But how can I then determine the environment used in standalone build then?
Did you check the console for errors? Are you try/catch’ing exceptions but neither logging nor re-throwing them? (Note: try/catch all service calls is mandatory, not optional! Any of these calls may fail at any point in time because at the most fundamental level, the Internet is not a perfectly reliable service.)
Are you sure the code executes? Are you testing the code execution in playmode (ie not an editor script)?
That’s odd. Perhaps you accidentally used a similar editor-only API that is only intended for editor functionality, like said project settings.
Did you check the console for errors?
Of course, when I write “I would expect an error message here”
Note: try/catch all service calls is mandatory, not optional!
How this? All errors are logged by default, i.e. written in Player.log as well as shown in the console. At least, what I expect as default behavior. But good, I encapsulated it in try and logged error in Debug.LogError (tbh, unnecessary code clutter xD). As expected, no error is reported when I use an undefined environment name.
But I have tested Analytics reporting anyway. So InitializationOptions().SetEnvironmentName is actually used and I get events in that environment. Just tried to first report events into a non-existing environment and then create that environment. But no events to be found as expected. You just don’t get any error messaging.
That’s odd. Perhaps you accidentally used a similar editor-only API that is only intended for editor functionality, like said project settings.
I only see what is documented
https://docs.unity.com/ugs/en-us/manual/overview/manual/environments-api
So my wild guess is EnvironmentsApi is supposed only let you view what is set in Project Settings, not what is actually used by let’s say Analytics package. As I said, I tested it. Would be better to have a clear note in the docs.
So for my case will then just store the env name put into InitializationOptions manually, so that is fine by me.
Logged yes, but not handled. These aren’t errors, they are indications that you may have to change application state and respond accordingly, even inform the user and disallow certain functionality.
Assume you want to “save player data” to the cloud. The call to saving the player data throws an exception because of a loss of Internet service.
If you don’t try/catch the exception or don’t do anything in the catch part (ignore exception), the Application state is undefined. User is most likely unaware that progress wasn’t saved, and so is your application. It may even consider the state saved and lets the player start a new session without asking “do you want to save your progress?” and so on.
What you’re supposed to do is to catch any exception, then notify the user “failed to save progress” and provide an option to “try again”.
This extends to all service calls. For instance, if sign in fails, you also will want to adjust the application state. Perhaps not even let the player play the game if the services are unavailable if it’s heavily relying on services.
Every service call exception is an inflection point in how your app may need to progress its state. Hence leave no service exception unhandled!
Sure, with Analytics it only affects reporting to you. But even there exceptions may skew your analytics results because, for whatever reason, you may not even receive certain analytics results leading you to believe that users don’t actually use a certain functionality. Therefore it’s common to record analytics data locally on the device and try send it later because you also want the analytics data from players who largely play offline.
1 Like
Thanks for pointing that out, even though, I was talking about missing error information in the first place.
Playing offline is an interesting concept, maybe I should handle that case. But tbh I already had hard time coming with a good consent message and writing down a whole Privacy Policy that I decided to only use this service for playtesting. If play testers like to test offline, that could be an issue, though…