Change notification chaining

Sometimes you want to define a complex container that aggregates other objects and you would like to chain INotifyPropertyChanged notifications upwards. However, it is difficult to write all the code to wrap up everything needed, and often results in code duplication. So although generally I’m against inheritance in favor of aggregation, this time I think it’s OK to just have a base Changeable class as infrastructure to get the requirements fulfilled faster.

I’ve just shared the code of such a Changeable class on GitHub, packaged as a .NET Standard 1.0 library so you could use it virtually everywhere (i.e. regardless of your target platform), being available there with a small sample app that shows how it can be used. Feel free to improve it further!

Posted in .NET, C# | Tagged , , , , | Leave a comment

Naming items

From time to time I find projects with completely inconsistent naming for their items. While I believe naming things – be them source code files, variables, or enum values – is one of the most important things for the long term.

Yes, I know. For files, path length is imporant, so sometimes you cannot assign them very long names. But do name a service ComputingService instead of just Computing even if you put it into a Services namespace (folder). Still, don’t fall into the other extreme: do not prefix an item with all the namespace path from the project root. Indeed, it wouldn’t be fun to call it PublicApiSpecializedComputingService.

Another thing I want to mention here is about grouping files in project folders. While it’s fine to do it, mind the path length and do not group by multiple criteria in the same root folder. Create more sub-root folders for criteria separation, otherwise it will be strange in most IDEs. For example, have Services split into Infrastructure and Logic first, then each into Generic and Specific, if needed. I wouldn’t like a root folder with specialized logic services directly inside, and Infrastructure and Generic subfolders (and another Generic within Infrastructure) outside.

And do create Contracts folders for grouping interfaces, especially if they use hungarian notation and always start with an I: otherwise these files will end between implementation files when sorting alphabetically and most IDEs don’t even support other types of ordering for the files of a folder!

You could argue that you don’t need a Contracts folder when you have a single implementation file in the same folder with the interface, but even then sorting items in different folders may lead to inconsistent ordering and sometimes the interface would be the first, and other times the last. So I’d say it’s best to always separate contracts, even when it’s only one! You may want to even put them into different assemblies, as it would be a lot better that way if you’ll be using the (almost always mandatory) dependency injection pattern!

Finally, use var or a similar generic keyword for introducing a field or local value indicating that its type should be automatically inferred whenever it’s clear from the name but think twice otherwise. Note that to be able to reach this condition, a variable name should really fit its content, expressing as much as possible about its usage. For example, in my opinion a lagInMilliseconds field can be of type double without specifying the type, and so could be, of course, a startDateTime value of type DateTime. But don’t call the output variable of a Linq query just result or tuples: find out and use the meaning of the value since there its type would be too complex to indicate and wouldn’t clarify anything anyway, even when it’s just an intermediary step in a larger algorithm!

Posted in C# | Tagged , , , | Leave a comment

Workaround for FrameworkElement.Triggers using Style and resolving issue

Many times it would be so handy to have Triggers available at the root FrameworkElement object type. Yes, the property exists, but it only supports EventTrigger at that level, while many times you’d want a different type of trigger, such as a DataTrigger, instead. Indeed, wouldn’t it be nice to be able to write this small XAML and ensure TextBlock will move a little more down in its parent Canvas when some toggle is set on the bound data item?

<!-- Note: This code doesn't work. -->
<TextBlock Text="..." Canvas.Top="10">
  <TextBlock.Triggers>
    <DataTrigger Binding="{Binding IsToggled}" Value="True">
      <Setter Property="Canvas.Top" Value="20"/>
    </DataTrigger>
  </TextBlock.Triggers>
</TextBlock>

Hey, you say, but there is a workaround: using an inline Style. More verbose, but the expected result would be the same, no?

<!-- Note: This code still doesn't work correctly, though. -->
<TextBlock Text="..." Canvas.Top="10">
  <TextBlock.Style>
    <Style TargetType="TextBlock">
      <Style.Triggers>
        <DataTrigger Binding="{Binding IsToggled}" Value="True">
          <Setter Property="Canvas.Top" Value="20"/>
        </DataTrigger>
      </Style.Triggers>
    </Style>
  </TextBlock.Style>
</TextBlock>

This should be working, but it doesn’t; you can check: at runtime the trigger will have no effect. And the root issue is difficult to spot if you are not aware of the priorities used by dependency properties upon obtaining their current values. Due to those priorities, the inline property setter that is applied directly to the TextBlock will override the value set by the DataTrigger inside the Style!

To resolve the issue you just need to move the property value setter inside the Style too:

