This is an old revision of the document!
Before writing any code I needed to write down what I intended to build. A “product first” approach to building this application. I've spent some time writing this sort of thing in the past, so I threw something together that should pass as product direction.
I made some interesting choices while writing. After a few hours this isn't an S3 desktop application anymore. I am now targeting a subset of Azure's “Blob Storage” service.
I've never built a C# application before. Recently Microsoft started giving away a useful version of its tools for free, so that's helpful. After downloading and installing Visual Studio 2015 I'm ready to build something.
After searching the web for examples and reference material I started to “get” what XAML is all about. I went from dragging and dropping UI components onto my work area to writing the markup by hand. It seems you can make a much more deliberate-feeling UI by writing XAML and using the “stage” area for a real-time preview. I wonder if other people do it this way?
As I was establishing a rudimentary main window I started getting the urge to hook up a few of the elements to some actual code. Hiding and showing the “Accounts” and “Properties” sections of the center grid seemed like a good start. I added a main menu and some menu items I could toggle.
I realized the menu item toggles could get out of sync with the UI if the user dragged the grid splitters to their extreme positions on either side of the UI. I hooked up an extra bit of code to detect if the splitters had arrived at those positions and set the toggle accordingly.
Following the Authentication for the Azure Storage Services documentation, I sent a properly signed request and got a successful response back from the storage service.
Taming the HttpClient class was straightforward. The signature took a little while. Computing the full SharedKey scheme value looks something like:
string signature = Convert.ToBase64String(new HMACSHA256(Convert.FromBase64String(key)).ComputeHash(Encoding.UTF8.GetBytes(signatureContent)));
Read about data binding. It cuts down on a lot of icky feeling code. Started using it with ListView/GridView combinations for container and blob lists.
The authentication requirements for Azure services are cumbersome. I was able to get a second request working, but I couldn't get a request against a “service” resource type to authenticate. It would be nice if they had signature output examples with a fixed date and API key so I could verify my implementation. It's clear most people don't consume the REST API directly, opting instead for the SDK.
I relented. I am now using NuGet and the official Azure Storage SDK. I'm not happy about this because I feel like I've failed in understanding how the SharedKey signature is generated. The approach I was taking wasn't adding any real value to the customer anyway, so it's best I just move on.
Removed the accounts and properties sections from the center grid. Added a full menu and tabs across the bottom to allow access to the client activity and transfer logs.
Learned about ClickOnce installations. It seems like a ClickOnce installer per major version of the application would be appropriate. If this were an application to be used on a server or with less interaction with a 3rd-party service, I'd probably use a more traditional installer.
Thought about a company name. I've speculatively bought a few domain names already. Spent a healthy amount of time going over company beliefs. Considering documenting the formation of the company publicly. Trying to stay focused on building the application.
I'm struggling with how to organize the application code. Right now I have a set of “Models” which represent each noun I've identified (Account, Container, Blob, Activity, Transfer, etc.) and a singleton “Kernel.” I suspect a singleton approach isn't sustainable long-term, but it gets me into a position where the application is functioning and I can have friends start testing it.
I also discovered observable collections. Those should probably be used in moderation.