13 Sep 2017
Ever since 3rd July 2012 this blog has been running on the blogger.com platform. However, I’ve grown tired of how things are managed in the blogger CMS and how blog posts are written. Especially when adding code blocks it is a huge pain. Since, this blog contains so much code and is mainly about code, I’ve been looking for a better way of writing.
Enter GitHub Pages and Jekyll! Now this blog is static, content is managed on GitHub and posts and pages are written in markdown, which I am used to with documentation for MvvmCross and issues and pull requests on GitHub.
If I need to change something, I can install some of the many Jekyll plugins or just quickly change some HTML or CSS, test it locally and push the changes to GitHub, using git which I use all the time for code anyways!
This workflow suits me much better and hopefully this means more focus on writing blog posts for you to read! Also hope you like the makeover of the blog!
28 Aug 2017
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 toolsIn 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.
MSBuildHaving 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.
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 😢
28 Jun 2017
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.
23 Dec 2016
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.
Create an implementation of CrashManagerListener, which overrides UserID, Contact and Description.
Then use it as follows when registering the CrashManager
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.