Tag Archives: xaml

software development, visual studio, windows

XAML and C#, or HTML and WinJS for Windows Store, Universal and cross platform apps?

4 Comments

Microsoft designed the Windows Runtime (WinRT, the engine behind the controversial touch-friendly “Metro” user interface in Windows 8) to support three development platforms. These are C++ with XAML (for most GUI apps) or DirectX (for fast games); or C# and XAML; or HTML and JavaScript using the WinJS library for access to Windows-specific functions.

Microsoft’s line is that all three approaches are fine to use, with little performance difference other than that C++ avoids an interop layer. Of course if you have any arbitrary code that runs faster in C++ than in C#, then you will still see that difference in the WinRT environment.

It is also obvious that if you are an HTML and JavaScript expert but know nothing of C# or XAML, you should use WinJS; similarly if you have a lot of C# code to port and know nothing of HTML or JavaScript, C# and XAML chooses itself.

But what if you approach the decision from a neutral perspective. I am going to leave aside the C++ option for the moment as it is more of a leap than C# versus JavaScript. Which is best?

On the WinJS side, a common misconception is that this library is only for Windows. At Build 2014 Microsoft announced that WinJS is now open source, and works on other browsers and devices:

The library has been extended to smaller and more mobile devices with the release of WinJS 2.1 for Windows Phone 8.1, which was announced today at //build. Now that WinJS is available for building apps across Microsoft platforms and devices, it is ready to extend to web apps and sites on other browsers and devices including Chrome, Firefox, iOS, and Android.

In order to sample this, I went along to try.buildwinjs.com on an iPad. All the things I tried quickly worked fine on iOS.

image 

If you used WinJS to build an app, you could use PhoneGap or Cordova to package it as a native application for the iOS or Android app stores.

A further reflection on this is that some of the WinJS controls which you might have assumed are native WinRT controls instantiated from JavaScript are in fact implemented in CSS and JavaScript. That is an advantage for cross-platform, but does suggest that Microsoft has been busy duplicating the look and feel of XAML controls in HTML and JavaScript, which seems a lot of work and an approach which is bound to result in inconsistencies.

Another snag with this approach – leaving aside the questions of performance and so on which I have not investigated – is that you end up with the distinctive look and feel of a Windows 8 app, which is going to be surprising on these other devices.

C# also has cross-platform potential, thanks to the great work of Xamarin and not forgetting RemObjects C#. Note though that I wrote C# rather than XAML. There is no cross-platform XAML implementation other than the abandoned cross-platform Silverlight efforts, Silverlight for the Mac and Moonlight for Linux. Xamarin expects you to rewrite your UI code for each platform – which may in fact be a good thing, though more effort.

If you are focused on the Windows platform though, it seems to me that the pendulum is swinging away from WinJS and towards C# and XAML. Wordament is an interesting case. This is one of the better games for Windows 8, and also available for Windows Phone, iOS and Android. Originally this was implemented in HTML and JavaScript. The developers have blogged about the choices they made:

Wordament grew up very fast. It seemed like it went from an indie game with a handful of players to a full on Microsoft title with millions of users, on lots of platforms, almost overnight. In that transition we ended up writing lots of code. For instance, in the course of a year we had ports of the Wordament client written in JavaScript, Objective C, C++ and C#. Each one of these ports has its own special issues, build processes and maintenance challenges. At the time, we were still a two person team and Jason and I were struggling to continue to innovate on Wordament, while supporting the “in-market” code bases we had shipped. So we started looking for a solution that would allow us to share more code between all of the platforms we were targeting. Funnily enough, the answer was sitting in our own backyard: C#.

As we looked around at the state of “cross platform development” on Windows, Windows Phone, iOS and Android we started to realize that C# was an excellent choice to target all modern mobile devices. So we did just that. With the help of Visual Studio for Windows and Xamarin for iOS and Android, we started a project to build a single version of Wordament’s source code that could target all the platforms we ship on. This release on Windows 8 marks the end of that journey. All of our clients are now proudly built out of one source tree and in one language. Even our service, which runs on Windows Azure, is built in C#. This is a huge efficiency win for our team of four.

Notable also is that the forthcoming Office for WinRT, previewed at Build, is written in XAML and C++ (according to what I was told). This means XAML will get some love inside Microsoft, which is bound to be good for performance and features.

An advantage of the C# approach is simply that you get to use C#, which is well-liked by developers and with some compelling new features promised in version 6.0, many thanks to the Roslyn project – which also promises a smarter editor in Visual Studio.

