Internet Fridge: The Outside World

In Part I of this series, I stuck a cheap Android tablet to my fridge with fridge magnets. In Part II, I talked a little bit about Blazor and what makes a progressive web application. In Part III, I’m going to add an API that will let the fridge talk to the Internet safely.

The Internet Fridge is all about living in the future. The future comes in different sizes. Kitchen computers have been the dream for fifty years, but when I get up in the morning, the future I’m interested in is, “Is it going to rain today?”

This is a big step up from the Honeywell kitchen computer that inspired this project. It didn’t have an internet connection, mainly because the internet only had four nodes in 1969. None of them were fridges.

The Blazor sample app we started with comes with a tiny nonsense weather page. We can improve on that with some real data from

Continue reading “Internet Fridge: The Outside World”

Progressive Fridge Applications

In Part I of this series, dreaming of the Honeywell H316 Pedestal Kitchen Computer, I stuck a cheap Android tablet to my fridge with fridge magnets, a hot glue gun, and a passing reference to Stewart Brand’s idea of “shearing layers.” That’s the hardware architecture sorted. In Part II, I’m going to put some software on it.

Progressive Fridge Applications

In the olden days, like 1969, if you wanted to program the H316 in your kitchen, you had to learn FORTRAN IV and punch it into a teletype. The Model 33 teletype used ASCII so that several other machines could understand it, and some H316s were plugged into the early Arpanet, but the dream of true interoperability still had a way to go.

Even in the not-quite-as-olden days, if you wanted to write an app for your Android tablet, you had to learn a bunch of Android-specific jibber-jabber. But not now. These days, I can write C# and run it as a progressive web application, on a .NET runtime compiled for WebAssembly, running in a browser, on a tablet, on my fridge. Things have never been better!

Continue reading “Progressive Fridge Applications”

Geolocation II: Position Updates

In the previous post, Geolocation in Blazor, I started wrapping the browser’s Geolocation API in a Blazor component. That first article showed how to get the device’s current position, including how to get prototype-based JavaScript objects back across the C#/JS interop boundary.

In this post, I’ll look at using a JavaScript callback to raise a C# event when the device moves.


Continue reading “Geolocation II: Position Updates”

Geolocation in Blazor

One of the joys of Blazor is never having to use JavaScript again. With C# running in WebAssembly, events like button clicks can be handled by handlers written in C# and old dogs don’t have to learn new tricks.

There are some browser capabilities that aren’t exposed and these need JavaScript interop. The first of the browser Web APIs that I wanted to use in a Blazor app was the Geolocation API. This gives us the position of the device, among other things.

The goal of this project is to create a component that encapsulates the JavaScript interop malarkey. I want to create a Geolocation service that a host application can call to get its position using only C#.


Continue reading “Geolocation in Blazor”

Slippy Maps in Blazor with Leaflet

Note: Updated November 2020 for .NET 5 and a good, hard refactoring. See the JavaScript References in .NET 5 section below for the bulk of the changes.

Wouldn’t it be nice to have interactive slippy maps in a Blazor application? Yes, it would!

Wouldn’t it be even nicer if the map component completely encapsulated all of the JavaScript interop and the page it was on was blissfully unaware that JavaScript even existed? Yes, yes, yes!

The hard work has already been by Leaflet.js. All that remains is to write a simple Blazor component to talk to the Leaflet API. (You can download my Darnton.Blazor.Leaflet NuGet package.)

Continue reading “Slippy Maps in Blazor with Leaflet”

Internet Fridge: Living the Dream

Forget flying cars; the Internet fridge is the future and has been for fifty years.

Last year there was a lot of fuss over the 50th anniversary of the Apollo moon landings, but 1969 was also the year of the Honeywell H316 Pedestal Kitchen Computer.

The Apollo Guidance Computer was celebrated, with its source code released on GitHub and a training course on Pluralsight. All this despite selling only eleven copies.

The H316 was much more practical, used for storing recipes rather than landing on the moon, which hardly anyone needs to do. The AGC’s users were military test pilots with years of training; a ’60s domestic goddess could learn to add recipes to the H316 in just two weeks. The kitchen computer cost only $10,000 — $399,999,990,000 cheaper than the Apollo project.

Even with all these advantages, the H316 Pedestal sold eleven fewer copies than the Apollo Guidance Computer.

