For a long time now, my blog has been powered by WordPress and hosted on GoDaddy shared hosting.
Last week I noticed that the blog was down, and when I opened GoDaddy’s shared hosting administration area, I got a database connection error message.
I then did what anyone in this situation would do: get help!
However, contacting GoDaddy support proved completely useless, as all I got was something along the lines of “yes, there’s a problem and we’re working on to fix it; no, we don’t know when it’s gonna be fixed, so please try later”…
Just had a chat with @GoDaddy support, their server is down and all I got was "we know it's down, just try later..." #fail@GoDaddyHelp
“…the Microsoft MVP Award is our way of saying “Thanks!” to outstanding community leaders.”
This is my first MVP Awards and to me feels like the top recognition for all the work I’ve been doing for the past few years with the community around Microsoft Technologies, particularly in Windows and Windows Phone development.
I consider this award as a personal achievement, but it is one that I could not have accomplished without the help and support of some people, specifically:
Scott Lovegrove, Joost van Schaik, Glenn Versweyveld, Hermit Dave, Sébastien Lachance, Bart Lannoeye, and quite a few other distinguished MVP’s!
Alberto Silva, Sandro Pereira, Tiago Pascoal, Paulo Morgado, and other fellow Portuguese MVP’s!
Luis Calado, João Pedro Martins, Clint Rutkas, and quite a few other Microsoft employees!
my wife, Joana, who has the patience to put up with me doing “geeky” stuff all the time!
…and finally but most importantly, the whole community, who reads my blog, follows me on twitter, checks my code contributions, downloads my apps, and gives me the opportunity to carry on doing what I’ve done so far and that will continue to improve in the future!
Adaptive triggers will not work if you are trying to change a control whose instance name is the same as one of the VisualStates of any control on the page, so make sure you name your controls accordingly!
The long run…
I recently came to discover what I believe to be a UWP platform bug related to how one names the instance controls and how these may collided with the VisualState names!
Let’s take the following sample code for a simple AdaptiveTrigger usage example:
Here we can see we have a Button called “MyButton”, who’s background color will change accordingly to the window size: if the window width is above 600, the button will be green, and if it is below 600, it will be red.
Now here’s how it looks when we run the sample code:
Works exactly as expected! :)
If you take a look at the Button styles and templates, you will find out that the Button control contains the following named VisualStates: “Normal”, “PointerOver”, “Pressed”, “Disabled”.
Given this information, let’s rename our button from “MyButton” to “Pressed”:
<Buttonx:Name="Pressed"Content="I don't do anything!"/>
This is the result if you run the code again:
What you see here is that the initial state was in fact applied, but it failed to change once we started to change the window size as it was supposed to!
Further testing made me aware that this is not only influenced by the visual states of the control we are manipulating, but by all controls on the page!
As an example of this, on the following code we have now added a ComboBox control, which will also fail the adaptive changes as I named our button Focused which matches one of the ComboBox visual states:
Assuming you already installed the Windows 10 IoT in your Pi 3 and that it is currently up and connected to the network, you can open the Windows 10 IoT Core Dashboard, go to the “My Devices” tab and find your device listed there.
If you now click the “Open in Device Portal” option, the browser will launch, ask you to login with your credentials, and then show you the “Home” page of the Device Portal.
On the bottom you will find the “Display Orientation” option:
Given my touch screen is placed upside down, I changed this setting to “Landscape (Flipped)”, and after rebooting the device I noticed that it flipped the touch screen display as requested, but it didn’t also flip the touch targets (so you’ll need to mentally rotate every point you touch on the screen to make it do what it is supposed to do)!
Under the hood, what this setting is doing is adding display_rotation=2 to the Raspberry Pi “config.txt” file, but that’s not the proper way of doing this for the touch screen!
Like it or not, the so called “Hamburger” design pattern has made its way to pretty much every platform, including the Windows Universal Apps!
Most Windows 10 native apps already show this new pattern, even a classic like the Calculator app!
However, for reasons unknown, Microsoft didn’t provide any Hamburger related control on the SDK base controls… frankly, this move brings back to memory when Windows Phone 7 SDK was launched without the Panorama and Pivot controls, the foundation of the whole “Metro” design guidelines!
The only alternative I’ve found is to use the Template 10, a “set of Visual Studio project templates”!
However, I’ve found that Template 10 version for Hamburger adds a bit of too much “fat” for my own taste, hence why I’ve been working on an alternative for the past last few weeks!
Introducing the Cimbalino Toolkit Controls
Starting with version 2.2.0 (currently still in beta 1), the Cimbalino Toolkit will feature a new package called Cimbalino.Toolkit.Control, and as the name suggests, it’s a control library for app developers.
Currently, the package features 3 controls:
Starting from the top, the HamburgerFrame control is a full replacement for the native Frame root control used in the app.xaml.cs file.
The control provides 3 content containers represented by the Header, SubHeader, and Pane properties, and on the center, it will show the navigated content:
Obviously, you can specify content for this containers however you would like, or just leave them blank!
The Header allows content to be presented above the Pane, so it will never be hidden by it:
The SubHeader allows content to be presented on the right side of the Pane. This means that if the pane is in one of the “overflow” modes it will show on top of this container, hiding the content behind it:
The control also provides background properties for all these containers (HeaderBackground, SubHeaderBackground, and PaneBackground).
To make the life easier of developers, I’ve “borrowed” the VisualStateNarrowMinWidth, VisualStateNormalMinWidth, and VisualStateWideMinWidth properties from Template 10, which allow to specify the break points where the pane state and location will readjust. If you don’t want to use these, you can always do it manually with the exposed pane related properties (IsPaneOpen, DisplayMode, OpenPaneLength, CompactPaneLength, …).
The HamburgerTitleBar control provides a basic Hamburger button on the left side (can be hidden with the MenuButtonVisibility property), and a Title property.
This is a quite rudimentar and easy to use control, yet developers might want to just go ahead and create their own version of this control and place it on their apps!
Finally, the HamburgerMenuButton is the button you’ll be using in the pane to indicate the available menu options!
This control shows a left-side icon and an optional label (through the Icon and Content properties):
The regular approach here will be to just place all the HamburgerMenuButton controls inside a vertical StackPanel, but one can also stack them horizontally, and in this case, we would only show the icon and hide the label (using the provided LabelVisibility property).
The NavigationSourcePageType property allow developers to specify the destination page type for navigation purposes. If the property is set, the button will automatically highlight anytime the page is the frame current navigation content.
Congratulation: your app now has a universal Hamburger menu with a nice title bar! :)
Next steps might be to create a separate user control to hold the HamburgerTitleBar, which will then allow you to bind the Title property to view model (making it easier to update on a page by page basis).
To make things easier, I’ve provided the source code for a simple app using these controls!
Update: Though the information and concerns in this blog post are still very true, I’ve actually had a change of heart and I’m now advocating to Start Strong-Naming your Assemblies!!
For far to long, Strong-Named Assemblies have been a huge rock in the shoe of 3rd party library developers, but people: it’s 2016, so why are you still using it?
How it all started…
The year was 2002 (or so I believe!), Microsoft had just released the .NET Framework, and one of the main enterprise focused features was the ability to sign an assembly with a strong-name.
Back then, Strong-Named Assemblies had some great advantages, as indicated in this MSDN article:
You want to enable your assemblies to be referenced by strong-named assemblies, or you want to give friend access to your assemblies from other strong-named assemblies.
An app needs access to different versions of the same assembly. This means you need different versions of an assembly to load side by side in the same app domain without conflict. For example, if different extensions of an API exist in assemblies that have the same simple name, strong-naming provides a unique identity for each version of the assembly.
You do not want to negatively affect performance of apps using your assembly, so you want the assembly to be domain neutral. This requires strong-naming because a domain-neutral assembly must be installed in the global assembly cache.
When you want to centralize servicing for your app by applying publisher policy, which means the assembly must be installed in the global assembly cache.
So strong-named assemblies are uniquely identified, which is a good thing, until it starts to work against you…
Let’s look at a real example: a few years back, JSON.net was actually a strongly-signed assembly. Now let’s assume we have a project that depends on “LibraryA” and “LibraryB”, and each of these require a different version of JSON.net.
If you build the project as it currently is, there will be a conflict as you can only have a single version of JSON.net on the output folder, but the libraries require different versions…
To fix this issue, .NET provided a mechanism called Assembly Binding Redirection to ensure that only one specific assembly would be used, regardless of the required version.
In comes Silverlight and Windows Phone
Unfortunately, neither Silverlight nor Windows Phone support Assembly Binding Redirection… and that is where the true problems started.
Others, followed the advice of the MSDN article I pointed above:
If you are an open-source developer and you want the identity benefits of a strong-named assembly, consider checking in the private key associated with an assembly into your source control system.
Obviously, for this to work you would have to build your own versions of your project dependencies… and let’s be honest here: that will eventually be more of a problem that a solution.
A few years ago, I personally felt this pain while developing a Windows Phone app, and so I went to the Windows Phone Developers UserVoice website and requested the support for Assembly Binding Redirection on Windows Phone… almost a year after the request, I got an update indicating it was “on the backlog”, and seems it has stayed like that till now…
If it is such a bad thing, why are people still doing it?
Developers seem to have the wrong notion that they should strong-name their assemblies as a security feature, but this could not be further away from the truth!
Granted, that does provide a basic insurance that an assembly hasn’t been tampered/altered, but in any case one can always use binding redirection (when available) to bypass the whole thing, so that is just a lame excuse to not buy a proper Code Signing Certificate and apply Authenticode to the assembly (which will prevent tampering AND impersonation, the right way!).
What about the Universal Windows Platform?
Unfortunately, as far as I know there is no support for Assembly Binding Redirection in UWP…