Autogenerated by MFractor v3.2.0

Activity Icon Should Be Mip Map

Inspects usages of the [Activity] attribute and validates the Icon property uses a mip map instead of a drawable.

Application Requires Peer Connection Constructor

MFractor detecting an unimplemented Application peer connection constructor

In Xamarin.Android applications, it is often necessary to implement a custom Android.App.Application subclass. Unfortunately this has a nasty edgecase; Application subclasses must manually implement the peer connection constructor otherwise the Xamarin.Android runtime cannot instantiate it!

Consider the following application subclass:

MyApplication.cs

[Application(Name="com.companyname.myandroidapp.MyApplication", Icon="@mipmap/icon", Label="@string/app_name")]
public class MyApplication : Application
{
    public override void OnCreate()
    {
        base.OnCreate();
    }
}

At a glance, this seems perfectly reasonable. However, when the OnCreate method is called by the Xamarin.Android runtime, it generates a System.NotSupportedException when the Java counterpart for the managed Application class cannot be bound:

The System.NotSupportedException caused by not having a peer connection constructor

This can be fixed by implementing the peer connection constructor for the Application class:

MyApplication.cs

[Application(Name = "com.companyname.myandroidapp.MyApplication", Icon = "@mipmap/icon", Label = "@string/app_name")]
public class MyApplication : Application
{
    public MyApplication(System.IntPtr javaReference, Android.Runtime.JniHandleOwnership transfer)
        : base(javaReference, transfer)
    {
    }

    public override void OnCreate()
    {
        base.OnCreate();
    }
}

To quickly fix this code issue, you can use the implement base class constructors code action.

Refer To:

Check Android.Content.Res.Resources Usages

When using the Android.Content.Res.Resources class, all Get* expressions expect the correct resource type identifier. For example, when using Resource.GetString(), a resource identifier of Resources.String.myString is expected. Passing any other resource identifier such as Resource.Color.myColor may result in unintended data being used or runtime exceptions. This code analyser validates that the correct resource type is being provided to the API call.

Check Views Exist In Layout

When connecting Android layouts (axml files located under Resources/Layout), developers pull views out of their bound layout with the FindViewById method.

Take this example layout:

Main.axml

<LinearLayout>
    <Button android:id="+@id/mainButton"/>
</LinearLayout>

MyActivity.cs

public class MyActivity : Activity
{
    public void OnCreate()
    {
        SetContentView(Resource.Layout.Main);
        var button = FindViewById<Button>(Resource.Id.mainButton);
    }
}

The developer is retrieving the mainButton from the Main.axml layout that was bound using the SetContentView(Resource.Layout.Main) invocation.

In large scale applications, as the amount of layouts grows, it becomes very easy to accidentally retrieve the wrong button from the layout.

Say another layout defined secondaryButton... Consider the following:

MyActivity.cs

public class MyActivity : Activity
{
    public void OnCreate()
    {
        SetContentView(Resource.Layout.Main);
        var button = FindViewById<Button>(Resource.Id.secondaryButton);
    }
}

The developer is accidentally pulling out the secondaryButton id from Main.axml but Main.axml defines mainButton; this will cause a runtime exception when the MainActivity is created.

MFractor provides the MFractor.Annotations library that lets developers declare their layout uses for a class, enabling MFractor to inspect FindViewById calls and check that the Resource.Id provided exists in a particular layout.

MyActivity.cs

[MFractor.Annotations.Android.UsesLayout(Resource.Layout.Main)]
public class MyActivity : Activity
{
    // ...
}

MFractor will look for a secondaryButton declaration in all configurations of Main.axml and provide a code warning if it cannot be found:

Inspecting for missing views in a layout using the UsesLayout analyser

Class Derives From IJavaObject

Often when creating new classes in a Xamarin.Android codebase developers will need a new class to be usable between Java and C#. Xamarin.Android provides the IJavaObject interface to expose a class to Java. Instead of directly inheriting from the IJavaObject interface, a developer should instead inherit from Java.Lang.Object which implements the required interface members.

Incorrect Activity Creation

This analyser detects when a developer is instantiating an Android activity or activity subclass directly using a new expression. Activities should only ever be created through the operating system; creating them through a new expression leaves them in an invalid state.

Validate Cheeseknife Attributes

This analyser inspect usages of attributes from the Cheeseknife view injection library; it validates that the Resource.Id.* exists in the layout provided into an MFractor.Annotations UsesLayout attribute.

Verify Toast Is Shown

Sometimes when a Toast is created via MakeText, the Show method is accidently omitted. This analysis routine looks for invocations of Toast.MakeText() that don't then invoke the Show() method on the toast object in the same expression. If the MakeText() result is assigned into a variable or passed as a method argument then this check is skipped.

Warn Of Static Context References

This analyser inspects static variable declarations within classes and checks if the type derives from Android.Content.Context. Static context references have the potential to cause large memory leaks.