XamRight: 95% Effectiveness in Binding Analysis

A central component of XamRight is it’s ability to analyze apps to match views, bindings, view models, and properties without any configuration. This analysis powers bug detection, Xaml autocomplete, and other handy features in daily Xamarin development.

When we last published our benchmarks, XamRight achieved 88% effectiveness against the suite of open source Xamarin.Forms apps we had been using.

With the latest release (1.876), we’ve increased the size of our test suite by about 20%, and the effectiveness of analysis is now over 95%!

Continue reading “XamRight: 95% Effectiveness in Binding Analysis”

Inefficient Xamarin.Forms Layouts

Unnecessary attributes and layouts on a Xamarin.Forms page can slow down the performance of your app – https://docs.microsoft.com/en-us/xamarin/xamarin-forms/deploy-test/performance. This guidance has been around for a long time, but we wanted to know what kind of impact it really can have.

Putting it to the test

We created two similar ListView layouts. The first layout intentionally violates some guidelines, including having unnecessary StackLayout wrappings and redundant LayoutOptions and Grid attribute declarations. The second layout is a more concise representation of the first layout, achieving the same layout but avoiding the unnecessary elements. The layouts are shown in the screenshots below:

Continue reading “Inefficient Xamarin.Forms Layouts”

Tab Retap in Xamarin.Forms, Now With Icons!

A while back, I wrote about how to handle reselecting/retapping of tabs in a Xamarin.Forms TabbedPage (covering iOS and Android in part 1 here and UWP and NavigationPage in part 2 here).  The basic problem is that app designs frequently want to react to a user selecting the already-active tab on a TabbedPage — reselecting, or retapping, the tab.  Sometimes the app might want to pop the navigation stack, or perhaps it would scroll to the top of a ListView.  Whatever the desire, Xamarin.Forms does not make it easy to catch these reselect events.

A lot has happened since the initial solution presented in the above-mentioned posts, for instance Xamarin.Forms has moved from version 2.3 to version 3.6, and tab icons are supported across the three platforms in the sample (iOS, Android, UWP).

If you’re only interested in iOS and Android, there’s nothing new here.  If you need to know how to do this for UWP, read on!

Adding Icons to Tabs

Icons are now supported on tabs on all three of the platforms implemented by this app, just set the Icon property on the immediate children of the TabbedPage. The Image resource must be in the platform-specific projects; shared assembly resources cannot be used for tab Icons.

Unlike iOS and Android, UWP does not support icons on tabs by default. In order to enable tab icons on UWP, the XAML declaration for the TabbedPage needs to be updated:

<TabbedPage xmlns="http://xamarin.com/schemas/2014/forms"
            xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
            xmlns:windows="clr-namespace:Xamarin.Forms.PlatformConfiguration.WindowsSpecific;assembly=Xamarin.Forms.Core"
            x:Class="TabReselectDemo.MainPage"
            windows:TabbedPage.HeaderIconsEnabled="true">
Continue reading “Tab Retap in Xamarin.Forms, Now With Icons!”

Getting whitespace right with Roslyn CSharpSyntaxRewriter

Most agree that Roslyn is a great C# code analysis and refactoring tool. One particularly powerful tool Roslyn has is it’s CSharpSyntaxRewriter [1]. The rewriter allows you to walk down the namespaces and classes of a project and add and edit code where necessary. While the documentation here [2] and the RoslynQuoter [3] can come in handy for generating new code blocks, there’s little guidance for formatting the code so that it’s placed at the right position with the appropriate amount of tabs and whitespace [4]. Hence, this post aims at providing some guidance for formatting code you wish to add using the CSharpSyntaxRewriter.

Continue reading “Getting whitespace right with Roslyn CSharpSyntaxRewriter”

ASP.NET Core with AWS Lambda and Cognito

We are wrapping up a project for a client consisting of mobile apps (Android and iOS, built with Xamarin Forms), and a fairly small management server deployed to AWS. For handling user account management, AWS Cognito seemed like the way to go, but there are a few different ways you can use it with ASP.NET Core:

1. Manual calls to APIs, for instance, for instance as described here https://aws.amazon.com/blogs/mobile/use-csharp-to-register-and-authenticate-with-amazon-cognito-user-pools/ and https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/cognito-authentication-extension.html.

2. Using the new (as of this post) Identity Provider, as described https://aws.amazon.com/blogs/developer/introducing-the-asp-net-core-identity-provider-preview-for-amazon-cognito/. This has the advantage of nicely integrating with typical ASP.NET Core Identity coding patterns.

