Tagged
37 posts · page 1 of 4
BLE Hubs got two phones talking with nothing but Bluetooth between them. But Bluetooth is short, slow and stuck in one room. So I taught the same hub to speak Wi-Fi too: one hub, one contract, one discovery list, BLE and Wi-Fi players in the same game, Wi-Fi drops that resume without anyone noticing, and a hub you can reach from across the internet.
Nearly every app I've worked on eventually had to move a file while nobody was looking at the screen. Shiny.Net.Http has been doing that job since 2016 - background uploads and downloads on every platform, a queue that survives restarts, retries, pause/resume, and progress you can bind to a UI or put on the Lock Screen.
Two phones in the same room, no server, no Wi-Fi, and nothing but Bluetooth between them. That should be easy, and it has never been. So I took the SignalR hub model and put it on the radio: one C# interface, generated proxies, request/response, streaming, events, groups and JSON, with every byte chunked, framed and reassembled for you.
Apple and Google both want assistants to act inside your app, and they picked completely different ways to do it: Swift App Intents on one side, Kotlin AppFunctions on the other. I didn't want to write the same feature twice in two languages I don't ship in, so I built a source generator that writes both from one C# declaration.
A web app inside a .NET MAUI app, served from the device, updated from your own signed server whenever you like, and talking to GPS, Bluetooth, Wi-Fi, the camera and more through typed C# and TypeScript clients. Background jobs, pushes and geofences reach the page, or a background script when no page is open. Hot reload runs inside the real app, and a terminal simulator stands in for the device so you can test Wi-Fi drops, denied permissions and GPS walks from a browser.
Four Office editors, a free-form notebook, ribbons on everything, Find across all of them, presenting mode for decks, and a camera you call instead of a screen you build. All of it in the box, on .NET MAUI and Blazor, no WebViews.
Somebody is waiting on bytes that were supposed to have arrived. Usually nothing was carrying them — HttpClient stops the second iOS suspends your app, and Android will reclaim the process while you are not looking. Shiny.Net.Http hands the bytes to the platform instead — NSURLSession, a foreground service, a connectivity-driven managed loop, Service Worker Background Sync — under one API. Plus why I sign Azure Blob and S3 uploads by hand instead of taking the vendor SDKs, what the Android service does when the network drops, and why a Live Activity has to animate a time range instead of a percentage.
DocumentDb runs on ten-odd backends, but picking one used to be a line of C# inside your service. The Aspire integration moves that decision into the AppHost — the consuming code becomes one provider-agnostic line with health checks and OpenTelemetry attached, the admin UI becomes a resource, and an entire Orleans silo points at the same store.
Membership, grain storage, reminders, grain directory and streams are five separate provider contracts. Shiny.DocumentDb.Orleans implements all five on one IDocumentStore — one connection string, grain state you can query without waking a grain, and a stream backlog you can actually open and look at.
A seekable keyframe engine for .NET MAUI with CSS @keyframes semantics in XAML, 42 motion icons compiled from one spec into a drawn scene on MAUI and real CSS keyframes on Blazor, and a ShinyButton that finally makes press-wait-see-if-it-worked a one-liner.
Sixty-odd controls, one token contract, two renderers, zero WebViews. Shiny Controls hits 1.0 for .NET MAUI and Blazor — and there is a live playground you can click through before you install anything.
Thirteen major versions in, there's a lot of DocumentDb that shipped in a bullet list and never got explained. A store that diffs documents for you, a read path that never deserializes, and an extensibility surface that soft delete is entirely built out of.