What about XAML? This is harder to love. XML is out of fashion – too verbose, too many angle brackets – and the initial promise of a breakthrough in designer/developer workflow thanks to XAML and MVVM (Model – View – ViewModel, which aims to separate code from user interface design) now seems hollow. I am writing a game in XAML and C# and do not much enjoy the XAML part. One of the issues is that the editing experience is less satisfactory. If you make an error in the XAML, the design view simply blanks out with an “Invalid Markup” error. Further, the integration between the XAML and C# editors is a constant source of problems. Half the time, the C# editor seems to forget the variables declared in XAML, giving you lots of errors and no code completion until you next compile. Even when it is working, a rename refactor in the C# editor will not rename variable references that are within quotes in the XAML, for example property names that are the targets of animations.

On the plus side, XAML is amazing in what it can do when you work out how. The user interfaces it generates are rich, scalable and responsive. It is way better that the old Win32 GDI-based approach (also used in the Windows Forms .NET API), which is hard to get right for all the combinations of screen sizes and resolutions, and has odd dependencies on system font sizes and dialog units (don’t ask).

Despite the issues with XAML, C# and XAML (or C++ and XAML) is my own preference for targeting the new Windows platform, but I am interested in other perspectives on this.

development, microsoft, windows

Getting animated: basics in Windows Store apps

I am not a designer and prefer to avoid things like animation as too difficult. On the other hand, I am writing an electronic card game and it looks bad if the cards move without any animation. There is also an issue in that animation is built into the standard controls, so if you do not animate your own parts of the user interface, it looks inconsistent.

Animation is more significant than it may first appear. You can think of it as a natural progression from a basic graphical user interface, along with things like full window drag. In the real world, objects do not just blink in and out of existence when they move from one spot to another.

My game is a bridge simulation so four cards are laid on the table in turn, at which point the winner of the four cards is calculated and the four cards gathered to form a “trick”. In my original implementation, the four cards simply disappeared at the end of the trick. How can I have it so that they smoothly gather themselves into a pile of four cards?

Like most things in Store apps, it proved a little more complex than I had thought. Originally, I put put each card in a separate cell of a layout grid. In Store apps, there is no built-in way to animate movement between grid cells, though users have come up with custom animations that do this. I thought it would be simpler to put the cards on a canvas instead.

I did some sums and positioned four Rectangle objects at the borders of the Canvas.

image

I want the Rectangle objects to slide smoothly into a pile in the centre. You do this in XAML with a Storyboard element. A Storyboard has child animation elements. When you call Storyboard.Begin() in your code, all the animations run. They run simultaneously unless one or more of the animations has a different BeginTime attribute. If you want a sequence of animations, you can either vary BeginTime, or use a KeyFrame animation which is designed for this.

There are several ways to do what I want. One is to animate Canvas.Top and Canvas .Left using a DoubleAnimation (the name indicates that it targets properties of type Double, not that anything happens twice). Note that if you this, the Storyboard.TargetProperty has to be in parantheses:

Storyboard.TargetProperty="(Canvas.Top)"

because it is an attached property. However, I chose to use a RepositionThemeAnimation. I found the way this works counter-intuitive. In XAML, you define a RepositionThemeAnimation with either or both a FromHorizontalOffset and a FromVerticalOffset. At runtime, the RepositionThemeAnimation moves the object to the offset position instantly, and then back to its starting point with animation. In other words, the animation itself does not move the object; unless you have AutoReverse set to True, in which case it does a second animation back to the offset position.

Once you grasp it, it is not difficult. Here is my Storyboard, set as a XAML Resource:

<Page.Resources>
    <Storyboard x:Name="TrickStoryboard">
        <RepositionThemeAnimation Storyboard.TargetName="CardLeft" SpeedRatio=".5"  FromHorizontalOffset="-185"/>
        <RepositionThemeAnimation Storyboard.TargetName="CardTop" SpeedRatio=".5"  FromVerticalOffset="-200"/>
        <RepositionThemeAnimation Storyboard.TargetName="CardRight" SpeedRatio=".5"  FromHorizontalOffset="185"/>
        <RepositionThemeAnimation  Storyboard.TargetName="CardBottom" SpeedRatio=".5"  FromVerticalOffset="200"/>
    </Storyboard>
</Page.Resources>

And here is my code to gather the trick:

