XAML element properties and cut-paste refactoring

As you know, to set properties for WPF objects in XAML, one uses either attributes or elements, like the Text and LayoutTransform properties of the TextBox element below, respectively:

  <TextBlock Text="Hello!">
      <ScaleTransform ScaleY="2"/>

Using elements is required when the content to set as property value is complex (and cannot be expressed with a simple attribute) and it is also local (i.e. there are no reasons to transform it into a resource), such as the case of the LayoutTransform setting above.

However, many times XAML is refactored during the lifetime of a project, and requirements like this appear often: the Hello text block should be replaced by a TextBox when the app enters edit mode, so that the end user can change the text at will.

To address this, you would probably update the XAML to something like this:

    <TextBlock Text="Hello!" Visibility="{Binding IsReadOnly, Converter={StaticResource BooleanToVisibilityConverter}}">
        <ScaleTransform ScaleY="2"/>
    <TextBox Text="{Binding Text, ElementName=TextBlock}" Visibility="{Binding IsEditing, Converter={StaticResource BooleanToVisibilityConverter}}"/>

Of course, this works assuming that you have prepared IsReadOnly and IsEditing properties under data context (e.g. view model), and surely there are easier ways (such as triggers) to do this, but for now let’s focus on the original LayoutTransform setting. In the updated code, it applies only to the TextBlock, but not to the TextBox, so the look of the text will change when entering edit mode. Not good!

To resolve the problem, you need to move the ScaleTransform definition to the LayoutTransform property of the element that contains both the TextBlock and the TextBox, which is the new Grid element that you introduced to ensure that the two text elements are on top of each other, i.e. same grid row and column, zero and zero, since a Border cannot have multiple children (and you needed a Panel, e.g. Grid):

      <ScaleTransform ScaleY="2"/>
    <TextBlock Text="Hello!" Visibility="{Binding IsReadOnly, Converter={StaticResource BooleanToVisibilityConverter}}"/>
    <TextBox Text="{Binding Text, ElementName=TextBlock}" Visibility="{Binding IsEditing, Converter={StaticResource BooleanToVisibilityConverter}}"/>

But as you can see in the updated example, the property element needs to be updated, i.e. the prefix class needs to be changed from TextBlock to Grid, so the refactoring is not an easy cut and paste operation! Imagine this repeats for multiple properties and multiple locations within the XAML.

To avoid the required prefix changes, however, you could have used this simple tip from the beginning:

When setting WPF properties using XAML elements, use a base class prefix.

In our example, that means that we could use <FrameworkElement.LayoutTransform> instead of <TextBlock.LayoutTransform> originally, since TextBlock inherits, at some point in the hierarchy, from FrameworkElement, and then we could easily move the definition from the TextBlock to the root Grid with a simple cut-paste operation because the Grid is also a FrameworkElement itself – both examples below work correctly:

<TextBlock ...>
    <ScaleTransform ScaleY="2"/>
<Grid ...>
    <ScaleTransform ScaleY="2"/>   

And now you just need to know good base classes for the objects you set up in XAML. Although the WPF class hierarchy seems (and is) complex, remember that most of the times FrameworkElement is the one you can use for most common properties where you would want to support cut-paste refactoring (interchangeability).

Posted in WPF | Tagged , , , , , , | Leave a comment

Developer, you need an iPhone

I don’t mean iPhone X: it probably doesn’t worth its price, although benchmarks shock. And I don’t mean 8 unless you want wireless charging and a little more power. It can surely be just an iPhone 7, especially if you like black. It can also be 6S if you accept an older chip and a model that is not water/dust proof, or even an SE if you can live with a smaller and less colorful screen, and don’t want 3D touch either. Compare models here.

