ScaleBun
Book a Demo
Skip to article

Session

react-nativeDeveloperv0.1.0-alpha.4

The ScaleBun.session namespace — 5 members.

Updated Reviewed

Unified Session namespace. Provides access to the unified SessionManager. Sessions auto-start on desktop connect.

TypeScript
import ScaleBun from '@scalebun/react-native';
ScaleBun.session.<method>(…);

Members#

MemberSignature
isActiveisActive: boolean
currentSessionIdcurrentSessionId: string | null
startstart(metadata?: Record<string, unknown>): boolean
endend(reason?: 'ended' | 'timeout'): boolean
emitEventemitEvent(type: string, data?: Record<string, unknown>)

Reference#

isActive#

TypeScript
ScaleBun.session.isActive: boolean

currentSessionId#

TypeScript
ScaleBun.session.currentSessionId: string | null

start#

TypeScript
ScaleBun.session.start(metadata?: Record<string, unknown>): boolean

end#

TypeScript
ScaleBun.session.end(reason?: 'ended' | 'timeout'): boolean

emitEvent#

TypeScript
ScaleBun.session.emitEvent(type: string, data?: Record<string, unknown>)

Notes#

The session namespace controls session boundaries explicitly. Most apps never need it — the SDK opens and closes sessions on foreground and background automatically, and that default is right for nearly every product.

startSession and stopSession return a boolean indicating whether the state actually changed, so calling startSession while a session is already open returns false rather than nesting or restarting.

When explicit control is genuinely needed#

A user switch. An app where one device serves several people — a shared tablet, a kiosk, a point-of-sale terminal — must not attribute the next person's activity to the previous one. Stop the session, clearUser(), then start a new one.

A background task that should not count as usage. A sync or a scheduled job that wakes the app would otherwise register as a session with no human in it, inflating session counts and destroying average-duration metrics.

stopSession takes a reason of 'ended' or 'timeout', which is worth setting accurately — it is how a deliberate close is distinguished from an abandoned one in session reporting.

Ordering#

  1. Do not call these before init()

    There is no session machinery yet, and the return value will tell you nothing useful.

  2. Stop before you clear the user, not after

    stopSession() then clearUser(). Reversed, the closing session's final moments are attributed to nobody.

  3. Check the return value

    false means the state was already what you asked for. That is usually a sign your own lifecycle handling is firing twice.

Limits and edge cases#

  • Session duration underpins several dashboard metrics. Fragmenting sessions changes stickiness, average duration, and anything computed per session.

  • newSession() on the events namespace is a related but distinct call — see events.

  • These calls do not throw and fail silently in release builds, so the boolean return is the only signal you get.

Related#