SDK Features
Debugging
The SDK is designed to be as silent as possible and use very few resources. You will therefore not get much information by default in your development console.
We have 2 different debug log types that can be enabled / disabled (at any time):
- info log
- verbose log
Info log
Short messages will be output when enabled explaining when some action is being performed by the SDK. Sometimes cropping text / values to make it more readable.
Enable info log when implementing the SDK – remember to turn it off in production!
ga_setEnabledInfoLog(true);
Example output:
Info/GameAnalytics: Add DESIGN event: {eventId:someEvent, value:0}
Info/GameAnalytics: Add DESIGN event: {eventId:someOtherEvent, value:100}
Info/GameAnalytics: Add ERROR event: {severity:info, message:This is some in}
Verbose Log
Console output when each event is added (all fields) in JSON string format. This is the data being submitted to the GA servers for each event.
Enable verbose log when troubleshooting events.
ga_setEnabledVerboseLog(true);
This can result in a lot of text. When troubleshooting/debugging events it is therefore recommended to enable/disable when performing the action that need inspection.
Troubleshooting example
// enable verbose log
ga_setEnabledVerboseLog(true);
// add event you need to troubleshoot / inspect
ga_addDesignEvent("Some:Event", 100);
// disable verbose log
ga_setEnabledVerboseLog(false);
Verify Implementation
Enable the Info Log to verify that events are being sent from your game project without any issues being reported.
Events submitted should register after a minor delay in our realtime dashboard in the GameAnalytics tool.
Session Handling
Sessions are the concept of a user spending focused time in your game – from game launch to the user leaving the game.
On Android a new session will start once the game is launched (or when the app is “resuming”). A session will end once the game is going to homescreen (or is not visible anymore).
On iOS a new session will start once the game is launched (or when the app is “going to foreground”). A session will end once the game is “going to background”.
Session start
Generates a new session. Adds a session start event (a user event)and starts the periodic activation of submitting queued events. Next event submit will fix potential missing session_end from earlier sessions.
Session end
Stops the periodic activation of submitting queued events. Adds a session_end event and submits all queued events.
Exiting the application
NB: only needed for desktop platforms.
To ensure the background thread of the SDK will not continue running after the application has closed you need to call during a “Game end” event:
ga_onQuit();
Event Queue
Whenever an event is added (and validated) it will be added to a local database queue.
Interval
Every 8 seconds the SDK will start a task for submitting queued events since last submit. This processing is done in a separate low-priority thread that will have minimum impact on performance. The payload is gzipped and will therefore only consume a small amount of bandwidth.
Offline
When a device is offline the events are still added to the queue. When the device is online it will submit.
Thread Handling
Almost every piece of this code is run using a dedicated low-priority serial thread queue to avoid UI lag or sudden performance spikes.
The queue will execute each task sequentially. If the SDK add several tasks to the queue then each will be executed in turn. A task could be adding an event or submitting all queued events. Consider this example with 3 calls.
// Configure build version
ga_configureBuild("alpha 0.1.0");
// Initialize
ga_initialize(
"12341234123412341234123412341234",
"1234123412341234123412341234123412341234"
);
// Add Design event
ga_addDesignEvent("Some:Event");
The configureBuild is required to be called before initialize is completely finished. The design event call is required after initialize is finished. The queuing will make sure that each task is completely finished before proceeding to the next one.