<TextBlock Text="...">
  <TextBlock.Style>
    <Style TargetType="TextBlock">
      <Setter Property="Canvas.Top" Value="10"/>
      <Style.Triggers>
        <DataTrigger Binding="{Binding IsToggled}" Value="True">
          <Setter Property="Canvas.Top" Value="20"/>
        </DataTrigger>
      </Style.Triggers>
    </Style>
  </TextBlock.Style>
</TextBlock>

 

Posted in WPF | Tagged , , , , | 4 Comments

Can smartglasses replace smartphones?

As I previously mentioned I think that 3D visual user interface (provided as augmented or mixed reality, such as by Microsoft’s HoloLens) is going to be the future of app development. Accompanied, maybe, by AI-enabled voice assistants available in more languages. (Hey Siri, how are you?)

Why? Simply because of human nature: we never read manuals, do we? We always want to use a new tool or do a new thing with the skills that we already have, skipping learning as much as possible. Natural user interfaces are going to eventually replace most screens, just like the more natural touch behavior replaced most mice.

(Remember that when Windows 3.1 was introduced you had to run a mouse tutorial to learn how to use it? But no manual, nor tutorial was needed for touch gestures, although older people tend to need one simply because they were used to the old, more difficult, way to handle things.)

I was discussing about these topics with my brother a few days ago, and he asked me a few critical questions that (stupid me) I hadn’t considered before (I was just too holo-enthusiastic):

  • Do you think people would accept dragging glasses (even if they become lighter) everywhere, like they do now with their phones? People want to only carry small things that fit in their pockets, while any glasses need to be larger, don’t they?
  • What if some now unknown company, despite the current pioneers (or dinosaurs) in the field, will find a (lot) better way to do it some time later? For example, what if they’ll find an easy way to generate holograms directly from a phone into the air, without the need to project them to the eye?
    • This way people could share apps at runtime (!) by simply using their features together in the same room, without having to wear devices on their heads (while of course, online sharing will also be possible with two devices).

Indeed, I feel that the current version of HoloLens, and probably the following 2-3 models, will not fit into anyone’s pocket. (Except, maybe, those of Pete from Mickey Mouse Clubhouse; or mine.) Later they will probably become foldable or otherwise “minimizable” to the size of a nowadays phone, though. But people may still don’t like to wear things on their heads, who knows for sure?

Moreover, the second idea – that holograms may end up displaying without eye projection – sounded even more strong to me: people would definitely like to see 3D apps directly in the air of their room more than by using any type of glasses, even if they are very light and foldable to their pocket. Because not wearing a device is more natural than wearing one, no? (You are right, though: with clothes we managed to invert this!)

Still, sharing the app runtime with others in the room might not always be a good option. A setting will need to exist to allow the user to show air holograms only for himself or herself. I think this, however, will be very difficult to achieve without some eye devices from a technical point of view, but we shouldn’t underestimate science.

A possible resolution for the issue would be to go back to smartglasses and turn them into contact lens instead of having them as a head-mounted device, which means little intrusion but otherwise a safe thing. Such holographic projectors must become really tiny standalone devices to be worn on the eye and to not require any connection to a separate machine (HoloLens does this today but it’s not small enough). If they become mass-produced, I’m sure that these lens would really revolutionize our world (again).

To conclude, I think that although glasses (as a medium size device) may not be the end of the story, and that – in the new light – they might not replace smartphones at all unless they become really tiny – it depends very much on the unpredictable crowds and on science progress – for now there isn’t a better technological way to get those natural apps live. HoloLens, like any other technology, from the first PCs to the smartphones and home assistants of today, will have their life cycle, getting us closer and closer to… well… “androidization”, or at least towards the most natural interfaces for our “external” apps, which will eventually be 3D. So I still believe that focusing on HoloLens now is important for future app development – for you to be ready when the real thing will appear.

(No, I was not referring to the Android OS above, but to the fact that eventually we’d all like apps to run directly in our brains. But I acknowledge also that it would be very, very difficult for humans to accept required body implants, and people will probably be very scared to go there, and actually would have many reasons and the right to be against it. This is why I changed the goal to be just the most natural external apps we can get.)

Posted in HoloLens, Miscellaneous | Tagged , , , , | Leave a comment

Server side trends (Microsoft development perspective)

After posting the previous article, discussing client side app trends from a Microsoft developer perspective, I’ve been asked to write something about server side too.

But I feel that for the server side following the trends is a lot less critical, simply because most of the time the developers are the ones who choose the backend platforms and technologies and not the end users. (You can argue that on the client side you are the one who selects the target platforms for your apps too, but wait: you do that by checking the numbers not by checking your preferences: how many possible customers use each possible platform, what do they desire, who pays for premium services and on which types of devices, etc.)