this.CardTop.Margin = new Thickness(0, 185, 0, 0);
this.CardLeft.Margin = new Thickness(200, 0, 0, 0);
this.CardRight.Margin = new Thickness(-200, 0, 0, 0);
this.CardBottom.Margin = new Thickness(0, -185, 0, 0);
this.TrickStoryboard.Begin();

In other words, you move the objects to where you want them, and then apply the animation which moves them temporarily back to their starting point, then smoothly to their destination. At this point I should include a little video, but will leave you to imagine the four Rectangles above sliding and merging to a single central Rectangle.

Something to watch for here is how the animation impacts your code flow. The animation runs asynchronously, so if you have:

this.TrickStoryboard.Begin();
DoSomething();

then DoSomething runs before the animation completes. If this is not what you want, you can break at that point, and handle the StoryBoard.Completed event to resume. In my brief tests, StoryBoard.Completed always fires even if the animation gets interrupted, say by some other code that did something to the objects.

For more on this subject, read up on Animating your UI and get to know the different animation classes, Visual states, easing functions, RenderTransforms and more. It soon gets complex and verbose unfortunately, but on the plus side it is great to have animation baked into the framework, and the result is a more polished user interface.

development, microsoft, software development, visual studio, windows

Notes on styling a Windows Store app ListView to vary item appearance according to the data

Problem: You have a ListView containing data. You want to vary the appearance of items in the ListView according to the value of the data.

I spent some time on this in relation to a panel for a game I am writing. For example, you have a ListView containing numbers. How can you have negative numbers appear in red?

image

In desktop WPF (Windows Presentation Foundation) you could do this with Property Triggers but these are not supported in Store apps.

One way to do this is with a value converter. Add a class to your project called MyValueConverter. Make the class public, and inherit from Windows.UI.Xaml.Data.IValueConverter.

Right-click IValueConverter and choose Implement Interface to have Visual Studio create two stub methods, Convert and ConvertBack.

This class is going to return an object which will be applied to the Foreground property of a ListViewItem. The Convert method looks like this:

public object Convert(object value, Type targetType, object parameter, string language)

At runtime, the value argument will contain the item displayed in this row of the ListView. The targetType will match the type of the property we are setting, which in this case is a Brush object.

Now add an instance of MyValueConverter to MainPage.xaml (or App.xaml) as a resource. If there is no Page.Resources element, create it, and add an instance of MyValueConverter with the Key “NumberForegroundConverter”:

<Page.Resources>
<local:MyValueConverter x:Key="NumberForegroundConverter" />
</Page.Resources>

Next, select the ListView element in the XAML editor or designer. Right-click the selected element in the designer, and choose Edit Additional Templates – Edit Generated Item Container (ItemContainerStyle) – Edit a Copy …

image

Accept the default name of ListViewItemStyle1 and click OK.

This generates an element that defines the layout and appearance of items in the ListView. Currently it does not appear to do anything, since it is a copy of the default settings.

Find the element called <ListViewItemPresenter> which is nested within <ControlTemplate TargetType=”ListViewItem”>. No Foreground attribute for ListViewItemPresenter is generated, but we can add one:

Foreground="{Binding Converter={StaticResource NumberForegroundConverter}}"

If you now run the project, you will get an exception, because the methods in MyValueConverter do not yet have any code. Now we have to think about the type of the items in the ListView. In this example, I just typed some strings into the XML editor:

<ListView ItemContainerStyle="{StaticResource ListViewItemStyle1}">
<x:String>145</x:String>
<x:String>-30</x:String>
<x:String>442</x:String>
</ListView>

All the items are strings, so the Convert method can look like this:

String s = (String)value; //note this ONLY works if the item is always a string

if (float.Parse(s) < 0)
{
return new SolidColorBrush(Windows.UI.Colors.Red);
}
else
{
return new SolidColorBrush(Windows.UI.Colors.White);
}

We don’t care about the ConvertBack method so can use this code:

return Windows.UI.Xaml.DependencyProperty.UnsetValue;

It works but there are some issues. One oddity is that when you roll the mouse over a negative number, it looks the same as a positive number.

image

This is because we did a converter for the Foreground property but not for the SelectedForeground property. XAML in Store apps makes extensive use of themes, and themes include a lot of brushes.

Another issue, which may or may not impact your application, is that the converter code does not run again if you change the displayed item dynamically. That is, if you replace the item it updates OK, but if you update the existing item it does not.

