Cake build issue reporting with PRCA

28 Aug 2017 | Build Cake
I have covered Cake build in one of my talks I did for a local user group I participate in Copenhagen. However, most of that just explained what Cake build is. If you are reading this and have no idea what Cake build is, I highly recommend looking at the Cake homepage and also watching this introduction by Gary Ewan Park, which explains very well what is great about Cake.

Once you have set up your Cake build, you may wonder how to process all the warnings and issues that MSBuild throws at you. You may also be running the ReSharper command line analysis tool which finds issues with your code. How do you combine all these results and report them or go through them to figure out what is going on?

Pascal Berger has written some great add-ins for Cake, which helps you with this, called Pull Request Code Analysis (PRCA). Let's try set it up for both MSBuild and ReSharper code Analysis.

Add-ins and tools

In your build script you need to add a couple of tools and addins.


In the snippet above, we start by adding the ReSharper CommandLineTools, for analyzing with either the default ReSharper rules or one or more rule sets that you have defined for your solution.
We also add MSBuild Extension Pack, which allows us to use an XML file format that PRCA knows how to parse. The default logging format does not work.

Then we add the relevant PRCA addins. In this case I am only interested in catching issues with my code. However, PRCA also supports reporting the issues it finds into TFS/VSTS pull requests.

MSBuild

Having added the required add-ins and tools for all this to work. Let's add some settings to our MSBuild, such that it can log the build in the format PRCA understands.

Here the important parts is the call to WithLogger, which sets up file logging to XML. The rest is up to you to figure out. I like to pass along the configuration as arguments in my scripts, which is where the configuration and platform variables come from. In this case we are logging to msbuildLogPath which is up to you to decide where is. It could for instance be in an artifacts folder.

ReShaper Inspect Code

Now let's add some static analysis into the mix and lets get some results from the ReSharper CLI tools. A ReShaper license is not required to use the CLI tool, so there is basically no reason not to use it if you want to improve your code.

The CLI tool just like the plugin for Visual Studio also supports extensions, which is great for adding additional analysis. This can help you catch spelling mistakes and other cool additions through the extensions.


We pass along similar MSBuild properties as we did in our build. The Profile property here is the ReSharper settings file. You can configure multiple layers of settings here, similarly to what ReShaper allows you in the VS extension.
I have chosen not to throw exceptions when finding violations, so I can report them at the end of a build if the rest of it succeeds. You can see I added a couple of extensions in the Extensions property. One for checking spelling and ensuring async suffix on async methods.
An important note here is the contents of ArgumentCustomization. On my environment, the CLI tool seems confused about which MSBuild version to use. Even though the documentation claims to always use the latest version, it still picked up an old version. Hence, I had to specify --toolset=15.0 myself to make it work.
The InspectCode tool takes a little while to run. In my case here it dumps the results in a log file at inspectReportFilePath. Just like with MSBuild, you could put that in artifacts or where ever you like.

Reading issues

Now to tie this blog post up, we now need to read the issues logged from both the build and the ReSharper code inspection. This is what PRCA excels at.


Here I simply check existence of the msbuild log and the code inspection report and run the ReadIssues tool. From this I get a IEnumerable<ICodeAnalysisIssue> which gives you the path to the file where the issue is in, the line, the message, which rule it violates and url to the rule documentation. From this you can get a very good idea about how to resolve the issue being reported.

There are plans on adding tools to create reports in various formats from this enumerable, currently you need to do something about the issues yourself, which highly depends on the environment you use to report issues, make pull requests etc.
If you are using TFS/VSTS there are built in methods to report these. More information can be found in the PRCA docs.

When you run the PRCA tool it will look something like this in your cake output.
As you see this project I've run it on has a lot of issues 😢

LiveXAML and Xamarin.Forms

15 Aug 2017 | Live Preview Xamarin.Forms
Full disclosure. This blog post is sponsored by LiveXAML. I was sent a free license to try it out and mention it in a blog post. All opinions are my own and I was not paid to say nice things about the product.
I do not usually work with Xamarin.Forms, but Mihhail from LiveXAML contacted me and asked whether I wanted a license for LiveXAML to test out and mention them in a blog post. I thought "why not", and here are some brief thoughts and experiences with the tool.

