Tag Archives: c++

Notes from the field: putting Azure Blob storage into practice

I rashly agreed to create a small web application that uploads files into Azure storage. Azure Blob storage is Microsoft’s equivalent to Amazon’s S3 (Simple Storage Service), a cloud service for storing files of up to 200GB.

File upload performance can be an issue, though if you want to test how fast your application can go, try it from an Azure VM: performance is fantastic, as you would expect from an Azure to Azure connection in the same region.

I am using ASP.NET MVC and thought a sample like this official one, Uploading large files using ASP.NET Web API and Azure Blob Storage, would be all I needed. It is a start, but the method used only works for small files. What it does is:

1. Receive a file via HTTP Post.

2. Once the file has been received by the web server, calls CloudBlob.UploadFile to upload the file to Azure blob storage.

What’s the problem? Leaving aside the fact that CloudBlob is deprecated (you are meant to use CloudBlockBlob), there are obvious problems with files that are more than a few MB in size. The expectation today is that users see some sort of progress bar when uploading, and a well-written application will be resistant to brief connection breaks. Many users have asynchronous internet connections (such as ADSL) with slow upload; large files will take a long time and something can easily go wrong. The sample is not resilient at all.

Another issue is that web servers do not appreciate receiving huge files in one operation. Imagine you are uploading the ISO for a DVD, perhaps a 3GB file. The simple approach of posting the file and having the web server upload it to Azure blob storage introduces obvious strain and probably will not work, even if you do mess around with maxRequestLength and maxAllowedContentLength in ASP.NET and IIS. I would not mind so much if the sample were not called “Uploading large files”; the author perhaps has a different idea of what is a large file.

Worth noting too that one developer hit a bug with blobs greater than 5.5MB when uploaded over HTTPS, which most real-world businesses will require.

What then are you meant to do? The correct approach, as far as I can tell, is to send your large files in small chunks called blocks. These are uploaded to Azure using CloudBlockBlob.PutBlock. You identify each block with an ID string, and when all the blocks are uploaded, called CloudBlockBlob.PutBlockList with a list of IDs in the correct order.

This is the approach taken by Suprotim Agarwal in his example of uploading big files, which works and is a great deal better than the Microsoft sample. It even has a progress bar and some retry logic. I tried this approach, with a few tweaks. Using a 35MB file, I got about 80 KB/s with my ADSL broadband, a bit worse than the performance I usually get with FTP.

Can performance be improved? I wondered what benefit you get from uploading blocks in parallel. Azure Storage does not mind what order the blocks are uploaded. I adapted Agarwal’s sample to use multiple AJAX calls each uploading a block, experimenting with up to 8 simultaneous uploads from the browser.

The initial results were disappointing. Eventually I figured out that I was not actually achieving parallel uploads at all. The reason is that the application uses ASP.NET session state, and IIS will block multiple connections in the same session unless you mark your ASP.NET MVC controller class  with the SessionStateBehavior.ReadOnly attribute.

I fixed that, and now I do get multiple parallel uploads. Performance improved to around 105 KB/s, worthwhile though not dramatic.

What about using a Windows desktop application to upload large files? I was surprised to find little improvement. But can parallel uploading help here too? The answer is that it should happen anyway, handled by the .NET client library, according to this document:

If you are writing a block blob that is no more than 64 MB in size, you can upload it in its entirety with a single write operation. Storage clients default to a 32 MB maximum single block upload, settable using the SingleBlobUploadThresholdInBytes property. When a block blob upload is larger than the value in this property, storage clients break the file into blocks. You can set the number of threads used to upload the blocks in parallel using the ParallelOperationThreadCount property.

It sounds as if there is little advantage in writing your own chunking code, except that if you just call the UploadFromFile or UploadFromStream methods of CloudBlockBlob, you do not get any progress notification event (though you can get a retry notification from an OperationContext object passed to the method). Therefore I looked around for a sample using parallel uploads, and found this one from Microsoft MVP Tyler Doerksen, using C#’s Parallel.For.

Be warned: it does not work! Doerksen’s approach is to upload the entire file into memory (not great, but not as bad as on a web server), send it in chunks using CloudBlockBlob.PutBlock, adding the block ID to a collection at the same time, and then to call CloudBlockBlob.PutBlockList. The reason it does not work is that the order of the loops in Parallel.For is indeterminate, so the block IDs are unlikely to be in the right order.

