0 Comments

NetStandardLogo

The wait will soon be over and we will all be able to use .Net Standards for sharing all our code across .Net run-times. But for the current time we are still in a transition state, not all libraries support .Net Standard out of the box. One option would to rely on good old Portable Class Libraries (PCLs) for now. But the PCL comes with many restrictions compared to a .Net Standard library. Plus .Net Standard is where all the action is (and will be) happening. So it seems like a no brainer to choose .Net Standard as our library container to share code.

But what when we are using a library that does not support .Net Standard out of the box? For instance let’s say we want to use Reactive UI as our MVVM framework for a Xamarin.iOS and Xamarin.Android app. When trying to add Reactive UI version 7.4.0 (latest stable version as of writing) via NuGet to our .Net Standard Project. We get the following error message:

Error message that .Net Standard library is not among the supported .Net Frameworks of this NuGet package

The solution to our problem is to define the required targets in our .Net Standard Project. The targets which the Reactive UI NuGet package defines. We can edit a .Net Standard library by right clicking on it in Visual Studio and selecting Edit Project name:

Right-Click menu showing the edit option of a .Net Standard Project

Now we can define the targets by adding the PackageTargetFallback line to our DotNetStandard.Core.csproj file:

Providing the targets provides NuGet with the information needed to install the package. Rerunning the NuGet installation once more leads to a success Smile

Successfull installation of Reactive UI after changing the project

Conclusion

.Net Standard is the future of writing .Net Libraries which runs on multiple .Net runtime Environments.

Happy coding and don’t let those not-yet ported libraries stop you from achieving your goals!

0 Comments

PureLayout is a library for iOS developers that allows to create UI views in code behind with ease. With PureLayout.Net this option is now available for Xamarin.iOS.

Since PureLayout.Net is based on the idea of defining your UI in code you might be tempted, especially as a C# developer, to dismiss it as an utterly bad idea. Because defining UIs in code is such a no-no right? Well actually no, not under iOS. The standard approach under iOS is to use the Storyboard to define your UIs and your screen flow. This is great at first since it is very much like Windows Forms with all it’s drag and drop goodness. The problem arises in two areas:

  1. Having more then one person editing the Storyboard
  2. Sharing standard values such as Margins over the entire UI

TL;DR;Define your UIs in a reusable way that allows to share design standards and reduce duplication within UI work. Enable collaboration on UIs without the fear of merge conflicts by using PureLayout.Net. Which you will be able to use in no-time.

Since the storyboard is one large (generated) XML file. Any change to the UI is stored in a single location. In a larger project this will mean that whenever two or more people will want to make changes to the UI a merge conflict could arise. Should a merge conflict arise… Well to put it short you are out of luck. Since the XML gets generated it is not human friendly to merge. An error while merging will result in the entire UI of the app being in tatters. Now one could mitigate this problem to a certain degree by using XIBs. But those come with some extra glue code to get it running. Plus there is still this second point.

If you are working on a larger app, you will (want to) have some sort of a style guide. In it you will define a set of defined constants for your colours, margins, text sizes, fonts etc.. Going with the Storyboard or XIB designer will not provide you with a central coded style file. The only way to define and distribute the style is in a written text document such as a Word-, PDF-File or a Wiki page. This approach comes down to every one, who works on the UI, needing to know this document. The current version may I add and apply the styles. This can be a challenge to say the least.

All this can easily be avoided by using PureLayout.Net. - Which I hope does not come as surprise at this moment Winking smile

Where to get it

Simply add the NuGet package to your iOS project and you will be all set:

Install-Package PureLayout.Net

How to get started

A getting started guide can be found on the projects GitHub page.

Thank you

I would like to point out that PureLayout.Net is only a wrapper around the existing PureLayout library written Objective-C. Therefore a big thank you to Tyler Fox the creator and Mickey Reiss for currently maintaining the library.

Further I would like to thank Samuel Debruyn for helping me a lot on the topics of wrappers with his blog post.

0 Comments

Zurich Xamarin User Group Logo

I had a great time on Thursday the 15. September 2016 at the Xamarin User Group in Zurich. Though having a little struggle with the latest updates which seemed to have a “minor” impact on my UI Tests to run on Windows i.e. Visual Studio I had a great time presenting and some interesting questions to chew on during answering.

Image of my talk at our great location at the impact hub.

After the Meetup there was the typical Pizza, Sweets, Beer, Water discussions that always spawn some new insights on topics. I want to thank all those who came to the talk and I’m looking forward hopefully seeing you dear reader at one of the upcoming Xamarin Meetups in Zurich.

Image of a Pizza - which made me hungry while just looking at it... well done to past-mark...

Plus I am thrilled to announce that I’m now a Co-Organizer of the Meetup together with Thomas Charrière and Reto Senn. So if you have any topics you would like to present or see presented be sure to reach out to me via  Twitter or just write a comment down bellow. If you simply wish to support our effort by providing some beverages do neither hesitate to contact me or one of my co-organizers Winking smile

Talk Content

You can find my slides here and the code on GitHub.

0 Comments

image

