Why it was needed
01Because the phone can lose internet while attached to the device over Wi-Fi, the webview and socket flow had to stay stable.
Vehicle device companion app
TalkCar
A vehicle companion product where the app receives web commands, talks to the device socket, and returns the result.
AutomotiveHardwareWebView
Automotive / Hardware
Mobile bridge for web commands, device sockets, downloads, and firmware updates.
Project overview
The product only works when the bridge between web, app, and vehicle device stays reliable.
TalkCar is a connected product that links the web, the mobile app, and a vehicle device. The app acts as a bridge: it receives commands from the webview, talks to the device, and returns results back to the web layer.
The repo shows login, a message library, downloads, firmware updates, enterprise approval, a webview bridge, and the socket protocol used to reach the device at 192.168.2.1:5050. It is a hardware companion product built around control clarity.
What I built first
02I combined a Flutter webview bridge, auth, downloads, library management, firmware updates, and the device protocol into one product flow.
Where this approach works well
03This fits control products and field connection apps where hardware, web, and mobile need to move together.
Technical details
Tech stack
App shell
Flutterhooks_riverpodget_itpackage_info_plusdevice_info_plusintl
Bridge and networking
webview_flutterhttpconnectivity_plusshared_preferencesurl_launcher
Operational integrations
api.talkcar.nettalkcar.co.kr WebView pagesS3 firmware bucketS3 message bucket
Services and tools
talkcar.co.krapi.talkcar.netAWS S3WebView bridgeConnectivity monitoring
Product surfaces
Selected screens
The screens below are the actual interfaces that defined the product experience.
Website
App
Contact
If you are considering a similar product, feel free to reach out.
A short brief, a reference link, or the current problem definition is enough. I can help structure the right first version from there.