I fixed this, it tested OK, and then I decided to further improve it by reading each chunk from the file within the loop, rather than loading the entire file into memory. I then puzzled over why my code was broken. The files uploaded, but they were corrupt. I worked it out. In the following code, fs is a FileStream object:

fs.Position = x * blockLength;
bytesread = fs.Read(chunk, 0, currentLength);

Spot the problem? Since fs is a variable declared outside the loop, other threads were setting its position during the read operation, with random results. I fixed it like this:

lock (fs)
{
fs.Position = x * blockLength;
bytesread = fs.Read(chunk, 0, currentLength);
}

and the file corruption disappeared.

I am not sure why, but the manually coded parallel uploads seem to slightly but not dramatically improve performance, to around 100-105 KB/s, almost exactly what my ASP.NET MVC application achieves over my broadband connection.

image

There is another approach worth mentioning. It is possible to bypass the web server and upload directly from the browser to Azure storage. To do this, you need to allow cross-origin resource sharing (CORS) as explained here. You also need to issue a Shared Access Signature, a temporary key that allows read-write access to Azure storage. A guy called Blair Chen seems to have this all figured out, as you can see from his Azure speed test and jazure JavaScript library, which makes it easy to upload a blob from the browser.

I was contemplating going that route, but it seems that performance is no better (judging by the Test Upload Big Files section of Chen’s speed test), so I should probably be content with the parallel JavaScript upload solution, which avoids fiddling with CORS.

Overall, has my experience with the Blob storage API been good? I have not found any issues with the service itself so far, but the documentation and samples could be better. This page should be the jumping off point for all you need to know for a basic application like mine, but I did not find it easy to find good samples or documentation for what I thought would be a common scenario, uploading large files with ASP.NET MVC.

Update: since writing this post I have come across this post by Rob Gillen which addresses the performance issue in detail (and links to working Parallel.For code); however I suspect that since the post is four years old the conclusions are no longer valid, because of improvements to the Azure storage client library.

Embarcadero AppMethod: another route to cross-platform mobile, now with C++ support

Embarcadero has updated AppMethod, its IDE for cross-platform mobile and desktop applications. The IDE now supports C++, and as a special offer, you can develop Android phone “free forever”, according to the web site.

AppMethod is none other than our old friend Delphi, combined with the FireMonkey cross-platform framework. The difference between AppMethod and the older RAD Studio product line (current version is XE6) is twofold:

1. AppMethod does not include the VCL, the Delphi framework for Windows applications. It does let you develop for Windows or Mac OS X using FireMonkey.

2. You can buy RAD Studio outright with a perpetual license, from £1342.00 plus VAT for a new user (RAD Studio Professional). AppMethod is only available on subscription.

AppMethod pricing is per developer per platform per year. Currently this is £179.83 plus VAT for individuals (very small businesses up to a maximum of 5 employees in the entire organisation) or £600 for larger businesses (a rather large premium).

C++ support is new in AppMethod 1.14 and supports all target platforms except the iOS Simulator (an annoying limitation). It supports ARC (Automatic Reference Counting) on Android as well as iOS. Mac OS X is supported from 10.8 (Mountain Lion) and up.

There are also a few changes in FireMonkey. You can load HTML into the TWebBrowser component using LoadFromStrings. There is a new date picker component.

Another new feature is in the RTL (run time library). Called App Tethering, it lets applications communicate with each other, for example using TCP. These can be apps on the same device or remote apps. Once paired, apps can run remote actions and share standard data types and streams.

There are also updates to push notifications for iOS and Android, Google Glass support, updated OpenGL and DirectX support on Windows, and more: see here for the complete documentation of what is new.

A Quick Hands-on

I installed the latest AppMethod on Windows 8. The install warns that AppMethod cannot co-exist with RAD Studio XE6, presumably because it is essentially the same thing re-wrapped. The product name is relatively new, but there is plenty of old stuff under the covers. AppMethod still has a dependency on JSharp, Microsoft’s Java implementation for .NET. Java code in the IDE dating back to who knows when?

image

There is a 10-field dialog conforming paths for Android tools, which is a reminder of how many moving parts there are here. It is more complex that most Android development environments because it uses the NDK (Native Development Kit) as well as the usual SDK.

image