But if you’re a UI app developer today you do need an iPhone, and here are the reasons, in a logical order, as much as I could find it:

  • People go mobile, and many go mobile-only, while desktops fade away. Asia is first, followed by the Americas, but Europe also joins the trend.
  • With the unfortunate Windows Mobile failure, even with free Xamarin, Windows is doomed to remain a server side OS, eventually buried in Azure services, and if Microsoft follows its current plan (as it seems) of remaining a services-only company, Linux may eat it there too: they just released .NET Core 2.0. While they continue selling Office 365 and Azure, which I assume is their best shot to remain relevant in the IT world for the medium term, they seem to have problems with HoloLens; some time ago I considered their holographic device that is capable of running most 2D UWP apps too as a possible Windows saver; but not anymore, because from my point of view they should have already prepared something for the end user by now, and instead I see no advance at all on that side.
  • Android and iOS will soon be the only ones that matter, even for AR (see ARCore and ARKit). And even for many businesses, not only for consumers. UI app developers (need to) accept it. Even if they come from the beloved Microsoft ecosystem of around 2010, like I do.
  • End users seem to like native apps more than Web apps, so going HTML5 and JavaScript won’t be the best choice. (I changed my mind, indeed; a few years ago I would have advocate towards using JavaScript everywhere.) But of course, a presentation Web site will always be needed for your company and products.
  • To be able to test your Web sites on the appropriate browsers, even if only those made for presenting your products, you need to check the browser market shares. Google Chrome is a must, but note that the second place is won by Apple‘s Safari. And devices that run it are only Apple devices: iPhone, iPad, and Mac. As it’s no longer available nor supported on the Windows desktop.
  • Back to native development, we can easily find out that Android has a high market share, but also that iOS app sales are often of higher value (especially for business-oriented apps) since iOS devices seem to be the preferred devices among those who afford them.
  • Therefore, to be relevant as an app developer, you should develop both for Android and iOS; the latter still has an appreciable share of over 20% on the phone market, and for tablets it even passes 60% (tablets are a niche, at this time, themselves, but they are still important.)
  • Targeting both Android and iOS apps, developers often dismiss cross-platform frameworks (both those producing native output like the above mentioned Xamarin or building JavaScript-enabled WebView-based apps like Cordova and Ionic), even that they could help reuse much code, mostly because they are late in feature adoption compared to the first party native development tools provided by Google and Apple, corner cases are way more difficult to resolve when they (inevitably) get you around, and (for JavaScript targets) app performance may be too low.
  • However, even if you would choose Xamarin or Cordova, you will need a Mac to be able to deploy iOS apps, besides an Apple developer subscription. And of course, if you choose to develop in a fully native fashion, you’ll also use xCode on that Mac.
  • For Android app development, things are easier: you can develop natively with Android Studio or Xamarin either on your old Windows PC or on the Mac (Microsoft also released Visual Studio for Mac that includes Xamarin!) And to release your apps you just need to register as an Android developer with your Google account (with a one time payment).
  • But when you develop mobile apps it’s quite mandatory to test your code on real devices running each of the target platforms, and not only on simulators. So you’ll need at least one iPhone and one Android phone since you target both their OSes.
  • If you’re a freelancer, a small business owner, or just bring your own devices into a company domain to work for that employer, and use them both for personal stuff and for business, it will be easier if one of the two phones will be your primary mobile machine. And as you’re a geek, that really needs to be the a powerful one, and therefore it’s probably going to be the most expensive of the two. That means you will either get a recent iPhone if you decide for iOS as primary device’s OS or a Google Pixel phone, or a similarly expensive third party device if you want Android.
  • Thinking about the secondary device, assuming that you don’t want second-hand items, you’ll notice that the least expensive iPhone at this time is the SE, but it’s still quite expensive and also maybe too powerful compared to many Android phones that you could use for testing your apps as secondary devices. For example, a new, but less powerful Samsung Galaxy J3 is only half of the price of an iPhone SE.
  • To conclude, as you need two phones – one with state-of-the-art technology and one for testing purposes only – you need to sum up their prices. And I really think that the amount is going to be much lower if you get a powerful iPhone and a low cost Android. This will also be a good simulation of the real world, where many of the Android phones are lower cost devices and run older OS versions, which your app should still support, while most iPhones are more recent and capable, as Apple pushes them hard towards its (smaller, but richer) crowd.

