Unit Testing Universal Apps

Learn by testing

Testing your code always shows up unexpected facets of that code. Attempting to test Universal Apps shows up how far Microsoft still has to go in developing a common platform for Windows and Windows Phone apps.

Universal Apps shared code

Universal Apps was the major developer announcement at Build 2014; “as a developer, this means you can now build XAML and HTML universal apps that run on both Phone and Tablets by sharing a significant amount of code and content”.

Excellent I thought, I can write code once for the functionality shared between my Windows and Windows Phone apps.

Unfortunately the method by which universal apps share code makes this code un-testable. Although universal apps contain a “shared” folder this does not result in any binary output and is incorporated by Visual Studio during the build of the individual Windows and Windows Phone apps by a mechanism that is essential the same as “add as link”. This is one step up from “cut and paste inheritance”.

The reason for this is that, even when the classes have the same name, the RT (Windows Runtime) used by Windows and Windows Phone are different and so the “shared code” has to be compiled against the relevant assemblies at build time.

You could test the code in the shared folder by creating a standard unit test assembly and using “add as link” to include that code but that is too ugly a mechanism to consider seriously.

Back to Portable Class Libraries

To share code that is testable, and there shouldn’t be any un-testable code, the common functionality needs to be in a portable class library and Visual Studio now contains a project template for a “Class Library (Portable for Universal Apps)”. There is, however, no corresponding template for unit test project. The standard unit test project will not reference the Universal Apps portable class library.

To produce a test project you have to use the “Unit Test Library (Windows)” template from the “Store Apps” folder. This template is actually a Windows App project and includes a manifest file, key file and Images folder in addition to unit test class you are actually interested in.

The lack of a clean unit test template shows that Visual Studio’s support for Universal Apps is unfinished. Hopefully this will be rectified in the next update.

What use is the shared code mechanism?

In its present incarnation I am not convinced that the “shared code” for Universal Apps gives developers anything that cannot be achieved using portable class libraries. Indeed the lack of a testing mechanism makes it a step backwards.

Microsoft’s guidance for writing this shared code makes much use of conditional compilation (WINDOWS_APP / WINDOWS_PHONE_APP) to isolate platform specific calls. Again I think this is a step backwards compared to inheriting from classes in the portable library to implement these calls within the respective Windows and Windows Phone apps.

Unfortunately until Windows and Windows Phone apps do share the same RT assemblies than writing “Universal Apps” is going to involve these unsatisfactory code sharing steps.

Convergent Mobile Development

Convergence is key to Microsoft’s mobile strategy.

This convergence occurs at multiple layers. For end uses it is the convergence of the UI between Windows 8 and Windows Phone though the “Modern App” (aka Metro) design principles. At the core it is the switch to the NT kernel for Windows Phone 8.

For developers convergence is a more complicated.

XAML can not be shared between platforms because the namespaces and widgets used by Windows 8 are different from those used by Windows Phone 8. This leaves convergence though shared code and currently Microsoft is encouraging the use of the Portable Class Library platform to enable this.

However what can be currently shared using the PCL is quite small, often limited to the business model. This is because WinPRT (Windows Phone 8)  is not the same as WinRT (Windows 8). Whilst this is likely to improve in future releases there is a more fundamental  issue.

The preferred language for Windows 8 app development is JavaScript / HTML. Apart from Maps all the core Window 8 apps have been written in  JavaScript to take advantage of the hardware acceleration this enables. The language for Windows Phone 8 development is .Net. As a result code convergence using the PCL would seem to result in under optimised Windows 8 apps  

Mobility, Is Microsoft going in the right direction ?

The forthcoming release of Windows Blue is an implicit admission that Microsoft has got Windows 8 / RT wrong and has once again missed the target when it comes to mobile devices. It raises the question as to why Microsoft keeps getting mobile wrong.

This failure is even stranger when you consider that Microsoft could legitimately claim to have helped create the environment they are now unable to come to terms with. With Windows Mobile they effectively invented the smart phone. The first Windows Mobile devices defined the core functionality and usability that is now standard for phones and tablets. The only exception was the stylus, a hardware solution to a software problem, but even that is making a comeback with devices such as the Galaxy Tab. However having helped created this new device and application space Microsoft then allowed the version 1 iPhone to completely overshadow the, by then, version 6 Windows Mobile.

Since then Microsoft have been playing catch-up with iOS and Android based devices. Though it may be too late, Windows Phone is beginning to gain a following but with Windows 8 Microsoft seems to have missed the target again. Watching TechEd 2013 it is clear that Microsoft’s solution is to emphasise the integration of Windows 8 into the enterprise environment through Active Directory and Intune. Whilst this may help IT managers struggling to deal with issues caused by the growth of Bring Your Own device it is not clear that will significantly improve Windows 8 market share. Integration into the business environment is also increasingly central to Windows Phone marketing.