A slightly more complex example will demonstrate this. Let’s say that rather than displaying strings, the ListView is displaying Widget quantities, where a negative number indicates backorders. The ListView is bound to an ObservableCollection<Widget>, and the Widget class implements INotifyPropertyChanged so that the ListView will update automatically when a Widget property changes. Note that the NumberForegroundConverter must be updated to accept a Widget value rather than a string.

Here is what happens if a Widget had a negative quantity when the ListView was first populated, but got dynamically updated to a positive value (some stock arrived):

image

Oops! Now the positive quantity is in red.

We can fix this by abandoning the converter, and instead giving the Widget class a Foreground property of its own, calculated to return Red for negative quantities and White for positive. Make sure it fires a NotifyPropertyChanged event when updated. Now the Foreground property in <ListViewItemPresenter> looks like this:

Foreground="{Binding Foreground}"

It works:

image

I used this approach in my game in order to implement an Enabled property that indicates items which are unselectable. This changes dynamically according to the state of the play.

Note that you are unlikely to want a Foreground property in your business objects, but could create a DisplayWidget class for the purpose.

I realise that these are not the only ways to create a ListView which styles items differently according to their values, but they may be the simplest. Other suggestions and comments are welcome.

Update: Mike Taulty has some comments and suggestions here.

.net, microsoft, mobile, sharepoint, silverlight, software development, visual studio, windows

Microsoft Build Sessions published: Windows Phone XAML and HTML/JS apps, new Azure APIs and more

2 Comments

Developing for Windows Phone is now closer to developing for the Windows 8 runtime, according to information from Microsoft’s Build sessions, just published.

Build is Microsoft’s developer conference which opens tomorrow in San Francisco.

image

Building a Converged Phone and PC App using HTML and JavaScript states that “An exciting part of Windows Phone 8.1 is that you can now start building applications natively in HTML and JavaScript.”

Other sessions refer to the Common XAML UI Framework, which seems to refer to a shared UI framework for Windows Phone and WIndows 8, but using XAML rather than HTML and JavaScript.

This is in addition to Silverlight, not instead, judging by this session:

We’ve been doing a lot of work with new converged XAML app support on Windows Phone 8.1, but what about legacy Windows Phone Silverlight XAML based apps?  Come learn about all the new features we’ve enabled with Silverlight 8.1.

Microsoft has also come up with new APIs for applications that integrate with its Azure cloud platform and with Office 365. The Authentication library for Azure Active Directory lets you build both Windows and mobile applications that authenticate against Azure Active Directory, used by every Office 365 deployment. There is also talk of using Azure for Connected Devices, meaning “Internet of Things” devices using Azure services.

Some other sessions which caught my eye:

Connected Productivity Apps: building apps for the SharePoint and Office 365 platform.

What’s new in WinJS: the road ahead. XAML vs HTML/JS is a big decision for Windows developers.

Anders Hejlsberg on TypeScript

Automating Azure: “The Azure Management Libraries and Azure PowerShell Cmdlets allow this type of automation by providing convenient client wrappers around the Azure management REST API”

Authentication library for Azure Active Directory: The Active Directory Authentication Library (ADAL)

Panel discussion on desktop development: is there a future for WPF? Maybe some clues here.

Miguel de Icaza gets a session on going mobile with C# and Xamarin. I recall when de Icaza ran sessions on Mono, the open source implementation of the .NET Framework which he initiated shortly after Microsoft announced .NET itself, in nearby hotels at Microsoft events; now he is inside.

Learning from the mistakes of Azure: Mark Russinovich on what can go wrong in the cloud.

Looks like both cloud and apps for Windows Phone/Windows 8 are big themes at Build this year.

.net, microsoft, software development, visual studio, windows

Entering Microsoft’s XAML labyrinth: is it worth it?

6 Comments

I spent some time at the weekend working on a Bridge game for the Windows Store. I am writing it in XAML and C#. The UI is hardly demanding, given that Bridge is a card game, but it has made me take a fresh look at XAML, the markup language for a Windows Store App user interface (unless you use HTML and JavaScript). XAML is also used in Windows Presentation Foundation and in Silverlight/Windows Phone.

As part of the game, the user selects a “bid” which consists of a number from 1 to 7 and a suit of cards (or double, redouble or pass). Most bridge games show this as a grid though functionally it is like a combo-box (choosing from a pre-defined range of options).