In 1969, landing on the moon was real. Having a computer full of recipes in the kitchen was a pipe-dream. Today, we no longer have the technology to get to the moon but the dream of the kitchen computer is within reach!

Smart is Dumb

The H316 sold zero units and most recent efforts deserve the same fate. Internet fridges appear regularly on @internetofshit’s Twitter feed. Peak Internet fridge was reached in 2016, a moment documented on Tumblr by Fuck Yeah, Internet Fridge.

If your dumb fridge is cluttered with drawings from kindergarten that don’t fit your fancy decor, a smart fridge with Google Calendar on it may seem like the answer – until Google changes their API and Samsung doesn’t update the fridge. Like your kid’s finger painting, it won’t be very good but you’ll feel bad throwing it away.

Smart fridges come with all the normal problems of internet-connected devices: buggy, outdated software; susceptibility to hijack by Russian mafiya botnets, the constant need to turn them off and turn them back on again. All this combined with the serious expense of a major household item.

For $6,000 you get a screen on the front of the fridge that saves you from opening the door. For an extra $20 you can get the App Enabled Smart Egg Tray and check how many eggs you’ve got while you’re on the bus.

The Internet fridge remains the North Star of the connected home, but so far it only solves problems that don’t exist. No one’s come up with a good reason to own such a whizzbang gizmo.

How Many Bulldozers Does It Take To Change a Lightbulb?

The reason internet fridges are a bad idea was explained by Stewart Brand in 1994, the same year I found out what the internet was.

His book, How Buildings Learn: What Happens After They’re Built, popularised the idea of “shearing layers”.

Buildings have parts that change at different rates. The site is permanent. The structural parts of buildings last from decades to centuries. The roof and cladding may last a few decades; wiring and plumbing something similar. The layout changes more often, and the “stuff” in the building changes constantly.

In a good building, the layers that change more frequently can be changed without tearing apart the other layers. In other words, you don’t need to bulldoze your house every time you change a lightbulb.

The specific application to buildings can be sheared away from this story, leaving Brand’s core idea of layers that change at different rates – which brings us back to internet fridges.

Fridges are great. The internet is great. Internet fridges are stupid. The reason is that the fridge layer, which should last 20 years, is strongly coupled to the crappy-Android-tablet layer, which will last two years. I bought my fridge in 2006 and it still works perfectly. If it had the PC I bought in 2006 bolted to the front of it, I would cry a little bit every time I got a beer.

What we need is a shearing layer. In software I would define an interface. A fridge’s interface is a big steel door and the clients of that interface are fridge magnets.

The $100 Internet Fridge

Snarky articles note that instead of spending $6,000 on something that will only last two years, you’d be better off nailing an iPad to your fridge. So I did almost that.

I bought a cheap Android tablet, glued some fridge magnets to the back and stuck that on my fridge. Having spent just $100 on it, I can use it without guilt for trivial tasks like timing eggs. No need to add pointless features like push notifications when the pesto hits its use-by date.

I can also write my own software for it, living the dream of the original 1969 kitchen computer, having an electronic brain full of recipes just where I need it.

In the next part, I’ll start on the software…

3D Blazor with Babylon

Babylon is a good choice for 3D graphics on the web. Anything that you can do in JavaScript you can do in Blazor, so I’m going to put some 3D in my web app using C#.

First, I’m going to create a Babylon component that I can drop onto a Blazor page and then I’m going to see if I can shift all the Babylon manipulation up from Javascript into C# with a full Babylon interop layer.

Continue reading “3D Blazor with Babylon”

How to Build a CORS Proxy for Client-side Blazor

Blazor is a godsend for C# developers who want to build web applications. I’ve found building web apps in Blazor quick and easy, but there are a couple of fish-hooks that could catch you out. CORS is one.

[Update 10th January 2021: For a real-life example using CORS, see the API section (The Outside World) of my Internet Fridge project.]

I had a server-side app that was working fine. Turning a server-side Blazor app into a client-side Blazor app is mostly painless, but this time nothing worked.

The app was making a call to an API but from the client-side version of the app, all the calls failed. They’d been blocked by the browser’s CORS policy.

The answer was to build a CORS proxy. Here’s what I did.

Continue reading “How to Build a CORS Proxy for Client-side Blazor”