First of all, LiveXAML is not the only product on the market. There are other players, such as Continuous, Gorilla Player and now Xamarin also have their Live Player. They all function a little bit different from each other, but their goals are very much the same. To show changes in the UI, while you are writing code.

I tried LiveXAML with the following setup:
  • Visual Studio 2017 15.2
  • Xamarin.Forms 2.3.4.247
  • LiveXAML 1.2.12
  • Android x86 7.1 image running in a Hyper-V VM
The project I worked with LiveXAML in was a sample project, where I have a ListView showing some images and names of cheeses. All the code was contained in a PCL. To get LiveXAML working I simply installed the Visual Studio 2017 extension. I also installed the LiveXAML NuGet into the PCL project.
For projects using Shared projects, you need to install LiveXAML into your application projects, which consume your Shared project.

This is basically it. Once the very small setup is done, you are ready to play around. Just start debugging your application. Fire up a XAML page and start editing. Every time you press save, LiveXAML will pick up the changes and they will quickly be reflected in the UI in the App.


See the video above to see it in action. In this video I edit some simple XAML, where I change the height and width of the images, then apply a transformation to add rounded borders. Every time I press CTRL + S to save, the emulator updates the view, which is super usefull when playing around with UI in XAML.

LiveXAML seems to work pretty well and seems stable, I only tried it in a Xamarin.Forms Android project, but the LiveXAML web page says that iOS projects work as well. There is also some preliminary VS4Mac support for those of you who use that. It installed and ran fine in an emulator, that is not mentioned as supported on the web page, which is great. It ran with external assemblies, in this case FFImageLoading, where images and transformations where shown correctly. To me it seems that any valid XAML will work with LiveXAML and be rendered on the device!

The difference between LiveXAML and Xamarin Live Player, is that with the former, you install a server in your app, which a plugin in Visual Studio can send commands to. So when saving your XAML it sends a payload which then is rendered on the screen.
With Xamarin Live Player, you don't add dependencies to your app. However, instead you install an App on your device you want to run on, then there is a pairing process with the IDE. Running the app, it seems like it is running inside of the Xamarin Live Player app and changes to any part of your code is reflected. This works with coded UI as well.
Like LiveXAML, Gorilla Player seems to be limited to XAML based UI and it would seem it works in a similar fashion, where your project takes a dependency on a Gorilla Player nuget and you need to set up Gorilla Player in your App startup.

All in all I was quite pleased how well LiveXAML works and how easy it is to get started. It just works. I have not tried it on a real device, but given that the device is on the same network as your PC, I think it may work just fine. If I were making Xamarin.Forms applications professionally, I would really consider LiveXAML as a means to create and debug XAML layouts.

Upgrade notes for MvvmCross 5.x on iOS

28 Jun 2017 | MvvmCross Xamarin
This post is just a couple of notes about some of the changes that affected some of my apps when updating to MvvmCross 5.x on Xamarin.iOS.

IMvxModalIosView or MvxModalNavSupportIosViewPresenter could not be found

MvvmCross has replaced the presenter logic, which before looked for the IMvxModalIosView interface in order to figure out how to present a ViewController. You should instead use the MvxModalPresentation attribute for your ViewController.

Previously you also had to use MvxModalNavSupportIosViewPresenter for it to understand the IMvxModalIosView interface. This is now all baked into the default presenter.

For this attribute you can also give it a couple of hints about how to display itself through a couple of properties.

  • Animated, set this to false to disable animations when presenting your modal ViewController, defaults to true
  • PreferredContentSize, set this to your content size on iPad, since they are not shown full screen default there
  • ModalTransitionStyle, set this to the desired transition style, cover, flip, cross dissolve or curl, this will not work when Animated is set to false, defaults to CoverVertical
  • ModalPresentationStyle, set this to the desired presentation style. This depends on the LayoutSize and in most cases on iPhone will default to FullScreen. This is mostly to change presentation on iPads.
Here is how the changes will reflect in your code:


Changing to the new presenter for Modals is pretty painless.

CreateNavigationController has changed signature

