BLE Hubs 1.0Think SignalR for BLE!Think SignalR for BLE!Hub it up!
UniHub 1.0Universal Hubs - SignalR Styled Hub BLE or HTTP - Why not both!?Universal Hubs - SignalR Styled Hub BLE or HTTP - Why not both!?YES PLEASE!
Call Directory
The call directory bridge lets the page block calls and label callers from a list of numbers it owns. It’s built on
Shiny.Mobile.CallDirectory, which stores the list in SQLite on the device. iOS loads it
through a Call Directory extension that the build generates, with no Xcode project, and Android checks every incoming
call against it.
AddCallDirectoryBridge(o => …) takes Shiny’s CallDirectoryOptions: the default country code, and on Android whether
to block every unlisted caller and whether to post a caller-ID notification. An app that already calls
services.AddCallDirectory(…) keeps its registration. See Shiny.Mobile.CallDirectory.
An entry is { phoneNumber, label, type }. phoneNumber is the country code and digits with no + or formatting, such
as 18005550100; POST calldirectory/normalize turns a number as people write it into that form. type is:
Type
What happens
Block
The call is blocked.
Identify
The call rings with label as the caller ID. On Android, where another app can’t change the dialer’s caller ID, a notification shows the label while it rings.
Allow
Android: the call always rings, even when unlisted callers are blocked. iOS has no allow list and stores it as Identify.
PUT calldirectory/entries adds or replaces entries, POST calldirectory/entries/remove removes numbers,
POST calldirectory/entries/replace swaps the whole list in one transaction (for a sync from your server), and
DELETE calldirectory/entries clears it.
Edits are stored straight away, but iOS only sees them when the extension loads the list, which
POST calldirectory/reload asks for. Make a batch of edits, then reload once. The result says how the load went:
Success, ExtensionDisabled (the user hasn’t turned it on), CurrentlyLoading, MaximumEntriesExceeded, and so on.
Android reads the list on every call, so there a reload only reports whether screening is on.
iOS has no permission prompt: the user turns the app on under Settings › Apps › Phone › Call Blocking & Identification.
POST calldirectory/access opens Settings, as close to that page as iOS allows, and answers the current state, so check
GET calldirectory again when the app comes back to the foreground. On Android it asks for the call screening role.
iOS: whether the user turned the extension on in Settings › Apps › Phone › Call Blocking & Identification. Android: whether the app holds the call screening role.
iOS has no prompt: this opens Settings (best effort) and answers the current state, so check again when the app is back in the foreground. Android asks for the call screening role.
Turns a number as people write it into the form the directory stores: formatting and a leading + or 00 dropped, and a country code added when it has none. Fails with 400 when it is not a phone number.
iOS: whether the user turned the extension on in Settings › Apps › Phone › Call Blocking & Identification. Android: whether the app holds the call screening role.
Blocking calls is a device-level effect, so the bridge is behind the bridge policy like every other: callers on this
device only, plus the launch session. Entries are validated (a number of at most 15 digits, a label of at most 256
characters) before they reach the store. See Security.