The problem is that Microsoft is locked in a desktop mind-set despite what it says about mobility and the impact of the cloud. It is treating tablets as a scaled down desktop computers rather than a scaled up smart phones. Key to this is emphasising integration of phones and tablets into the corporate environment.

Is this the right direction to go?

Probably not; the growth of smart phones and tablets has been driven by consumer demand not business requirements. BYO is being forced on business by employees. Enabling these devices to be managed in the same way as enterprise computers solves the problems BYO cause business but adds nothing for consumers. Windows Mobile 6 had great enterprise integration but that did not stop users switching to iOS or Android devices.

Windows 8 and HTML/JavaScript

Until recently I had taken at face value Microsoft’s claim that in developing Windows RT apps (aka ‘Windows Modern’, previously known as ‘Metro’) there is a level playing field between .Net/XMAL and JavaScript/HTML.

I had presumed that the support for JavaScript/HTML was introduced to enable web developers to utilise their existent skills to develop  Windows 8 apps. This made sense given that Web developers far outnumber those exclusively writing in .Net languages. 

I now doubt this.

All Microsoft Windows 8 apps, with the exception of Maps, have been written in JavaScript and HTML. Within Microsoft JavaScript/HTML is the preferred (mandated) language for future Windows 8 app development. I suspect that this will also become the case for Windows Phone development as the convergence between Windows 8 and Windows Phone 8 continues.

Why is this ?

The key fact seems to be UI performance, particularly on ARM based devices. Using JavaScript/HTML enables apps to benefit from the hardware acceleration used by Trident, Internet Explorer’s rendering engine. 

Below the UI layer there are problems with using JavaScript due its performance and lack of features such as threading and data binding. However these are mitigated by the use of the WinJS library. Also some Microsoft Apps use C++ DLLs to implement the non-UI functionality with access from the UI layer via JavaScript’s interop support.

As an aside, one sign of the importance Microsoft is attaching to JavaScript/HTML as the preference for Windows 8 app development is that the author of the Microsoft Press book on the subject is Kraig Brockschmidt. Those with long memories will know Kraig from “Inside OLE” from the time he was central to a previous seismic change to the Windows programming model.

Given the skill set of Microsoft’s existing Windows desktop and Windows Phone developer community it is not surprising that Microsoft has not made their preference for JavaScript/HTML explicit. However third-party developers should start considering how they develop Windows 8 apps in the future and keep an eye on the implications of this for Windows Phone development.

Identity columns and the real world

The canonical design of a database table is to have a primary key that is either a GUID or an integer. If the key is an integer it is often also an identity column.

Good for database performance but totally useless for real users. 

Consider the the ASP.Net membership provider. The key in all the tables used in the system is  UserId which is an integer.

The user, however, knows nothing about this ID and for him or her what is unique in the login credentials is his or hers user name.

The  ASP.Net membership provider actually stores the user name in the UserProfile table and the password in the separate webpages_Membership table. The uniqueness of the user name is not part of the database schema but is enforced by the controller which checks for existing user names when registering a new user. In fact the entire membership system behaves as if the user name is the primary key rather than the user ID so, for instance, the user’s security principal contains only the user name and not the user ID.

The reason for this database schema is to maximise the efficiency of foreign key lookups based on integer rather than nvarchar columns but the result is a schema that is at odds with the real world.

A classic case of the engineering model having a faulty relationship with the domain model and one that is repeated when ever columns that have no real world existence are used. 

Loading one-to-many data with the Entity Framework

Technorati Tags: Software Development,Entity Framework

The guidelines for use of the Entity Framework suggest that traditional SQL constructs such as Join should be avoided in preference to EF specific features such as projection.

When dealing with one-to-many relationships the relevant features are the use of collections in the primary entity and the use of Include to load secondary entities.

There are, however, issues with loading secondary entities as it is not easy to restrict or order the loading of related data.

Domain model

The business domain used to illustrate the discussions within this article is a simple project planning web application with a chain of 1 to N relationships; Project -> Feature -> Story -> Tasks.

As an example consider the following code first definition of the Feature entity;

