Sunday, July 14, 2019

UWP Inline DesignTime data

TLDR: UWP apps can now simulate the inline design-time data that Xamarin.Forms supports.
Simply install `Install-Package UwpDesignTimeData`
Then, do things like this in your XAML: `dt:DesignTime:Text="Only shown in designer."`

---

Let's say you have a simple page in an app. Imagine something like this. It's a default settings page as generated by Windows Template Studio.


Now imagine this is a localized app and so all the text comes from a resource (RESW) file.
In this situation, the XAML will contain Universal Identifiers (`x:Uid`) for each element and the text will be defined in the resource file (for each language.)
These files will look something like this:


That's great, but if you want to change what the page looks like, the designer isn't a lot of help.
Here's what the designer shows.


This is far from great and it's something I can make better based on my knowledge of attached properties and the way the XAML designer works.

Simply install my new NuGet package. UpwDesignTimeData.
Then modify the XAML like this.
The designer now looks like this.
Yay!

It's not just great for localized content, it can also provide design-time data for values set with a binding.



It doesn't only work with text. It supports the following properties:

  • Caption
  • Content
  • Date
  • Description
  • FlowDirection
  • Footer
  • Header
  • Icon
  • IsChecked
  • IsOn
  • Maximum
  • MaxRating
  • Minimum
  • OffContent
  • OnContent
  • PaneFooter
  • PaneHeader
  • PaneTitle
  • Password
  • PasswordChar
  • PlaceholderText
  • PlaceholderValue
  • QueryText
  • Source
  • Symbol
  • Text
  • Time
  • Title
  • Value

These should work with all the standard controls. It won't work with custom controls. Sorry.

It even works for a few things that you can't do in XAML with the regular properties.
For example, you can specify a date or time for the DatePicker (or TimePicker) as strings and it will try and parse the value and then show it.



It works with Visual Studio 2017 and 2019.

Things to note.
  1. You may need to (re)build the project to force the designer to refresh and show the design-time data.
  2. If you find a bug or something that it doesn't work with, please log an issue with the details.
  3. If you define the actual and design-time versions of the same property, specify the design-time version second. This is necessary because of the way the XAML designer works.
  4. This should work regardless of the version of the SDK you are targetting (or have as the minimum.) If it doesn't work in your scenarios, please log an issue with the details.
  5. Documentation will follow.
Important.
Xamarin.Forms already has native support for this functionality. Hopefully, UWP (and WPF) will get this officially at some point in the not-to-distant future. ;)
When that happens, I hope and expect you'll be able to simply remove this package from your app and replace all instances of "dt:DesignTime." with "d:".


Sunday, July 07, 2019

Using data from SQL Server and/or Web API in UWP apps - Feedback wanted

In the next release of Windows Template Studio (the amazing tool for scaffolding your modern Windows apps) we'll be adding options to make it easier to connect to a SQL Server database or also create your own Web API.

If you've done, or are interested in either of these things your feedback will be gratefully appreciated.

SQL Server

In many enterprise scenarios, the ability to connect to data from a SQL Server database is a must. Adding appropriate references to a project can be more work than many developers would like and so this option makes setting up the project appropriately only require a single click.
Of course, it's still necessary to retrieve and load the required data but you'd have to do that anyway. What this option does is just set up the project so that this is easy to do. It also adds appropriate TODO notes so you know where the generated code needs to be modified. Additionally, there's also a method that shows how to use data from a NorthWind sample database as a replacement for the SampleData that is used by default by the pages included in the generated app.
This is deliberately not an option for generating an app based on the contents of a database. There are other tools available if that's something you want to do.


Web API (and HTTP data access)

Taking heavy inspiration from the MobileAppService option when creating a Xamarin.Forms app, we've added the ability to include an ASP.NET CORE Web API  project in the generated solution. If you are creating a custom web-based API to go with your new app, this should make it that little bit easier.
Differences between these new options and the Xamarin.Forms version are that we take a dependency on the "App.Core" shared library to avoid duplication, return our own `SampleData` in the default controller, and we've separated the code for the app to retrieve content from the API in a separate `HttpDataService` class so that they're available in apps that don't want (or need) to include the Web API directly.