In this post we will look at how we can write UI tests for a Xamarin.Android app. The app which we are testing is a basic app based on the MVVM pattern. You can find a detailed blog post on the in and outs of the app under test here.

Assuming you already have a Xamarin Test Cloud (XTC) project added to your solution. As described in this former post. Lets get started by preparing the app for UI testing.

Enabling your Android app for the XTC tests

You do not have to do anything to enable your app to be compatible with XTC. That being said when writing a test with Xamarin Test Cloud. The test should not recognize a control by the content it is displaying. Rather it identifies a control via an ID which is not visible to the end user but rather a invisible ID. Setting this ID is best done via the accessibility label attribute. You can set this in the AXML code of your view i.e. control:

This ID will not have to change if the locale changes. Even if the location of the UI element changes it will still be found by the test. Thus IDs should be generally used to identify controls as they allow for higher resilient test code.

Writing Test(s)

After tuning our the UI code we can start writing the test. One way is to use the XTC recorder. While this tool brings a great benefit when starting off with or smaller apps (as it would be the case in this post). I usually prefer to use the REPL which is easy to use and can be invoked at any point in the test code.

When the UI is prepared accordingly we can start writing the test. One way is to use the XTC recorder. While this tool brings a great benefit when starting of with or smaller apps (as it would be the case in this post), I usually prefer to use the REPL which is easy to use and can be inserted to be started at any point in your code.

The REPL is especially useful once you have a large testing framework. Having a framework i.e. helpers in place you can run those before firing up the REPL. So you can start exploring and interacting with the UI right were you need to.

XtcTreeWithIds_thumb

Starting the REPL is as easy as adding the following line to your test method:

You can see the entire apps visual tree outlined.

Now we can define the steps we want to perform in our test:

Note how the test takes screenshots at every stage. This allows to easily identify the steps on the Xamarin test cloud and give them a label. While this might seem to be a bit of an overkill for such a small sample. When writing larger tests naming your steps i.e. screen shots will help you narrowing down where an error is happening.
One good thing about the tests is that they also run well on your local machine. So using e.g. the al Studio we can execute the tests over the NUnit Runner:

shows resharper testrunner in visual studio after executing a test

You can choose to run the tests on an emulator or device as you like. Just select the desired target as you would when starting the application. Or submit it to the test cloud i.e. integrate it in our build process.

Conclusion

This post described how to get started writing automated UI tests with Xamarin Test Cloud for a Xamarin.Android. Showing you how to adopt your UI for writing resilient test. Based on NUnit the tests are running on a stable and battle proven foundation.

Keep in mind that UI tests should not be the only testing you rely on for testing your app. But in combination with Unit and Integration tests they can provide great value to your project. Running them on Xamarin Test Cloud allows you to run them on a sea of devices. Along with different versions of Android i.e. vendor flavours.

You can find the entire sample on GitHub.

0 Comments

Title image showing the xamarin test cloud and ios logo

In this post we will look at how we can test a Xamarin.iOS app which is based on a storyboard. The app which we are testing is a basic app based on the MVVM pattern. You can find a detailed blog post on the in and outs of the app under test here.

Assuming you already have a Xamarin Test Cloud (XTC) project added to your solution as described in this former post. Lets get started by preparing the app to be tested.

Preparing the iOS for the XTC tests

When writing a test with Xamarin Test Cloud the test ideally does not recognize a control by the content it is displaying but rather via an ID which is not visible to the end user but rather a invisible ID. Setting this ID is best done via the accessibility label attribute which can be set in the storyboard under properties:

Shows where under properties the label can be enabled.

This ID will not have to change if the locale changes or the UI element is moved to a different location and therefore will allow you to write more resilient test code.

Writing Test(s)

When the UI is prepared accordingly we can start writing the test. One way is to use the XTC recorder. While this tool brings a great benefit when starting of with or smaller apps (as it would be the case in this post), I usually prefer to use the REPL which is easy to use and can be inserted to be started at any point in your code.

The REPL is especially useful once you have a substantial testing framework written because it allows you to execute it after executing some prearranged steps to get to a certain point which you would like to test.

Shows repl output of the app

Starting the REPL is as easy as adding the following line to your test method:

You can see the entire apps visual tree nicely outlined.

Now we can define the steps we want to perform in our test:

Note how the test takes screenshots at every stage. This allows to easily identify the steps on the Xamarin test cloud and give them a label. While this might be a bit overkill for such a small sample on larger tests when named right the steps and screen shots will greatly help you narrowing down where an error is happening.
One good thing about the tests is that they also run well on your local machine. So using Xamarin Studio on a Mac we can simply execute the tests over the NUnit Runner:

image showing the nunit test runner of xamarin studio.

Or submit it to the test cloud i.e. integrate it in our build process.

Conclusion

This post described how to get started writing automated UI tests with Xamarin Test Cloud for a Xamarin.iOS application. After some minor adjustments to the UI a test can be written using the familiar NUnit testing framework. Keeping in mind that UI tests should not be the only testing you apply to your app since they are rather slow, they do bring a lot of value when used properly since one can easily run the tests on different devices and iOS versions with the Xamarin Test Cloud.

You can find the entire sample on GitHub.