You’ve got advertising, scanning, and a connection that moves data working. The next question is how the device should behave over time. Should it stay connected whenever it can, or connect only when there’s something to exchange?
There’s no default answer, and staying connected is rarely as free as it looks. Two devices that sleep to save power, drift in and out of range, and share the 2.4 GHz band with everything else nearby pay for an always-open link in battery, in platform friction, and in who else can reach the device. What you’re really deciding is when the peripheral advertises, when the central asks to connect, and whether and how the connection ends.
Almost all of that follows from one question, so that’s where to start.
Which side should decide when to connect?
Before you pick a behavior, figure out who owns the decision to move data. The peripheral, the central, or both. Once you know that, the right behavior mostly picks itself, and most designs land in one of three shapes.
Staying connected all the time
If you want both devices ready to talk at any moment, the peripheral advertises whenever it isn’t connected and the central always scans and reconnects the moment they’re in range. It’s the most responsive setup and the default people reach for. It also costs the most. It burns power, it can force a persistent notification on Android, and a peripheral tied up in one connection is harder for other centrals to reach. More on each below.
Advertising only when the peripheral has data
If the peripheral is the only side that knows when data needs to move, let it drive. Keep the central scanning, and have the peripheral advertise only when it has something to say. A button press or an accelerometer event wakes it from sleep, it advertises, the scanning central connects, it reports what happened, disconnects, and goes back to sleep. Most of the time it’s doing nothing, which is exactly what you want on a coin cell.
Connecting only when the app needs it
When the central is the one that knows when data needs to move, flip it. The peripheral stays available by advertising, and the central decides when to connect and whether to hold on or drop after the exchange. On a phone this is the usual pattern. The OS does some background scanning, but it won’t connect unless your app asks (or the peripheral implements the HID GATT profile, a separate story). The user opens your app, it connects, you sync data up or push a setting down, and the app closes the connection when it’s done.
When both sides drive
When the phone and the device both need to send data on their own schedules, you’re back to staying connected. A smartwatch is the classic case. The phone forwards notifications to the watch while backgrounded, and starting a workout on the watch kicks off GPS on the phone. Neither side can predict the other, so they keep the line open. Those are the four shapes. Choosing between them is a question of tradeoffs.
Weighing power, latency, and platform behavior
Power and latency are the first tradeoffs to weigh, and they pull in opposite directions. Platform behavior, multi-central access, and reconnection efficiency shape the rest.
Power consumption and battery life
From the peripheral’s side, power is usually what rules out staying connected. If your device exchanges data only now and then, and nothing breaks when it arrives a second late, there’s no reason to spend battery advertising or holding a connection around the clock. Wake on a button press or an internal event, do the work, sleep.
Two things worth knowing. Advertising slowly and holding a connection with a long interval land in roughly the same power ballpark, so if the device has to stay reachable, holding the connection is often the better trade since you skip the reconnection delay. And if BLE is only a small slice of your total power budget, squeezing it may not be worth the effort. The parameter math lives in our guide on choosing BLE parameters, and you don’t need it to make this call.
Latency and how fast data gets through
Latency runs the opposite way from power. While connected, either side can fire off data and it lands quickly. Connecting from scratch isn’t instant. How long a scanning central takes to catch an advertisement is probabilistic and can stretch to several seconds. So if you need data fast right after an event, be already connected. Faster means more radio on, and more radio on means more battery.
Background BLE on Android and iOS
This one’s mobile-specific, and it’s why “just stay connected” isn’t free on a phone. On Android, keeping a scan or connection alive while backgrounded means running a Foreground Service, which puts a persistent notification in the drawer. If your app must talk to the device while closed, there’s no way around it. If it can wait until the app is open, do that, and give the device a quick advertising interval so it connects promptly when someone opens the app. iOS is lighter. Core Bluetooth wakes your app for a short window on a BLE event and will even relaunch one the system had cleared from memory.
Connecting to multiple centrals
With one device and one phone, staying connected is easy to justify. Once several centrals need access, it gets in the way. A peripheral can hold multiple connections, but that adds complexity around connection limits, bonds, and multiple data sources, and it has to keep advertising the whole time it accepts more. Allow only one connection and you can stop advertising once connected, which is simpler and easier on the battery, but whoever connects first holds the device until they let go. If you want that simplicity and still need to serve several centrals, connect only when there’s work to do so they can take turns.
Avoiding reconnection loops
One trap to design around. It’s easy to fall into a loop where the peripheral disconnects, immediately re-advertises, the central reconnects at once, they do a tiny exchange, disconnect, and start over. That churn wastes power on both ends. After an intentional disconnect, put a little space in, either the peripheral holds off before advertising or the central holds off before scanning.
Settle those tradeoffs and you’ve got your behavior. One question is left, which is who gets to connect at all.
Controlling who can connect to your device
How you advertise also decides who gets to reach the device. Advertisements are visible to anyone within earshot, and by default any central that hears one can connect.
Limiting connections with a Filter Accept List
Advertising announces your peripheral to the neighborhood, so any central that hears it can ask to connect. Stopping advertising once connected isn’t automatically safe, since another device might grab the connection before the one you wanted, and even after you disconnect, the same or a different central can reconnect and lock your intended one out. Bonding won’t stop this, because BLE security kicks in after a connection exists. Bonding keeps an unauthorized device from interacting with your application, but it still connects.
A Filter Accept List does stop it. Authenticate a central once, add it to the list, and the peripheral ignores connection requests from anything not on it. You’ll need a way to get a device onto the list first, usually a temporary open mode or an out-of-band address exchange. It isn’t a security feature on its own, since an address can be spoofed, so treat it as a way to keep the wrong devices from connecting and lean on real security for the rest.
Advertising privacy and LE Privacy
Advertisements go out in plaintext, so treat them as public. Never put anything sensitive in one, and remember a peripheral advertising a fixed address can be tracked. LE Privacy helps by rotating the advertising address on an interval, which makes tracking harder. Just don’t undo it by leaving some other fixed, identifying value in the advertisement, since that hands the tracker the same handle it was missing.
Choosing your connection strategy
There’s no single right answer here. What matters is making the call on purpose, from who needs to talk and when, rather than defaulting to always-connected because it’s the first thing that works on the bench.
Once you know when your device should be connected, the next move is turning that into timing, which is the job of advertising and connection parameters. Our guide on choosing those parameters picks up right there. And if this is more of a product decision than an implementation one, Always-Connected vs. Dynamic BLE frames the same question around the tradeoffs that matter to the team shipping the device.