The MvxIosViewPresenter has changed the signature of CreateNavigationController, this is luckily a very simple change.

MvxTabBarViewController is presented as child?

Another thing in the new presenter for iOS, is that some ViewControllers, cannot be presented as children and need to be presented as root instead. This is something that will be fixed in MvvmCross 5.0.4 since this is unwanted behavior. You should be in control of how you want your ViewControllers presented. For now in 5.0.0-5.0.3 you can make a small change to fix this.


MvvmCross.Dialog is gone?

Yes. It was unmaintained and upstream MonoTouch.Dialog has been unmaintained for just as long time. The MvvmCross team does not want to support something that no one wants to fix.

What should you use instead? How about Xamarin.Forms? Or plain iOS Tables and Views? Sorry, no shortcuts here. You could recompile Dialogs from MvvmCross 4.x against 5.x yourself.

What I have opted for is using MvxTableViewController and making my own Adapters for cases where I need to display different kind of cells, groupings etc. It is not that much work and you are not dependent on a 3rd party library here. You can still bind MvxTableViewCells to whatever you want and TwoWay bindings work much better than MonoTouch.Dialogs ever did.


Identifying users with HockeyApp

23 Dec 2016 | CrashAnalytics Xamarin
I use HockeyApp for crashes and App analytics. Most of the time users that are logged into the App have different accounts than what they use with HockeyApp, so most of the time I can't use the LoginManager.

Instead, to Identify users I do the following instead.

Android

Create an implementation of CrashManagerListener, which overrides UserID, Contact and Description.
Then use it as follows when registering the CrashManager

iOS

On iOS you need to implement BITHockeyManagerDelegate where you need to override UserIdForHockeyManager(), UserNameForHockeyManager() and UserEmailForHockeyManager().
Then right before starting the SharedHockeyManager you need to register your Delegate.
Now the User and Contact columns in a crash report on HockeyApp should be filled out with the values you provided.

Firebase Cloud Messaging in Xamarin.Android

11 Nov 2016 | Notifications Xamarin.Android
I've seen people asking a lot about this lately on XamarinChat Slack. Looking around there does not seem to be much good information on how to get Firebase Cloud Messaging (FCM) to work in a Xamarin.Android project. I made the switch in one of my apps a month or so ago, from Google Cloud Messaging to FCM and I too was lacking the information about how to get this to work. I did get it to work by piecing together information from the Java world. Surprisingly enough it is not that much different in Xamarin.Android.

1. Creating a Firebase Project

If you have not already created a Firebase project you need to do so now. You can either opt to import an existing Google project or Creating a new. Either way the instructions are pretty much the same.

1. Go to the Firebase Console

2. Create a new project or import Google Project


I don't think it is super important what region you choose your project to be in. I just chose the region where I expect the most users to use my App.

2. Registering Application

When you have created your project or imported an existing one you can now add your application. This can be done several places in the console. I just went to Notifications and it prompted me to add an application.
Pressing the Android icon will show you the following dialog
Here you need to enter the details of your Application. Package name is the package name you have set in your AndroidManifest.xml file. You might want to change that to something resembling your namespace in your app. Make sure that it is all lowercase too. Nickname is optional and is just an easy way to identify your app in the Console. Press Add App or optionally do step 2.1 first to add a SHA-1, then press Add App. The browser will now download a google-services.json file, which we will use later, in step 4.

2.1 Creating a keystore (optional)

If you haven't already created a keystore file for your App, you can do so now. For more information refer to the Xamarin Documentation.
You will need it for deploying to Google Play Store anyways. You will need it for Google Play Services, such as Google Maps. Easiest way to do so is through the Archive tool in Visual Studio or Xamrin Studio, which you can trigger by right clicking your Android Application project. Make sure to have selected Release Configuration and your App can build.
At the bottom of the Archive screen, when an Archive is ready, click Distribute... > Ad Hoc > +
A dialog for creating a new keystore will appear, which you will need to fill out with relevant details. Create your keystore and now we need to find it on the computer.
Note: A keystore is used to sign the application, for deployment on the Google Play Store. Many Google Play Services require a SHA-1 entered into the Google Console for your App package
On Windows, Xamarin Archives put the keystore in C:\Users\<username>\AppData\Local\Xamarin\Mono for Android\Keystore you can find the one you just created in a subfolder maching the name of the keystore you just created. To get the SHA-1 from a keystore you run the keytool command line tool. If it isn't in your environment PATH, it is located in the Java SDK folder. In my case C:\Program Files\Java\jdk1.8.0_102\bin lets just assume you don't have it in your environment PATH the command to get the SHA-1 would look something like