Naturally I looked for the easiest way to accomplish this. The solution I came up with was to nest TextBlock controls in Border controls in Grid cells. Then I wrote C# code that detects which cell the user taps and updates the background of the selected Border accordingly.

image

I have in mind to replace the text with graphics and make the numbers a bit smarter at some future date. My solution works fine; here it is at runtime:

image

At the weekend I happened to be chatting with a developer more expert in XAML than myself, who told me I had done it wrong. In XAML everything should be in Style definitions. I should use a ListView and design it in Blend.

Well, I knew that I had somewhat subverted how XAML is meant to work, so I sat down to investigate this different approach. A ListView looks nothing like what I want out of the box.

image

However, with the magic of XAML it can be transformed. I made the ListView horizontal by defining an ItemsPanelTemplate in Application.Resources:

<ItemsPanelTemplate x:Key="ItemsPanelTemplate1">
  <StackPanel Orientation="Horizontal"/>
</ItemsPanelTemplate>

and adding 

ItemsPanel="{StaticResource ItemsPanelTemplate1}

as an attribute of the ListView.

Then I added an ItemTemplate to draw the kind of block that I wanted:

<ListView.ItemTemplate>
    <DataTemplate>
        <Border BorderThickness="1" Height="130" Width="130" BorderBrush="Black">
            <TextBlock FontSize="24" FontWeight="Bold" HorizontalAlignment="Center" VerticalAlignment="Center"
                       Text="{Binding Name}" Foreground="Black" />
        </Border>
    </DataTemplate>
</ListView.ItemTemplate>

Note that I am using a DataTemplate because the ListView is bound to an ObservableCollection in the proper XAML way.

At this point I am close to what I want – never mind that the numbers are missing, they can easily be added with a second ListView:

image

However I do not want that little tick mark appearing, the selected background colour is not to my taste, and the spacing of the items is wrong. How do I fix that?

My search led me to this post which explains a far-from-obvious series of steps you can take in Blend. The steps did not quite work for me but got me on track to create a new Style resource which I called ListViewItemStyleNoGlyph and which lets me adjust the margin and also a previously hidden property called SelectionCheckMarkVisualEnabled. Blend generated a substantial block of code for this:

image

This has helped and now my ListView looks like this:

image

Well, it is nearly there and I can see that with a bit more effort I can get what I want. Even so, I am beginning to wonder whether my initial approach, in which I understood all the code, had advantages over this exploration into the labyrinth.

Is XAML well loved out there? I came across this post by Paul Stovell from a couple of years back which seems relevant. “I’ve lived and breathed the technology for the last six years”, he says, but writes:

What’s disappointing is that WPF started out quite positively during its time. Concepts like dependency properties, styles, templates, and the focus on data binding felt quite revolutionary when Avalon was announced.

Sadly, these good ideas, when put into practice, didn’t have great implementations. Dependency properties are terribly verbose, and could have done with some decent language support. Styles and templates were also verbose, and far more limited than CSS (when WPF shipped I imagined there would be a thousand websites offering high quality WPF themes, just like there are for HTML themes; but there aren’t, because it is hard).

Data binding in WPF generally Just Works, except when it doesn’t. Implementing INotifyPropertyChanged still takes way too much code. Data context is a great concept, except it totally breaks when dealing with items like ContextMenus. ICommand was built to serve two masters; the WPF team who favored routed commands, and the Blend team who favored the command pattern, and ended up being a bad implementation for both.

Stovell mentions the verbosity of XAML, and that it is hard, both of which sound right to me. He contrasts the way ASP.NET has evolved, with ASP.NET MVC a great improvement on web forms. Read the full post for more detail.

It seems to me that XAML does offer much that is wonderful: flexibility, capability, and the ability to separate presentation from data. At the same time, neither XAML nor Blend are intuitive tools for developers; they may make more sense to designers, but it seems to me that removing a tick mark from a ListViewItem should be more straightforward. Perhaps it is, in which case there is a failure of documentation or tooling rather than functionality, but it makes little difference to the developer.

microsoft, professional, software development, visual studio

How to crash your Windows Store XAML app

I am working on a Windows Store app, of which more soon. I am writing the app in XAML and C#. I was tweaking the page design when I hit a problem. Everything was fine in the designer in Visual Studio, but running the app raised an exception:

image

WinRT information: Failed to create a ‘Windows.Foundation.Int32’ from the text ‘ 2’.

along with the ever-helpful:

Additional information: The text associated with this error code could not be found.