As with everything that is included in Windows Template Studio we tread a delicate balance between providing enough to avoid developers needing to do more than they must, but also not being explicit on how something must be done, or including lots of code that must be removed.

If you have thoughts on any of the above, I'd love to hear them.



As an own-trumpet-blowing aside, the addition of these options means I now personally claim responsibility for twenty (20) of the options available in the WTS wizard. I've done a load of other stuff too (VB.NET support & internal testing being the main areas) but thought this was a nice milestone to celebrate.


Tuesday, June 25, 2019

How much code is there? (Counting lines of code)

Lines of Code (LoC) isn't the greatest of metrics (and definitely not a sign of productivity) but sometimes it can be interesting to know.

Last week, after giving a demonstration of the Rapid XAML Toolkit someone asked me just how much code I'd written.

I didn't have a way to quantify this so I said I didn't know. "What counts as 'quite a lot'?"

Later I was thinking about the question and it made me wonder "What even is a quick way to count LOC in Windows?"

I didn't know.

Then I remembered that it's something I used to do regularly in Linux with one command. This was probably prompted as I gave a talk about Windows Subsystem for Linux (WSL) earlier that day.

WSL makes it easy to do things on Windows that are easy on Linux.

So, to count the lines of code in a project on Windows.

  1. Open the folder, with the code in, in Windows Explorer.
  2. Open WSL there (Shift+Right click and select 'Open Linux shell here', or type 'wsl' in the address bar.)
  3. Type `find . -name '*.cs' | xargs wc -l`  (assuming you're using C#)
  4. Look at the number

Screenshot of output from the command


Wow, that's 33463 lines of code in RXT.
Much more than I would have guessed.
Ok, so it includes blank lines and lines that only include curly braces but it's still quite big.

I wonder how many lines it will be by the time we release the preview...

Tuesday, June 18, 2019

What’s New for the Command line and Windows Subsystem for Linux #InsiderDevTour

Today at the #InsiderDevTour in London I gave a talk about WSL and the new Terminal.

Here are some useful related links that might be useful if you want to learn more about this.




Monday, May 20, 2019

UWP Terminology



The Universal Windows Platform (UWP) has never been just one thing.
As a "platform" it incorporates many elements. There was the UI (which was a new "flavor" of XAML.) There were all the new platform APIs. And there was a new application isolation and packaging capability.
With a new operating system, designed to work on lots of different devices, you'd expect a lot of new functionality and capabilities.
Having a single term for all these capabilities that's different from the OS itself (which could still support old development capabilities as a way of maintaining backward compatibility) was a useful shorthand. "UWP" was that term.

UWP had some limitations as a term. That many people wanted "Universal" to mean any device or OS, not just Windows was one of them. Those people missed the second word in the term though. It meant "universal" across Windows devices. As a counterpoint, at the time Apple was using "Universal" to mean iOS apps built to run on both the iPhone and iPad.
There was also uncertainty as it was clear what made an app a UWP app. Even on Microsoft's own page explaining this, I don't think it's clear to be able to say if something is a UWP app or not.

Here's the thing though, it doesn't matter.
An app can be a UWP app regardless of the technology the UI is created with.
Any app which uses Windows 10 specific APIs can be a UWP app.
Any app can be packaged as a UWP app.

So, as the term loses its meaning, the need to use it diminishes as well.

WinUI covers everything to do with creating a modern, fluent, Windows 10 related interface.
Any app can use Windows [10] APIs.
And any app can be packaged with MSIX.

Maybe we'll need to use these terms in combination with "UWP" for a while (I've used "WinUI/UPW" to connect the two ideas in what I hope is just a transition phase) but hopefully not forever.
This isn't the "death of UWP", this is just an acknowledgment that the term isn't all that helpful and we can use other terms for more specific aspects instead. The underlying technologies aren't going away and there's no value in arguing over if an app is a UWP app or not.