Trading Strategy Start/Stop in Mobile App
It seems that bot start/stop is just one button. Actually it's a sequence of actions with confirmations, state checks, and edge case handling. Press "Stop" while there are open positions—what should happen? Close positions? Wait for natural closure? Just stop new orders?
Bot States and Transitions
A trading bot is an FSM. Minimal set of states:
- STOPPED—bot is not running, no positions
- STARTING—initialization in progress (exchange connection, state loading)
- RUNNING—actively trading
- STOPPING—received stop command, waiting for current cycle to finish
- ERROR—error (invalid API key, insufficient funds, exchange unavailable)
Mobile UI should reflect each state and block incompatible actions:
// iOS, SwiftUI
struct BotControlView: View {
@ObservedObject var viewModel: BotControlViewModel
var body: some View {
VStack(spacing: 16) {
StatusBadge(status: viewModel.bot.status)
switch viewModel.bot.status {
case .stopped:
Button("Start") { viewModel.start() }
.buttonStyle(.primary)
case .running:
Button("Stop") { viewModel.showStopDialog = true }
.buttonStyle(.destructive)
case .starting, .stopping:
HStack {
ProgressView()
Text(viewModel.bot.status == .starting ? "Starting..." : "Stopping...")
}
.foregroundColor(.secondary)
case .error(let message):
VStack {
Label(message, systemImage: "exclamationmark.triangle")
.foregroundColor(.red)
Button("Restart") { viewModel.start() }
}
}
}
.confirmationDialog("Stop bot?", isPresented: $viewModel.showStopDialog) {
Button("Stop and close positions", role: .destructive) {
viewModel.stop(closePositions: true)
}
Button("Stop without closing") {
viewModel.stop(closePositions: false)
}
Button("Cancel", role: .cancel) {}
}
}
}
confirmationDialog on iOS—native action sheet. User explicitly chooses stop behavior.
Optimistic vs. Real Status
When user presses "Start", button should immediately move to STARTING, not wait for server response. But real status comes from server. Two sources of truth conflict.
Solution: set local pendingStatus optimistically, simultaneously send request. On server response—replace local status with server status. If request fails—revert local status and show error.
// Android, ViewModel
fun start() {
_uiState.update { it.copy(localStatus = BotStatus.STARTING) }
viewModelScope.launch {
runCatching { repository.startBot(botId) }
.onSuccess { serverBot -> _uiState.update { it.copy(bot = serverBot, localStatus = null) } }
.onFailure { err ->
_uiState.update { it.copy(localStatus = null, error = err.message) }
}
}
}
Multi-strategy Bot
If bot supports multiple strategies, start/stop—separate for each. List of strategies with individual toggle switches and aggregated bot status on top. Toggle for specific strategy sends PATCH /bots/{id}/strategies/{strategyId} with {active: true/false}.
Important: changing strategy activity and stopping bot—different operations. Deactivating strategy removes it from trading, but bot continues with remaining ones.
Push Notifications on Status Change
When bot transitions to ERROR or auto-stops (for example, daily loss limit reached)—push via FCM/APNs. User should know without opening app.
On backend: after each status change, publish event to queue, worker sends push. Mobile app registers FCM token on login and updates on every app launch.
What's Included
- Bot control component with all status display
- Confirmation dialog with stop mode selection
- Optimistic status update
- Individual strategy management (if applicable)
- Push notifications on auto status changes
Timeline
3–5 business days depending on number of strategies and FSM complexity. Cost is calculated individually after requirements analysis.