Note: iPhones (and Macs) are not only style & fashion devices, like I used to think myself, and like others may still think due to rumors and misunderstandings; they are really powerful devices and Apple hardware and software teams really seem to collaborate well, as software innovation easily turns into interesting hardware changes whenever needed. This integration is most of the times more important than having the newest hardware or the newest software installed, if they are obtained separately and from different parties. Moreover, Apple‘s ecosystem, although it lacks a few things on the server/cloud side, is somehow similar to Microsoft‘s old world that you may have liked.

PS: If you’re an Android fan, don’t hate me. Get yourself an Android primary device and an iPhone SE for iOS testing. You’d pay more this way, but if it brings more emotional value to you, don’t hesitate and go for it. Maximize your own value! (You’ll still need a Mac, though, and it will probably be less integrated to your primary Android phone than it would with an iPhone, but again, it’s your life, your choice.) 🙂

Posted in Development | Tagged , , | Leave a comment

Bloody space in a form input name

Suppose that you have to HTTP-post a form with some pre-computed hash field to a service. You prepare the form as HTML or as an HTTP client call, with a hidden input field or a request body parameter that is (apparently) named hash and submit it.

But you receive an error from the service, like this:

The computed hash is different than the hash in your request.

You struggle to see what’s the difference, thinking that maybe your hash generation algorithm was incorrect or incomplete and sometimes you might work for a few hours on this to only see eventually that… there was an inadvertently entered space in the name of the input field:

<input type='hidden' name='hash ' value='{computedHashValueHere}'/>

In this case the hash<space> field is correctly sent with the form, but the service might not match it to the expected hash field, and also it might not inform you that the expected hash hasn’t been received at all, especially if it’s implementation is poor (like that of ipg-online.com, for example).

And you won’t be able to easily spot the issue with a network sniffer either (e.g. Fiddler), since the space will probably be there in the view just as an (obviously) invisible char!

Lesson learned: be very, very careful and cautious when you define your request in these situations. Check for supplemental or missing spaces, lowercase vs. camelCase vs. PascalCase vs. UPPERCASE vs. ANYOtherCase, and also check that the form root element is defined correctly.

For the latter case (regarding the root form element definition), note that the example form below will only send one field – the second – feel free to try it yourself and check the form in the browser’s DOM (using developer tools) to detect the issue:

<form id='myForm' method='post' action='http://myurl.com">
  <input type='hidden' name='x' value='{x}'/>
  <input type='hidden' name='y' value='{y}'/>
  <input type='submit' value='submit'/>

Or, if you don’t have the time to do it, just check this screenshot – it will help you easily identify the incorrect ending character for the action attribute of the form definition (double quote instead of single quote):


Posted in HTML5, WebAPI | Tagged , , , , , , | Leave a comment

Auto-disposing? Empty using syntax?

What do you think? Should this code auto-dispose the X object instance created but not used? If you test it, you’ll see it does not:

public class X : IDisposable { … }
static void Main(string[] args)
    Get(); // Doesn't dispose result.

static X Get()
    Console.WriteLine("Getting X...");
    return new X();

As you can see, the Get() call in Main will cause the side effect of constructing a new X object, which is disposable. But Main doesn’t actually use that object – it’s interested just in other side effects caused by Get method to occur, such as to have the Getting X… string written to the output stream.

The compiler could easily infer that the caller doesn’t need the object and it might just inject a Dispose() call on the result of the call that is not put into a var. This would avoid the need of this empty using statement to do the disposal in an explicit way, which seems so awkward, and brings further questions – such as whether to do it or not – especially as X can be Task<T> and in that case it’s commonly used with .NET 4.5’s asynchronous code:

using(Get()) { } // Disposes result.

A possible reason against auto-disposing, though, might be that without the explicit using, maybe the caller is also interested in having the X object healthy (i.e. not disposed) in memory for the next undefined period of time – maybe X just adds itself as a listener to some static object events, for example, and in this case, disposing it blindly might cause unexpected results.