The annoying this about this error is that debugging is not that easy. The exception is in Framework code, not your own code, and Microsoft does not supply the source. Once again, everything is fine in the designer and there are no compiler errors.

Puzzling. I resorted to undoing bits of my changes until I found what triggered the problem.

This was it. In the XAML, I had somehow typed a leading space before a number:

Grid.Row=" 2"

The designer parses this OK (it would be better if it did not) but the runtime does not like it.

Actually, I know why this happens. If you are typing in the XAML code editor (which I find myself doing a lot), then auto completion inserts the blank space for you:

image

I wish all bugs were this easy to solve, though I regard it as a bug in the Visual Studio editor. Posted here mainly in case others hit this problem; but I also observe that Windows Store development still seems less solid in Visual Studio than the tools for desktop or web apps.

Other problems I have hit include the visual designer changing to read-only of its own accord; and a highly irritating issue where the editor for a XAML code-behind class sometimes forgets the existence of all the controls you have declared in XAML, covering your valid code with red squiggly lines and reporting numerous errors, which disappear as soon as you compile. Once this starts happening, the problem persists for the rest of the editing session.

It is not all bad. I am pleased with the way I have been able to put together a touch-friendly game UI relatively easily. Now comes the fun part: writing the logic for the AI (Artificial Intelligence).

development, microsoft, software development

Miguel de Icaza: don’t blame Google for Microsoft’s contempt for developers

2 Comments

Xamarin’s Miguel de Icaza (founder of the Mono project) has complained on Twitter about Microsoft’s Windows Division’s “contempt for developers” when it created the Windows Runtime and a “4th incompatible Xaml stack”, in a conversation prompted by the company’s spat with Google over the YouTube app for Windows Phone. Google wants this removed because it does not show YouTube ads, to which Microsoft counters that the API for showing these ads is not available.

image 

I am more interested in his general reflections on the wisdom (or lack of it) shown by Microsoft in creating a new platform for touch-friendly apps in Windows 8, that lacks compatibility with previous Windows frameworks. “No developer wants to build apps twice for Windows: one for desktop, one for winstore” he also remarked.

The four XAML stacks are Windows Presentation Foundation, Silverlight (for which de Icaza created a version for Linux called Moonlight), Windows Phone (which runs a slightly different version of Silverlight), and now the Windows Runtime.

Could Microsoft have done this differently, without compromising the goal of creating a new tablet personality for Windows rather than continue with doomed attempts to make the desktop touch-friendly?

The obvious answer is that it could have used more of Silverlight, which had already been adapted to a touch environment for Windows Phone. On the other hand, the Windows division was keen to support native code and HTML/JavaScript as equally capable options for Windows Runtime development. In practice, I have heard developers remark that HTML/JavaScript is better than C#/XAML for the new platform.

It is worth noting that the Windows Runtime stack is by no means entirely incompatible with what has gone before. It still uses the Windows API, although parts are not available for security reasons, and for non-visual code much of the .NET Framework works as before.

.net, apple, development, mobile, professional, software, software development, visual studio, web authoring, windows

Infragistics building cross-platform development strategy on XAML says CEO

1 Comment

I spoke to Dean Guida, CEO at Infragistics, maker of components for Windows, web and mobile development platforms. Windows developers with long memories will remember Sheridan software, who created products including Data Widgets and VBAssist. Infragistics was formed in 2000 when Sheridan merged with another company, ProtoView.

In other words, this is a company with roots in the Microsoft developer platform, though for a few years now it has been madly diversifying in order to survive in the new world of mobile. Guida particularly wanted to talk about IgniteUI, a set of JQuery controls which developers use either for web applications or for mobile web applications wrapped as native with PhoneGap/Cordova.

“The majority of the market is looking at doing hybrid apps because it is so expensive to do native,” Guida told me.

Infragistics has also moved into the business iOS market, with SharePlus for SharePoint access on an iPad, and ReportPlus for reporting from SQL Server or SharePoint to iPad clients. Infragistics is building on what appears to be a growing trend: businesses which run Microsoft on the server, but are buying in iPads as mobile clients.

image

Other products include Nuclios, a set of native iOS components for developers, and IguanaUI for Android.

I asked Guida how the new mobile markets compared to the traditional Windows platform, for Infragistics as a component vendor.

“The whole market’s in transition,” he says. “People are looking at mobility strategy and how to support BYOD [Bring Your Own Device], all these different platforms, and a lot of our conversations are around IgniteUI. We need to reach the iPad, and more than the iPad as well.”