Once up and running, you can start a new project such as a FireMonkey mobile application:

image

and then you are in an IDE which would not be entirely unfamiliar to a Delphi user in 1995 (or I suppose, a C++ Builder user in 1997) – I am not saying this is a bad thing, though the IDE feels dated in comparison to Microsoft’s Visual Studio.

image

After coming from a spell of development with XAML it feels odd to have a form builder that defaults to xy layout, but layout managers are available:

image

Compile and run, and after the usual slow initialization of the Android emulator, the app appeared.

image

Why AppMethod?

In the crowded world of cross-platform mobile development, why use AppMethod?

Embarcadero makes a big play of its native development, though it is “native” in respect of code execution but not in GUI fidelity since by default visual controls are custom-drawn by the framework. This is in contrast to Xamarin (the obvious alternative for developers from a Windows background) which does no custom drawing but only uses native controls; however for raw performance AppMethod may have the edge (I have not done comparisons).

Delphi developers should also look at RemObjects Oxygene which also uses a Delphi-like language but is hosted in Visual Studio and, like Xamarin, uses native UI components.

The AppMethod approach does make sense if you prioritise maximum code-sharing over getting exactly the right look and feel for each supported platform, and need better performance or more capability than HTML and JavaScript can get you. There is no support for Windows Phone though; if that is in your plans, Xamarin or HTML and JavaScript development is a better fit.

Apple’s Swift programming language: easy coding for OS X and iOS at last?

Apple has announced a new programming language, called Swift. (There was already a language called Swift, used for parallel scripting, but Apple links to the other Swift in case you land on the wrong page. So far it looks like the other Swift has not returned the favour).

For as long as I can remember, serious Apple developers have had to use Objective-C, an object-oriented C that is not like C++. I have only dabbled in Objective-C but when I last tried it I was pleasantly surprised: memory management was no hassle and I found it productive. Nevertheless it is an intimidating language if you come from a background of, say, JavaScript or Microsoft .NET. Apple’s focus on Objective-C has left a gap for easier to use alternatives, though the main reason developers use something other than Objective-C, as far as I am aware, is for cross-platform projects. Companies such as Xamarin and Embarcadero (with Delphi) have had some success, and of course Adobe PhoneGap (or the open source Cordova) has had significant take-up for cross-platform code based on HTML and JavaScript.

I should mention that RAD (Rapid Application Development) on OS X has long been possible using the wholly-owned Filemaker, a database manager with a powerful scripting language, but this is not suitable for general-purpose apps.

Overall, it is fair to say that coding for OS X and iOS has a higher bar than for Windows because Apple has not provided anything like Microsoft’s C# or Visual Basic, type-safe languages with easy form builders that let you snap together an application in a short time, while still being powerful enough for almost any purpose. This has been a differentiator for Windows. Visual Basic is almost as old as Windows itself, and C# was introduced in 2000.

Now Apple has come up with its own equivalent. I am new to Swift as are most people outside Apple, but took a quick look at the book, The Swift Programming Language, along with the announcement details. A few highlights:

  • Swift is a type-safe language that compiles to native code using LLVM.
  • The IDE for Swift is Xcode. It supports Cocoa development (Apple’s user interface framework) via import of the existing Objective-C frameworks, which become Swift APIs via the import keyword:

import UIKit

  • You can mix Swift and Objective-C in a single project. In Objective C you can use #import to make Swift code visible and usable.
  • Swift is a C-family language and you will find familiar features like curly braces and semi-colons to terminate lines (though semi-colons are optional).
  • Swift uses reference counting for automatic memory management. There is rather complex section in the book about weak references and unowned references, to solve some of the problems inherent in reference counting.
  • Type inference is the preferred approach to declaring the type of a variable, but you can state the type if required. You can also declare constants.
  • Swift supports single inheritance for classes and multiple inheritance for protocols (protocols are more or less equivalent to interfaces in other languages).
  • There are advanced features including closures, generics, tuples, and variadic parameters. (I am not sure if “advanced” is the right word, but other languages such as C# and Java took a while to get these).
  • Swift has something like destructors which it calls deinitializers.
  • There is an interesting feature called Extensions which lets you add methods to any existing type. For example, you could extend Int with a prettyprint method and then call 3.prettyprint.
  • Swift variables are not normally nullable; they must have a value. However you can declare optional types (add a ?, such as Int?) that can be set to nil. You can also declare implicitly unwrapped optionals which can be nil, but once assigned a value cannot be nil thereafter.
  • Swift includes the AnyObject type which can represent anything.

Swift seems to me to have similar goals to Microsoft’s C#: easier and safer than C or C++, but intended for any use right up to large and complex applications. One of the best things about it is the smooth interoperability with Objective-C; this also saves Apple from having to write native Swift frameworks for its entire stack.

A smart move? I think so, though Swift is different enough from any other language that developers have some learning to do.

What difference will Swift make? Initially, not that much. Objective-C developers now have a choice and some will move over or start mixing and matching, but Swift is still single-platform and will not change the developer landscape. That said, Swift may make Apple’s platform more attractive to business developers, for whom C# or Java is currently more productive; and perhaps Apple could find ways of using Swift in places where previously you would have to use AppleScript, extending its usefulness.

If Apple developers were tempted towards Xamarin or Delphi for productivity, as opposed to cross-platform, they will probably now use Swift; but I doubt there were all that many in that particular group.

I would be interested to hear from developers though: what do you think of Swift?

Xamarin 3.0 brings iOS visual design to Visual Studio, cross-platform XAML, F#, NuGet and more

Xamarin has announced the third version of its cross-platform tools, which use C# and .NET to target multiple platforms, including iOS, Android and Mac OS X.

Xamarin 3.0 is a big release. In summary:

Xamarin Designer for iOS

Using a visual designer for iOS Storyboard projects, you can create and modify a GUI in both Visual Studio and Xamarin Studio (Xamarin’s own IDE). The designer uses the native Storyboard format, so you can open and modify existing files created in Xcode on the Mac. The technology here is amazing, since you iOS controls are rendered remotely on a Mac, and transmitted to the designer on Windows. See here for a quick hands-on.

Xamarin Forms

Xamarin has created the cross-platform GUI framework that it said it did not believe in. It is based on XAML though not compatible with Microsoft’s existing XAML implementations. There is no visual designer yet.

Why has Xamarin changed its mind? It was pressure from enterprise customers, from what I heard from CEO Nat Friedman. They want to make internal mobile apps with many forms, and do not want to rewrite the GUI code for every mobile platform they support.

Friedman made the point that Xamarin Forms still render as native controls. There is no drawing code in Xamarin Forms.

“The challenge for us in  building Xamarin forms was to give people enhanced productivity without compromising the native approach. The mix and match approach, where you can mix in native code at any point, you can get a handle for the native control, we’re think we’ve got the right compromise. And we’re not forcing Xamarin forms on you, this is just an option,”

he told me.

Again, there is a quick hands-on here.

F# support

F# is now officially supported in Xamarin projects. This brings functional programming to Xamarin, and will be warmly welcomed by the small but enthusiastic F# community (including, as I understand it, key .NET users in the financial world).

Portable Class Libraries

Xamarin now supports Microsoft’s Portable Class Libraries, which let you state what targets you want to support, and have Visual Studio ensure that you write compatible code. This also means that library vendors can easily support Xamarin if they choose to do so.

NuGet Packages

The NuGet package manager has transformed the business of getting hold of new libraries for use in Visual Studio. Now you can use it with Xamarin in both Visual Studio and Xamarin Studio.

Microsoft partnership

Perhaps the most interesting part of my interview with Nat Friedman was what he said about the company’s partnership with Microsoft. Apparently this is now close both from a technical perspective, and for business, with Microsoft inviting Xamarin for briefings with key customers.

Microsoft’s new open source direction for C# and .NET (and native compilation too): Anders Hejlsberg explains

At the April 2014 Build conference Microsoft made some far-reaching announcements about its .NET platform and the C# programming language. Yes, there was talk of C# 6.0, the next version, but the real changes are more profound. Specifically:

C# and Visual Basic have a new compiler, itself written in C#, code-named Roslyn. Roslyn is not just a new compiler; Microsoft now calls it the “.NET Compiler Platform”.

There is a new commitment to open source for .NET projects. Microsoft formed the .NET Foundation to oversee existing open source projects, including  ASP.NET, Entity Framework, the Azure .NET SDK, and now Roslyn as well. “When it comes to development projects we are going to operate from the premise that open source is the default. Unless there are reasons why it does not work,” said C# lead architect Anders Hejlsberg.

image

Note that open source does not mean chaos. It does mean that you can fork the project if you want – the Roslyn license is Apache 2.0 – but getting Microsoft to accept new features you have contributed will not be trivial. Hejlsberg makes the point that language features are easy to add, but impossible to take away, so extreme care is necessary.

Microsoft is also supporting cross-platform C# to a greater extent than it has done in the past. The most obvious sign of this is its cooperation with Xamarin, which provides C# compilers for iOS and Android. Xamarin’s Miguel de Icaza got a top billing at Build, and is also involved in the .NET Foundation.

There is more though. The idea of standardised C# is re-emerging:

“The last ECMA standard was C# 2.0. There wasn’t a lot of demand for it, but that demand has recently risen and we have re engaged with the ECMA community to produce a standard for C# 5.0,” said Hejlsberg.

This bears some unpacking. Why was there little demand for ECMA C#? Partly I would guess from the assumption the C# was firmly in Microsoft’s grip, with Java the obvious choice for cross-platform development. The main interest was from the Mono folk (Miguel de Icaza again), which implemented .NET for Linux and the Mac with some success, but nothing to disturb Java’s momentum.

The focus now though is on mobile, and interest in C# is stronger, mainly from Microsoft-platform developers reaching beyond Windows. There is also Unity, which uses C# as a scripting language for developing games for multiple platforms, including iOS, Android, Windows, Mac, Linux, Xbox, PS3 and Wii – PS4 is coming very soon.

Microsoft has now consciously embraced multiple platforms, as evidenced by Office for iOS as well as the Xamarin collaboration. “We want C#developers to build great applications across different form factors and different device platforms,” said Jay Schmelzer Director of Program Management for Visual Studio.

You might observe that this position has been forced on the company by the rise of iOS and Android, a view which likely has some merit, but the impact it has on C# and .NET itself is still real.

I asked Hejlsberg to unpack the difference between the Roslyn project and C# 6.0, bearing in mind that both are covered on the Roslyn open source site; you can see the current status of C# 6.0 and the next Visual Basic here.

Roslyn is the name for the project that encompasses the new C#compiler and the new VB compiler and the new language services that they share. C# 6.0 is the name of the next version of the C #language which will have a specification and which will have an implementation. We are implementing C# 6.0 on the Roslyn platform. We are not going to continue to evolve our old C++ C# compiler – the C# compiler was originally written in C++ and has been evolved up through C# 5.0. That is where we are going to retire that code base, and going forward versions of C# will be built on Roslyn and therefore will be built open source. Unlike previously where, boom. C# came down from the sky with a set of features, it is going to happen more organically now, people will submit pull requests, open up issues, and you will see us work on these features. You will see them from inception to fruition.

“The C# team, the Roslyn team, the VB team, their day to day workplace now is the open source site. That is where they check-in code. It is a community in the making.

Even that is not all. At Build, Microsoft also announced .NET Native, which is a native compiler for C# and Visual Basic, now in preview for x64 Store apps. What is the difference between .NET Native and the existing NGen native compiler for .NET? Over to Hejlsberg:

NGen is the native feature that we currently support. NGen is really, “I’m going to JIT [Just in time compile] your code and then snapshot all the data structures and dump them in a file so that I can quickly rebuild that file later when you run this particular application”. But it is the same code generator and all the same features, and JIT is still there. NGen is really a way to pre-cache the JIT output and therefore get better performance, but it adds to the size of your app because you still have all the assemblies and metadata and then the NGen image as well.

.NET Native is a completely different approach. Instead of the JIT we use the backend from the C++ compiler. You can think of it as a linker that takes as input assemblies, and as output produces a PE [Portable Executable] executable. In the process this linker or code generator will analyse all the IL [Intermediate Language] that goes into the application and it will apply a thing known as tree-shaking where it eliminates all of the code that will never execute based on known execution roots.

In other words, the public static main of your program and also whatever pieces of your app that you designate as reflectable, they also become roots. Based on that we produce an optimised exe, and into that exe we link the pieces of the framework that you are referencing. We link in a garbage collector [GC], and it looks to the operating system just like an exe. When you run it, it runs a local GC in there and it is as efficient really as C++ code.

There are some restrictions associated with .net native, mainly that you can’t just willy-nilly reflect on the whole world. You can’t just generate new code and ask for that to be jitted because they may not be a JIT compiler. We are considering allowing you to link in a JIT compiler, but there are certain execution environments which don’t permit jitting, like Xbox. If you use reflection in your lap you have to tell us what to keep reflectable, because otherwise we will optimise it away.

According to Schmelzer:

The preview out today is scoped to Store app x64 and ARM. We haven’t run into any technical limitation that shows it can’t be done across the breadth, it is just a matter of request and need.

Open source, native code compilation, and an innovative compiler: it adds up to huge changes for C# and .NET, positive ones as far as I can tell.

The Xamarin connection is intriguing though. Developers in general admire the technology as far as I can tell, but it is expensive, and paying out for a Xamarin subscription on top of maybe MSDN for Visual Studio is too much for some smaller organisations and does not encourage experimentation. Might Microsoft acquire Xamarin and build Visual Studio into an IDE targeting all the major mobile platforms, but with special hooks to Azure-hosted services?

That prospect makes sense to me, though it would be a shame if the energetic Xamarin culture became bogged down in big-company bureaucracy. Currently though: no news to report.

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

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.

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.

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.

Microsoft Build goes nuts over Xamarin’s C# and .NET for iOS and Android

Xamarin’s Miguel de Icaza was booked for a standard session room at Build, Microsoft’s developer conference in San Francisco, but the session was moved to the keynote room because of demand. I am not sure how the likely demand was calculated, but it was possibly something to do with the event app that lets attendees plan their agenda.

It was just as well that the session got moved.

image

The attendance at the session mirrored my observation that Xamarin’s stand in the third-party partner exhibition was drawing more attention than any other. Xamarin’s tools let developers port applications to iOS and Android while still using C# and the .NET Framework.

image

I am not sure what to conclude from the obvious high level of interest in compiling apps for iOS and Android. You can interpret this as good news for Microsoft, in that it keeps developers working in .NET and with easy access to the libraries that support Microsoft services; or as bad news, in that it shows how many developers are moving towards non-Microsoft platforms in their app deployments.

It was the second time today that de Icaza appeared on the keynote stage. Earlier he stood there with Anders Hejlsberg, the author of C#.

image

It has been a long journey, from the time when Mono (the open source implementation of .NET founded by de Icaza) was viewed with distrust by Microsoft (as far as I could tell), as an open source competitor to the official version.

Now there is talk of whether Microsoft might acquire Xamarin – of which there is no news here at Build, I should emphasise.

Anders Hejlsberg says C# 6.0 to use Roslyn compiler, coming in next Visual Studio after VS 2013

A disappointment at Microsoft’s Build conference last month was lack of news about the next version of C#, version 6.0. C# architect Anders Hejlsberg did present a session, but it was on TypeScript, a language which compiles to JavaScript.

Aside: Hejlsberg talks about the new Xbox music app in Windows 8.1 (and Xbox One) which is written in JavaScript. It is a large app with 500,000  lines of code, and new features are now implemented in TypeScript (30,000 lines so far).

However, Hejlsberg did also talk about C# 6.0 at Build, during this Channel 9 Q&A, though you have to scroll through to reach the C# content (about 34 minutes in).

image

He confirmed that C# in Visual Studio 2013 is the same as before, but there will be new previews of the forthcoming “Roslyn” compiler soon, and that C# 6.0 will be in the “next Visual Studio after” which suggests Visual Studio 2014, presuming Microsoft sticks to its annual release cycle.

“We are at a point where the Roslyn compilers are done,” he said.

Roslyn, Hejlsberg explained, is the new compiler for “C#, and VB, and the language services in the IDE.”

Roslyn performance will be at least as good as the existing native compiler, says Hejlsberg. It is better suited to parallel processing so will take advantage of multi-core machines, “particularly for large projects.”

You can read more about Roslyn here. Microsoft describes it as “opening up the Visual Basic and C# compilers as APIs.” Practical benefits include features like instant porting of VB code to and from C#, and the use of C# and VB as macro languages within a .NET application.

Hejlsberg also says that Roslyn will enable a faster pace of evolution for C# in future.

Another aside: Xamarin, which provides a compiler for C# targeting iOS and Android, gets a nod of approval from Hejlsjberg. “I’m a great fan of their work,” he says.

Blogger (and former Microsoft Excel developer) Wesner Moise provides a transcript of the key points.