However, I personally think that at least the language should permit this syntax sugaring – and I wonder why nobody thought of it already, as C# reached version 7 this year!

using(Get()); // Doesn't compile!

Ah, I see the problem now! Actually the syntax should better be:

!using(Get()); // But still doesn't compile, of course! :-)
Posted in C# | Tagged , , , | Leave a comment

Using CSS attribute selector to simulate a CSS style selector

Although it might be considered strange by some, sometimes we just want to set up CSS styles on elements selected based on other style values, that are set in other ways, such as inline styles placed by internal JavaScript components that our app uses.

Here is a real-life example. Let’s assume that inside a grid we want input elements of all cells to have a specific height:

.cell input {
    height: 24px;

However, inside some grid columns we use a multi-selector combo box component, displaying multiple items with checkboxes in a pop-up whenever the user clicks the drop down button, allowing him or her to change selections to apply to the cell value. And because the checkboxes from the fixed position and z-index-enabled pop-up are internally considered logical parts of the grid cells, the style for input elements declared above applies to them too, but we clearly don’t want that!

To resolve the problem, we can try using an attribute selector and restore the height to auto for input elements inside the pop-up using the style attribute itself:

.cell [style*="z-index:"] input {
    height: auto;

Strange but this works if the popup is defined with an inline style containing a z-index setting. You can also add the exact value of z-index but then it is important to check if there is a space or not between the column character and the number and copy it properly, because the selector will check the string in a strict fashion. (Too bad that – at least so far – there is no wildcard character that we could use inside the checked value.)

Posted in JavaScript | Tagged , , , | Leave a comment

Developer focus selector

From low level to high level programming, software developers need to select a good technological area to focus on, since nobody would ever know well everything:


Of course, the diagram above is not exhaustive, and it can be seen as just a sample technology sheet. But it allows us to observe some things and draw some (hopefully good) advice regarding the selection of the development focus point that one should embrace, especially if it’s a newcomer to the IT world:

  • Freedom vs. productivity:
    • If you select lower level technologies, you will have more freedom in development, but it will be more difficult to get your app developed and maintained.
    • If you select higher level technologies, you will have to use the framework within its use case boundaries, but it will be easier to get the app released, and maintenance will be easier.
  • Cross-platform limitations vs. multi-platform difficulty:
    • Sometimes a higher level framework will make more lower level technologies compatible at a logical point of view, allowing you to learn less and develop faster, and with more ease; e.g. Xamarin uses only C# and allows you to develop apps for UWP, Android, and iOS without having to learn Swift and Kotlin;
    • However, cross-platform frameworks typically come with many limitations that you won’t have otherwise, especially when you reach to corner cases or want specific features that lower level technologies offer; but if you want to learn multiple platform technologies separately and avoid such limitations, prepare for other type of difficulties: less time left for actual development due to the always learning need, and sequential release chains or longer time between different platform releases.
  • Extended focus – whichever primary focus point you choose, however, you should learn a bit both at lower and at higher levels (whenever and as much as possible):
    • Learning lower level technologies will allow you to understand better how your (otherwise black box) framework works, especially regarding performance, but also addressing user experience or other common app development concerns.
    • Learning higher level technologies will allow you to prepare your code so that it’s usable also from those upper frameworks with more ease, just in case that would be eventually needed, such as to expose components from your area to other projects or even to the general public in the development niche.
Posted in Development | Tagged , , , | Leave a comment

Why interfaces?

We should almost always extract interfaces from your service classes because:

  • We should use dependency injection to load and compose implementations: to avoid the need of manually constructing chains of dependent objects and/or to be able to release implementation changes without rebuilding the entire solution, if dependencies are dynamically loaded.
  • We should isolate and test client callers and for this purpose we need mocking; mocking is a lot easier if the call is performed through an interface.
  • Rarely for polymorphism (although this might be their most obvious use): only if really, really needed – I’d say we should always consider composition first; thst would probably save us from much unforeseen trouble!
Posted in Development | Tagged , , , | Leave a comment