“There’s still a huge market doing ASP.NET, Windows Forms, WPF. It’s still a bigger market, but the next phase is around mobility.”

What about Windows 8, does he think Microsoft has got it right? Guida’s first reaction to my question is to state that the traditional Windows platform is by no means dead. “[Microsoft] may have shifted the focus away from Silverlight and WPF, but the enterprise hasn’t, in terms of WPF. The enterprise has not shifted aware from WPF. We’ve brought some of our enterprise customers to Microsoft to show them that, some of the largest banks in the world, the insurance industry, the retail industry. These companies are making a multi-year investment decision on WPF, where the life of the application if 5 years plus.

“Silverlight, nobody was really happy about that, but Microsoft made that decision. We’re going to continue to support Silverlight, because it makes sense for us. We have a codebase of XAML that covers both WPF and Silverlight.”

Guida adds that Windows 8 and Windows Phone 8 are “great innovation”, mentioning features like Live Tiles and people hub social media aggregation, which has application in business as well. “They’re against a lot of headwind of momentum and popularity, but because Microsoft is such an enterprise company, they are going to be successful.”

How well does the XAML in Infragistics components, built for WPF and Silverlight, translate to XAML on the Windows Runtime, for Windows 8 store apps?

“It translates well now, it did not translate well in the beginning,” Guida says, referring to the early previews. “We’re moving hundreds of our HTML and XAML components to WinJS and WinRT XAML. We’re able to reuse our code. We have to do more work with touch, and we want to maintain performance. We’re in beta now with a handful of components, but we’ll get up to 100s of components available.”

It turns out that XAML is critical to the Infragistics development strategy for iOS as well as Windows. “We wrote a translator that translates XAML code to iOS and XAML code to HTML and JavaScript. We can code in XAML, add new features, fix bugs, and then it moves over to these other platforms. It’s helped us move as quickly as we’ve moved.”

What about Windows on ARM, as in Surface RT? “We fully support it,” says Guida, though “with a straight port, you lose performance. That’s what we’re working on.”

.net, software development, visual studio, windows

Hands on Windows 8 development: Twitter and hyperlink hassles

7 Comments

I have been messing around with a Windows 8 app to present content from ITWriting.com in an app, mainly as a learning exercise. I came up with the idea of showing recent tweets on the main page of the app. Like this:

image

I thought this would be easy, but encountered several problems. I am developing in XAML and C#; this aspect would probably be easier in HTML.

The first problem: retrieving the tweets. The Twitter REST API version 1.1 has GET statuses/user_timeline which does what I want, except that it requires “user context”, in other words a Twitter log-in. That is an unacceptable requirement for a user simply viewing my tweets, rather than their own timeline.

The deprecated  Twitter RSS API on the other hand is perfect. Unfortunately:

Please note that there is no support for the RSS response format in API v1.1. Properly versioned API v1 URLs will cease functioning in March 2013

Never mind, it will do for the moment. I created a Twitter data source which retrieves the tweets as RSS. In my XAML I have a ListView which is bound to this data source. This ListView has an ItemTemplate which defines what appears in the list. I added a TweetItemTemplate in the Resources section of the XAML which displays each tweet in a TextBlock. So far so good.

image

No hyperlinks though – they are dead. What is the use of a tweet without hyperlinks? Not much. I thought of a hack which would let you click or tap an entire tweet, look to see if a hyperlink is there, and then launch it. Ugly, and would only work for one hyperlink per tweet.

TextBlock does not support hyperlinks. However there is a way to do this using RichTextBlock. This supports a collection of inline elements. You can have a Run element containing text, then an InlineUIContainer containing a HyperLinkButton, then another Run element and so on. The Hyperlink will be out of alignment, as shown here, but you can fix that by tweaking margins and padding.

Of course, this approach does mean parsing the tweet to extract the URLs and then building the RichTextBlock content. So in place of my simple TextBlock binding I now have this:

  <ContentControl Content="{Binding Path=Title,Converter={StaticResource tweetToBlocks}}"></ContentControl>

I have also written a converter class which takes the bound value, builds the RichTextBlock in C#, and returns it. This gets you the result in the first image in this post. Not too bad, and the links work.

What is annoying though is that the mouse pointer does not change to a hand icon when you hover over the link. I thought I could fix this by subclassing HyperLinkButton and adding code to change the cursor on the PointerEntered event:

Window.Current.CoreWindow.PointerCursor = new Windows.UI.Core.CoreCursor(Windows.UI.Core.CoreCursorType.Hand, 1);

This does not work. At least, you can see a flash as the cursor tries to change, but it is overridden by the RichTextBlock which changes it back to a text select cursor. I have not found a way round this yet.

I then tried another approach. You can use a RichEditBox which does support links. The approach is different; you set the text of the Document property and then use the Link method to assign a link to a TextRange within it. It works; but I was frustrated to find that the mouse pointer still does not change to a hand when over the link. The RichTextBlock actually works just as well and is more integrated with XAML.

image

I am sure you could fix this by using a WebView – embedded IE – for each tweet, but that seems to me an unduly heavyweight approach. Better perhaps would be a single web view showing all the tweets, which I might try when I have a moment.

Even so, I was surprised how tricky it is to show tweets with hyperlinks in a ListView.

.net, microsoft, professional, software development, windows

Developing a Windows Runtime app: some observations

2 Comments

What would it take to create a Windows 8 Modern UI content reader for this site? Just for fun, I built a simple one; or rather, I slightly adapted Microsoft’s Metro style blog reader tutorial.

The app only has four screens (or pages) but despite its simplicity I found the tutorial somewhat fiddly. Getting the data from the WordPress RSS feed is simple, thanks to the Windows.Web.Syndication namespace which is part of .NET Framework 4.5. Most of the work is in the user interface, which means switching between XAML and C#. Of course as a developer I would rather work in C#.

Further, the Visual Studio editor for C# is better than the editor for XAML. In C# I can easily navigate the code using Go to Definition, Find all References, and so on.  In XAML it takes longer to find things like referenced styles and resources. Plus XAML is XML, which I find harder to read than an elegant language like C#. Even commenting out a line is more hassle in XML.

I did not like the colours used by the tutorial for the list of posts in SplitePage.xaml. It took me a while to work out what to change. Was the colour defined in a resource, or in a template, or in a style, or directly coded as an attribute of the relevant TextBlock object?

Of course you can open the XAML in Blend if you prefer, the designer-oriented tool that comes with Visual Studio 2012. Blend is more complex than the Visual Studio XAML editor, but may be better once you have figured out how it works.

The amount of work involved in making your app well-behaved is proportionately larger if your app is essentially very simple. You have to deal with different layouts for different screen sizes and orientation, as well as the small Snapped layout. You also have to consider what happens if your app is suspended and resumed.

The above means that despite the apparent simplicity of a Modern UI interface, with its chunky buttons, there is more to consider than with, say, a Windows Forms application whose window is never rotated and over which you have full control.

Still, I was pleased with my app which has reasonable functionality based on a small amount of work.

Visual Studio 2012 is impressive, though I did experience some screen corruption after switching back and forth between the Metro and Visual Studio environments for debugging. Restarting Visual Studio fixes it. Using the simulator seems more robust in this respect.

image

The App Bar

One thing though. If you squint at the above screenshot, you will see that I have put a Read button to the right of the post title. Clicking or tapping this opens the post in a embedded web browser view that is nearly full-screen. However, this Read button is not included in the tutorial, which says:

On the split page, we must provide a way for the user to go to the detail view of the blog post. We could put a button somewhere on the page, but that would distract from the core app experience, which is reading. Instead, we put the button in an app bar that’s hidden until the user needs it.

This may in fact be an excuse to include an App Bar in the tutorial; but I disagree with it. With the App Bar, the user has to right-click or swipe down to display the App Bar, and then click or tap the View Web Page button.

image

That is two actions rather than one. Is it really better than having a small button in the UI?

It seems to me that tucking things into the App Bar is fine in cases where there is real merit in an immersive experience, such as in the web browser, but less compelling when you already have a screen with a back button and a scrollable list. I was also concerned that users might not realise they needed to display the App Bar in order to use the app properly.

Let the design debate continue.

Design-centric

Microsoft’s Modern UI continues a trend which began with Windows Presentation Foundation (the first incarnation of XAML), which is to make a platform richer for UI designers and more challenging for developers who lack design skills. Nothing wrong with that; but if you remember how easy it was to snap together an app in Visual Basic 3.0, you may feel that something has been lost.

I guess that recognition of that fact was one of the motivations behind Visual Studio LightSwitch, in which you define the data and business rules, but the screens are generated for you. LightSwitch has complexities of its own though.