3. Using OpenId Connect (OIDC) and Cognito UI.  With both methods 1 and 2, AWS Cognito is in charge of the user database and integrating with the AWS roles and permissions infrastructure, but you are still responsible for all of the UI flow around account creation and management.  This option has Cognito handle all of the UI flow around account creation and login (though you have some ability to customize).  For a recent project, we needed to provide server-side access, but didn’t have any kind of fancy needs for account management, so this really seemed to fit the bill.

Continue reading “ASP.NET Core with AWS Lambda and Cognito”

XamRight for Xamarin Native Code

Even when developing a cross-platform Xamarin.Forms app, you still often need to write some platform-specific code to get the most out of each platform.  Apart from analyzing Xamarin.Forms Xaml code, the latest version of  XamRight also introduces error checking for Xamarin.Android and Xamarin.iOS C# code. Here we will look at some of the common errors made when building platform specific code using Xamarin (even if you’re not using Forms) and how XamRight helps.

Xamarin.iOS

One common mistake made when writing Xamarin.iOS code is the incorrect spelling or casing of the property key string value when trying to hook up the AddObserver method as described in a previous blog post – Key Value Observing on iOS for Xamarin. As stated in the post the key value string used in the AddObserver method has to match the export attribute of the getter of the property that is being observed. XamRight’s analyzer does this check for you.
Continue reading “XamRight for Xamarin Native Code”

Benchmarking analysis accuracy for MVVM code

One of the key motivators for developing XamRight was to have a tool that would support a wide range of MVVM patterns in Xaml development without requiring additional configuration.  You shouldn’t have to adapt your code to suit the tool — the tool should adapt to your code!

To do that, we developed XamRight, with a fast, powerful analysis engine that powers error checking in Xaml, autocompletion, and more.  XamRight analysis is now able to fully understand over 88% of Binding expressions in this real-world testing.  For developers, that means a more efficient Xaml editing process, with fewer deploy/debug cycles to fix Binding bugs.

Continue reading “Benchmarking analysis accuracy for MVVM code”

Creating View Model Properties with XamRight 1.646

We are thrilled to announce the latest version of XamRight, version 1.646, which has a lot of fixes and improvements across the product, as well as a major feature – creating a new property in the view model when editing the Xaml view.

XamRight was developed to recognize a wide variety of ways that view models are associated with views.  Whether you use an MVVM framework or manage your view models and views, XamRight has the most powerful analyzer for understanding Xaml MVVM code.

All XamRight features are built on top of that powerful analysis engine, including diagnosing Binding errors, providing completions in Xaml, and now creation of new properties in view model classes.  When you put that all together, XamRight helps you write effective Xaml, regardless of how you want to work.

Give it a try and let us know what you think!

Deep Dive into LayoutOptions in Xamarin.Forms Part 2 (Grids)

In a previous post, I started methodically working through how LayoutOptions work inside different containers.  In this post, that topic is continued, detailing the interactions between LayoutOptions and Grid.

While LayoutOptions values on child views of Grids do aid in positioning the views, LayoutOptions values do not have the same amount of control over the position of child views within Grids as they do over the position of child views within StackLayouts. This is because a Grid’s RowHeight and ColumnWidth values, function to define each child view’s position and dimensions.

For instance, if a view has its Grid.Row property set to 0, its Grid.Column property set to 0 and its Grid.ColumnSpan property set to 2, the view would be positioned at the top left of the Grid. The height allocated to the view would be the height of the first row, and the width allocated to the view would be the width of the first column plus the width of the second column.
Continue reading “Deep Dive into LayoutOptions in Xamarin.Forms Part 2 (Grids)”

Have I Reached the End of my ListView?

Building on a previous post about seeing how a user interacts with a ListView in Xamarin.Forms, the next question is, “Has the user scrolled to the end?”  This can be useful, for instance, if the user is scrolling through a long feed of data, and only a portion is returned at a time.  When the user reaches the end, the app can automatically download more entries.  My colleague Lazareena and I recently collaborated on a solution for this, and here’s what we came up with.

Let’s start with what we want to see on the Forms side of our app. We’ll add this to our class that inherits from ListView:

public static readonly BindableProperty AtEndOfListProperty =
        BindableProperty.Create(nameof(AtEndOfList), typeof(bool), typeof(MyListView), false);

public bool AtEndOfList
{
    get { return (bool)GetValue(AtEndOfListProperty); }
    set
    {
        SetValue(AtEndOfListProperty, value);
    }
}

Continue reading “Have I Reached the End of my ListView?”