public class Feature {

public Feature() {

Stories = new List<Story>();

}

public int FeatureId { get; set; }

public virtual List<Story> Stories { get; set; }

…

Displaying related data

The simplest form of a page listing entities uses a grid with paging.

This enables the efficient display of pages of data with the minimum of data being retrieved from the database and transmitted to the browser.

This is achieved by using Skip and Take to page forward and return a page worth of data respectively;

_repository.Projects

.Skip(pageSize * (pageNumber – 1))

.Take(pageSize).ToList()

However there are two problems in using this to display secondary data related to the primary entity.

Firstly related data returned by the Entity Framework as a result of the Include statement is unordered.

Secondly there is no mechanism for paging this secondary data.

There are two options for dealing with these problems; either allow the Entity Framework to return all the related data and then order and page this data or do not include related data when querying the primary entity and the make a second call to load ordered and paged secondary data.

Using ‘Include’ when querying the primary entity

If the entity Feature contains a set of related Story entities the related entities can be loaded in one database call by using the Include statement in the query

Feature feature = _context.Features

.Include(f => f.Stories)

.Where(f => f.FeatureId ==featureId)

.SingleOrDefault();

Whilst efficient in making a single database call it is inefficient in returning all the Story entities related to the primary Feature entity and in the requirement for subsequent processing to order and page these entities.

For instance;

feature.Stories = feature.Stories.OrderBy(s => s.StoryTitle).ToList();

Using a secondary query to load related data

The alternative is to make a second database call explicitly ordering and selecting the related entities;

Feature feature = _repository.GetFeature(featureId);

List<Story> selectedStories =_repository.Stories

.Where(s => s.FeatureId == featureId)

.OrderBy(s => s.StoryTitle)

.Skip(pageSize * (storyPage – 1)

.Take(pageSize)

.ToList();

feature.Stories = selectedStories;

The problem with this is that the Feature entity still has a collection of Story entities.

When the query returning the primary entity does not have an ‘Include’ statement that entity’s collections of related entities consists of proxies to support lazy loading.

If an ‘Include’ statement was included in the query then the collections consist of instantiated related entities.

In either case modifying these collections affects the in-memory representation of the database. This has side effects with latter modifications of the entity data. Indeed the use of the secondary query only results in the required behavior if the collection is cleared before assigning the new list.

List<Story> selectedStories = query.ToList();

feature.Stories.Clear();

feature.Stories = selectedStories;

Clearly the proxies are still in memory and are lazy loading the original collection on top of those resulting from the secondary query.

This is a warning about meddling with the internals of the Entity Framework and suggests that the use of secondary queries should be avoided despite their efficiency in data retrieval from the database.

The importance of a ViewModel

The dangers of modifying Entity Framework objects to achieve sorting and selection of related entities can be avoided by using a ViewModel. All the secondary data is returned in the Entity Framework query and this is then sorted and selected into a ViewModel that contains its own definition of the entities involved.

Although this appears overcomplicated for simple domains it removes the Entity Framework proxies from interacting with subsequent processing of the returned data.

How useful is “Include”?

The Include statement is the preferred method of loading one to many related data at the same time as the primary entity is loaded. However there are potential inefficiencies in not being able to order or restrict the loading of the secondary entities. This becomes more pronounced as the number of secondary entities increases.

However attempting to bypass one-to-many relationships in the domain model is itself problematic and undermines the arguments for using the Entity Framework in the first place. Unless the amount of data involved is high it would appear that the safest solution is use “Include” and then order and page the secondary entities returned by the initial query, preferably using a separate ViewModel representation of the domain entities.

Such processing is only possible if “Include” is used to force eager loading rather than relying on lazy loading by the Entity Framework proxies.

Code First

Code First modeling has been used in this discussion but the issues also apply to Database First modeling.

Lichtenstein – Tate Modern Retrospective

The Tate Modern is currently showing the first major retrospective of Lichtenstein’s work since his death in 1997.

The question about “Pop Art” has always been “is it art ?”.

To some extent a meaningless question, but two paintings included in the exhibition suggested an answer to me.

The first was Lichtenstein’s reflection on the art of Mondrian. This is beautiful and has the same impact as the works of Mondrian himself. However that impact is Mondrian’s not Lichtenstein’s. Adding stencilled dots to two of the white panels adds nothing.

The second picture his reflection on Chinese landscapes, the “Landscape with Philosopher”.  Again this is beautiful but the beauty is that of the original not Lichtenstein’s. The fact that it took 15 different sizes of stencils to reproduce the exquisite shading of Chinese art is a feat of draftsmanship but does not, I think, say much more.

Walking around the exhibition it occurs to me that Lichtenstein was saying something about art in the time of mass produced images but contributing little to that art. More importantly if “Look Mickey” is art than so is, possibly more so, the comic illustration it was based on.

Technorati Tags: Culture