So if you’re a Microsoft-oriented developer you can stick with SQL Server for data storing purposes and ASP .NET WebAPI (with Entity Framework for object-relational mapping) to serve JSON data needed in your client side apps, be them running on Android, iOS, Windows desktop or in a Web browser, without assuming any trend-related risks.

But of course, one can see that many developers look to (and many job offerings are now for) node.js and associated technologies like the MongoDB. Microsoft itself offers node.js development tools in Visual Studio, and a Mongo-based DocumentDB service in Azure!

The latter – namely the NoSQL object oriented databases – have a great technical reason for existence: the developers don’t need an ORM anymore if they embrace the new storage; of course, queries that require traversing many implicitly clustered documents to just read and aggregate some field values would have less performance than if they were run in a relational data context, but many times this is bearable. Especially with cache tools like Redis which can actually hold anything and everything in memory for really fast access, and in conjunction with RAM being very cheap now (you can get it directly in the cloud and increase the paid amount only when you actually need it.)

For node.js, however, my feeling is that trends are somehow not in sync with client side development trends, and it’s even ironical if you think about it more than a minute:

  • for a long time, Web client development (and especially JavaScript-based frameworks like Angular, Aurelia, and languages like TypeScript) increased; but nowadays, because end users tend to move from the browser back to native apps – on their mobile devices – JavaScript development decreases again.
  • node.js on the server side eventually allowed developers to use the same programming language on both server and client sides (reaching a unified technology stack), but this was only temporary since client side apps for iOS and Android aren’t usually done with WebViews (and they won’t ever be done like that).

In conclusion, in my opinion for the server side you are more free to choose whatever technology you wish to learn and use, but personally I’d stick with .NET and WebAPI for the runtime, and either SQL Server or a new NoSQL database for data storage. (MongoDB does have a .NET API which you can use to implement your business logic in C#, for example, don’t worry.)

Posted in Development, Miscellaneous | Tagged , , , , , , , | Leave a comment

Microsoft-ish developer, new app idea: what platforms to target/tools to use?

First, let’s summarize the current trends:

  • mobile (smartphone) usage increases tremendously, desktop usage decreases;
  • users prefer native apps vs. Web.;
  • programmers prefer native development vs. cross-platform development;
  • medium term: HoloLens (3D holograms projected directly on eyes).

Apps

Assuming that you’re a Microsoft technology oriented developer that masters .NET (probably with C#) and JavaScript (probably through TypeScript), I think there are a few (partially divergent) directions to take. I tried to illustrate the options in a small table and hope it would help someone, someday:

Native development (more to learn to target smartphones) Using Xamarin (native apps with C#-based cross-platform dev. tools) Using Cordova tools (WebView-based apps, using JavaScript or TypeScript – not native, but sharing Web code)
Smartphones only
(minimal)
App development 1.0 (native, minimal) App development 2.0 (Xamarin, minimal) App development 3.0 (Cordova, minimal)
Smartphones + HoloLens
(future-oriented)
App development 1.1 (native, future trends).png App development 2.1 (Xamarin, future trends) App development 3.1 (Cordova, future trends)
HoleLens
(future only)
App development 1.1.1 (native, future only) N/A N/A
Smartphones + desktop/Web
(past-oriented)
App development 1.1.2 (native, legacy) App development 2.1.2 (Xamarin, legacy) App development 3.1.2 (Cordova, legacy)
Smartphones + HoloLens + desktop/Web
(extensive)
App development 1.2 (native, future, legacy) App development 2.2 (Xamarin, future, legacy) App development 3.2 (Cordova, future, legacy)
Posted in Development | Tagged , , , , , , , , , , , | 1 Comment

Targeting .NET Framework 4.7 or .NET Core 1.1

A heads up, if I may.

If you plan to develop an app targeting .NET Framework 4.7 or .NET Core 1.1, Microsoft says that you need to:

  • Update Windows 10 to the Creators update, build 15063;
  • Update Visual Studio 2017 to version 15.1.

But they do not tell you that you also need – of course – the .NET Framework 4.7 development tools and/or .NET Core 1.1 development tools, that are both optional features available in the Visual Studio 2017 update dialog, to be able to target these .NET versions from your projects (assemblies).

Note that the check boxes of these optional items may not be pre-selected when you do the Visual Studio update (at least that occurred in my case) and in this case, to resolve the target availability issue, you will need to start the Visual Studio Installer app again, select Modify, then check the features from the right side of the screen, under the .NET desktop development section:

NET47

Posted in .NET | Tagged , , , , , | Leave a comment