Curious about the actual application flow?

Usage Scenarios / Checking Maintenance & Updates

Maintenance/Update

Understanding

Using the maintenance/update feature provided by the STOVE SDK, you can set or clear game-server maintenance and control updates by managing the game version.
The STOVE SDK runs inside the user's app (client). When the app launches, if maintenance is in progress or a new update is available, it shows a guidance popup to the user.
However, beyond STOVE's features, there are parts the game server must manage directly, so they need to be implemented together.

Feature Providers

The maintenance/update feature is provided with roles split between STOVE (SDK) and the game (CP company).

Cautions for Maintenance on the Mobile Platform

• Due to the nature of the mobile platform, various exceptional situations can arise for users during maintenance.
  • When the user is in a section with no server communication at the time of maintenance setup / user kick (e.g., lobby screen, during single-player)
  • When the app was sent to the background before maintenance started — situations like app in background before maintenance → app to foreground during maintenance can occur.
  • When the user is in a section where the network is physically cut off (e.g., airplane mode, subway)

• If server-based maintenance/update features are absent or not handled, the following problems can occur.
  • Some users who weren't kicked access/play the game during maintenance
  • Because resource updates are checked only at app launch, some users don't receive resource updates

• To prevent the problems above, the game server must implement the following items.
  • Game-server maintenance setup (entry blocking)
  • Server-based user-kick implementation
  • App-update version / update options
  • Resource-update version / update options

Integration Guide

Prerequisites

Basic Integration Structure

At STOVE SDK initialization (initialize), it checks maintenance/update status and automatically shows a context-appropriate guidance popup. The popup STOVE provides is a simple user-notice popup; in-game maintenance notices, user kick, input blocking, and server-level maintenance must be implemented separately by the game.

Maintenance & Update Flow

This is the full sequence in which the STOVE SDK and the game server judge maintenance/update in order when a user enters the game.

The earlier steps (①–⑤) are handled by the STOVE SDK at the platform level, and the later steps (⑥–⑨) by the game server at the game level.

This breaks down how each situation is handled when maintenance or an update actually occurs within the full flow.

This is the flow when an app (client) or resource (CDN) update exists. It covers when a user who wasn't kicked accesses the game during an update check, or when only app/resource updates are applied without maintenance.

Development

SDK Integration

When maintenance or app-update status is detected in the result of SDK initialization (initialize), call OperationUI.handleResult to show the guidance UI the SDK provides and then control the subsequent game flow.

Prerequisites

• AuthUI module dependency: OperationUI is included in the AuthUI module. Check that the AuthUI dependency is added to your project (Android build.gradle, iOS Podfile/SPM, Unity/Unreal packages).
• Partners configuration complete: configure service maintenance and update management in Partners in advance. The client receives this configuration in the initialize response and branches the screen accordingly.
• Call context: handleResult needs a live Activity (Android) / UIViewController (iOS) to show the screen. Confirm that the context hasn't been finished/dismissed at call time before calling.
• Game-server-side implementation: SDK maintenance info is returned only at the first initialize, so implement game-server entry blocking, user kick, and resource-version verification separately. (See Troubleshooting for details)

Development Flow

1. Call Auth.initialize (Android) / [SGSAuth initialize:] (iOS) / Auth.Initialize (Unity/Unreal) at game start.
2. Pass the Result (including errorCode) received in the callback as-is to OperationUI.handleResult(activity, result) { ... }.
3. OperationUI branches on errorCode and automatically shows the appropriate screen.
   • Auth.MaintenanceError (30003) → maintenance-notice screen
   • Auth.AppUpdateError (30004) → app-update-notice screen (behavior branches by mandatory/optional option)
   • Other permission/account-related errors → the corresponding notice screen (sanction, dormancy, withdrawal, etc.)
4. When the user interaction (confirm / go to update / exit app) finishes, the listener callback is called. Inside the callback, use handled.isSuccessful() to continue the game-entry flow (login → character selection → lobby).
5. If Auth.initialize itself fails for a reason other than maintenance/update (network error, etc.), implement retry logic separately.

Troubleshooting

Sample Code

using Stove.Auth;
using Stove.AuthUI;

Auth.Initialize(initRequest, (Result result) => {
    OperationUI.HandleResult(activity, result, (Result handled) => {
        if (handled.IsSuccessful()) {
            // Continue the game-entry flow (login → character selection → lobby)
        } else {
            // User chose exit/cancel → handle app exit
        }
    });
});

Frequently Asked Questions