"C:\Program Files\Java\jdk1.8.0_102\bin\keytool.exe" -exportcert -list -v -alias yourkeystorealias -keystore C:\Users\<username>\AppData\Local\Xamarin\Mono for Android\Keystore\fcmtest\fcmtest.keystore

yourkeystorealias being the name of your keystore in this case. Although a keystore can contain multiple aliases, which the Xamarin Archive tool does not seem to care about. The output will look like follows
We need the SHA-1, you can enter that in the certificate SHA-1 for your Firebase Project.
You can also grab the one from the debug.keystore in the C:\Users\<username>\AppData\Local\Xamarin\Mono for Android folder and enter that later as an additional fingerprint in the Firebase console.

3. Adding FCM NuGet to your project 

Before we proceed and before we can do 4. where we add the google-services.json to our project. We need to add some NuGet for the FCM stuff, but also for the Build Action needed in 4., which comes with the Google Play Services Nuget.

Add the Xamarin.Firebase.Messaging NuGet to your project. Currently there is only a pre-release version of it. Hence you need to tick the Include Prerelease box in your NuGet package manager.

 

4. Adding google-services.json to the application

We will now add the google-services.json file from 2. to the Android project.

Right click your project, select Add > Exisiting Item find the google-services.json in the folder your browser downloaded it to, then press Add.

Now we need to set the build action of that file to GoogleServicesJson.
Note: If the GoogleServicesJson Build Action is not present, follow the instructions in this GitHub issue which tells you to: 1. clean/rebuild your project. 2. restart Visual Studio/Xamarin Studio. 3. make sure that the csproj file includes Xamarin.GooglePlayServices.Basement.targets
Add the Build Action by right clicking the google-servies.json file you added to your project. Click Properties. In there set the Build Action.

5. Adding FCM receivers to the AndroidManifest

Inside the AndroidManifest.xml we need to add a couple of entries for the FCM BroadcastReceivers, which are not added by the NuGet package.

Locate the <application> tag in your manifest. Inside of that node add the following code

${applicationId} will get replaced at build time, with your App's package name. Make sure your package name conforms to Android's guidelines.

6. Implementing FirebaseInstanceIdService and FirebaseMessagingService

Now we need to add two services in our App. FirebaseInstanceIdService, which gives us the token used to identify the FCM registration of this particular device. This is normally used with a backend to tell it how to send notifications to the device.
FirebaseMessagingService is the service, which will be invoked when we receive a notification in the application. Here you prepare the notification to be displayed with data coming from the FCM.

6.1 FirebaseInstanceIdService

In order to receive the token from the App's registration with FCM, we need to implement FirebaseInstanceIdService. In here you would save the token and communicate it to the backend, which sends the notifications to the App.


What I usually do in step 1. and 2. in the todo comment is to check with the token I saved in SharedPreferences whether it has changed and override it if it has. Then I send a request to my backend with the new token.


6.2 FirebaseMessagingService

The FirebaseMessagingService is where we receive our notifications. Here you will get the data out of the notification sent to you. If you have sent extra stuff with your notification, take a look at the Data property on the RemoteMessage argument we get in OnMessageReceived. This will probably also apply to raw notifications that do not trigger any visual feedback.

In either case here is some sample code to get you started. Here I simply grab the Title and Body sent with the notification and present it with an Intent to start my MainActivity. The Intent accepts extras which you can add to it and when the notification triggers your Activity you can pull that data out and act accordingly.

That should be it! Build and fire up your Application and use the Firebase Console to send some test notifications.





The GooglePlayServicesComponents repository that Xamarin has on GitHub, contains a sample application that you can take a look at if you need a starting point. You can also take a look at the documentation from the Firebase Component not yet in the Xamarin Component store.