SocarFrame - Bluetooth Module

Control of Socar, Elecle, and Ddareungi is possible because the terminal inside each mobility device exchanges data with the app. Socar splits this communication into two paths—server and Bluetooth—while prioritizing the more reliable Bluetooth.

Platform APIs don't fully capture device context, and the behavioral differences between iOS and Android are significant. In particular, iOS's scanForPeripherals(withServices:options:) does not allow additional scans while scanning is in progress, whereas Android's startScan(filters, settings, callback) does allow this. To resolve this, SocarFrame introduces a virtual scan manager that merges multiple scan requests into one.

The core structure consists of BluetoothHost and BluetoothRemote.

• BluetoothHost: Manages the list of remotes and controls lifecycle callbacks for creation, connection, and termination.
• BluetoothRemote: An object that abstracts an actual Bluetooth device, encapsulating device-specific routines.
• BluetoothSpec: Holds static identity such as CarID, BikeID, and UUID.
• BluetoothHandle: Holds dynamic behavior that can change, such as aliveMessage and issueCommands.

Thanks to this structure, app developers don't need to worry about scanning, connecting, reconnecting, error handling, or protocol branching—they only need to express intent, such as "send a door-open command." Handling based on device type is hidden inside the module, minimizing changes to existing code when new devices are added.

In the example pseudocode, if only platform code is used, each device type requires a switch to branch the connection routine, command transmission method, response parsing, and error policy. In contrast, with SocarFrame, you can register a BluetoothHandle and control it through a consistent flow like bluetoothHost.checkIsConnected(...).getBluetoothRemote().request(...).

The value this architecture provides can be summarized into 5 points.

• Horizontal/vertical scalability: Adding a new Bluetooth device only requires adding an implementation, without modifying the existing BluetoothHost.
• Separation of infrastructure and business logic: The app can issue commands without knowing hardware complexity.
• Business flexibility: iOS and Android share the same structure, making it easier to respond to requirements and estimate schedules.
• Testability: Reduced hardware dependency makes Mock testing and exception-case verification easier.
• Open-source potential: Separating BluetoothCore and BluetoothCommon creates room to open up the core platform logic externally.

Ultimately, SocarFrame adds a layer of abstraction on top of fragmented platform Bluetooth APIs, enabling various mobility types like cars, bicycles, and kickboards to be handled in the same way. As a result, the app team can focus on service intent and scalability instead of low-level communication implementation.