Categories
.net Android MonoForAndroid Windows Phone Xamarin

Different XAML layouts for different device orientations in Xamarin.Forms

In case you’ve been wondering how to achieve different XAML layouts for different device orientation with Xamarin.Forms (just Forms from now), here is a solution. The thing is that there is currently no support for this. There is support for different layout when it comes Phone vs Tablet (OnIdiom<T>) or when it comes to different OS (OnPlatform<T>) but the thing is that these guys are static. They do their work once and that’s it. They won’t react to changes and it makes sense, since underlying OS or device type don’t change during runtime.

So something different is need. But before I even start with the XAML there is an important part that has to be done – getting the current orientation, or better, rotation at the Portable Class Library level. It is a twofold solution.

Here is code that exists in PCL project and isn’t OS specific.

public enum Rotation
{
    Rotation0,
    Rotation90,
    Rotation180,
    Rotation270
}
public static class Orientation
{
    private static Rotation rotation;
    public static EventHandler RotationChanged;
    public static Rotation Rotation
    {
        get
        {
            return rotation;
        }
        set
        {
            if (Rotation != value)
            {
                rotation = value;
                OnRotationChanged();
            }
        }
    }

    public static bool IsLandscape
    {
        get
        {
            return Rotation == Rotation.Rotation90 
                || Rotation == Rotation.Rotation270;
        }
    }

    private static void OnRotationChanged()
    {
        if (RotationChanged != null)
            RotationChanged(null, EventArgs.Empty);
    }
}

And here is the OS specific part where you set the orientation.

Android version:

public class MainActivity : AndroidActivity
{
    protected override void OnCreate (Bundle bundle)
    {
        UpdateCurrentRotation();
        base.OnCreate (bundle);

        Xamarin.Forms.Forms.Init (this, bundle);

        SetPage (App.GetMainPage ());
    }

    public override void OnConfigurationChanged(Android.Content.Res.Configuration newConfig)
    {
        base.OnConfigurationChanged(newConfig);
        UpdateCurrentRotation();
    }

    private void UpdateCurrentRotation()
    {
        switch (WindowManager.DefaultDisplay.Rotation)
        {
            case  SurfaceOrientation.Rotation0:
                Orientation.Rotation = Rotation.Rotation0;
                break;
            case SurfaceOrientation.Rotation90:
                Orientation.Rotation = Rotation.Rotation90;
                break;
            case SurfaceOrientation.Rotation180:
                Orientation.Rotation = Rotation.Rotation180;
                break;
            case SurfaceOrientation.Rotation270:
                Orientation.Rotation = Rotation.Rotation270;
                break;
        }
    }
}

Windows Phone version (note that you have to set SupportedOrientations=”PortraitOrLandscape” in your MainPage.xaml to enable rotation of the page):

public partial class MainPage : PhoneApplicationPage
{
    public MainPage()
    {
        InitializeComponent();
        UpdateRotation();
        Forms.Init();
        Content = App16.App.GetMainPage().ConvertPageToUIElement(this);
    }

    private void UpdateRotation()
    {
        if ((Orientation & PageOrientation.PortraitUp) 
== PageOrientation.PortraitUp) App16.Orientation.Rotation = Rotation.Rotation0; else if ((Orientation & PageOrientation.PortraitDown)
== PageOrientation.PortraitDown) App16.Orientation.Rotation = Rotation.Rotation180; else if ((Orientation & PageOrientation.LandscapeLeft)
== PageOrientation.LandscapeLeft) App16.Orientation.Rotation = Rotation.Rotation90; else App16.Orientation.Rotation = Rotation.Rotation270; } protected override void OnOrientationChanged
(OrientationChangedEventArgs e) { UpdateRotation(); base.OnOrientationChanged(e); } }

Sadly I have no iOS device at this time, but it should be pretty easy to support it as well.

At the beginning of the page/activity and each time orientation changes the current rotation is sent to Orientation class in PCL.

At this point we have the rotation information and event RotationChanges that notifies about changes in rotation. Now this information can be used to achieve the dynamic layout changes.

For that purpose I’ll use a Grid ContentView derived class that can be nicely used with XAML.

public class Rotational: ContentView
{
    public View Landscape { get; set; }
    public View Portrait { get; set; }
    public string LandscapeType { get; set; }
    public string PortraitType { get; set; }
    private bool isPortrait;

    protected override void OnParentSet()
    {
        base.OnParentSet();
        VisualElement view = ParentView;
        while (!(view is Page))
        {
            view = view.ParentView;
        }
        Page page = (Page)view;
        page.Disappearing += page_Disappearing;
        page.Appearing += page_Appearing;
    }

    void page_Appearing(object sender, EventArgs e)
    {
        Orientation.RotationChanged += CurrentOrientation_Changed;
        Update();
    }

    private void CurrentOrientation_Changed(object sender, EventArgs e)
    {
        Update(); 
    }

    void page_Disappearing(object sender, EventArgs e)
    {
        Orientation.RotationChanged -= CurrentOrientation_Changed;   
    }

    private void Update()
    {
        if (Content == null || Orientation.IsLandscape && isPortrait ||
            !Orientation.IsLandscape && !isPortrait)
        {
            Children.Clear();
            if (RhOrientation.IsLandscape)
{
isPortrait = false;
if (Landscape != null)
{
Content = Landscape;
}
else
{
View child = FindContentView(LandscapeType);
Content = child;
}
}
else
{
isPortrait = true;
if (Portrait != null)
{
Content = Portrait;
}
else
{
View child = FindContentView(PortraitType);
Content = child;
}
} } } private View FindContentView(string contentViewName) { var query = from t in GetType().GetTypeInfo().Assembly.DefinedTypes where t.IsClass && !t.IsAbstract && t.IsSubclassOf(typeof(ContentView)) && t.Name == contentViewName select t; var contentViewTypeInfo = query.SingleOrDefault(); if (contentViewTypeInfo != null) { ContentView page = (ContentView)Activator.CreateInstance
(contentViewTypeInfo.AsType()); return view; } else return null; } }

The class is named Rotational and defines four properties: Portrait, PortraitPage, Landscape and LandscapePage. Portrait and Landscape are of type View and you can store View derived classes that would appear based on orientation. Here is an example:

<ContentPage xmlns="http://xamarin.com/schemas/2014/forms"
                       xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
                       xmlns:v="clr-namespace:App16;assembly=App16"
                       x:Class="App16.TestPage">
  <v:Rotational>
    <v:Rotational.Landscape>
      <StackLayout Orientation="Vertical">
        <Label Text="Landscape" HorizontalOptions="Center" />
      </StackLayout>
    </v:Rotational.Landscape>
    <v:Rotational.Portrait>
      <StackLayout Orientation="Vertical">
        <Label Text="Portrait" HorizontalOptions="Center" />
      </StackLayout>
    </v:Rotational.Portrait>
  </v:Rotational>
</ContentPage>

Note that namespace declaration is required (xmlns:v=”clr-namespace:App16;assembly=App16″). The above definition will show a label saying Portrait or Landscape, depending on device rotation and will change dynamically. The drawbacks of this approach are that both configurations are in-memory and the page might become a bit bloated.

Hence the second pair of properties: PortraitPage and LandscapePage. These are of string type and allow to enter the page class names the content of which will be used dynamically. Here is an example:

<ContentPage xmlns="http://xamarin.com/schemas/2014/forms"
                       xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
             xmlns:v="clr-namespace:App16;assembly=App16"
                       x:Class="App16.TestPage">
  <v:Rotational PortraitType="PortraitTestContent" 
LandscapeType="LandscapeTestContent" /> </ContentPage>

Additional two pages are required (PortraitTestContent.xaml and LandscapeTestContent.xaml):

<ContentView xmlns="http://xamarin.com/schemas/2014/forms"
                       xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
                       x:Class="App16.PortraitTestPage">
    <Label Text="Portrait test" VerticalOptions="Center" 
HorizontalOptions="Center" /> </ContentView> ... <ContentView xmlns="http://xamarin.com/schemas/2014/forms" xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml" x:Class="App16.LandscapeTestPage"> <Label Text="Landscape Test" VerticalOptions="Center"
HorizontalOptions="Center" /> </ContentView>

The pages are found using reflection and based on their names (no namespace is used).

This method is more memory efficient since it loads required content on demand and discards it afterwards. On the other side it is slower due to the loading of the page.

So, here you have it. What do you think? Is there a better way?

The sample is attached.

Rotational.zip (77.2KB)

Update 1: Instead of dynamically loading ContentPage and then using its content, ContentView should be used (it is XAML supported). That’d be a change in FindPageElement method to FindContentView.
Update 2: Changed base type for Rotational from Grid to ContentView.

Note: sample hasn’t been updated from original version.

Categories
.net

An async problem

Imagine you have an asynchronous cancellable method like this:

CancellationTokenSource cts;

async Task DoSomethingAsync()
{
    if (cts != null)
        cts.Cancel();
    cts = new CancellationTokenSource();
    try
    {
        await AnAsyncMethodAsync(cts.Token);
    }
    finally
    {
        cts = null;
    }
}

And you trigger it here and there. The idea is that if it is already running when triggered (cts != null) it should send cancellation signal through its token.

Now, can you spot a possible problem that can occur?

The answer: DoSomething starts and is awaiting, another call is issued, original call is cancelled, second call is awaiting, original call advances to finally block (cts is set to null). Third call chimes in but this time cts is null (because original call set cts to null) even though second call is awaiting and thus second call is *not* cancelled, third call is awaiting and both second and third will finish.

There you go.

Categories
.net Android MonoForAndroid Xamarin

Troubleshooting memory leaks in Xamarin.Android

I was testing an application I am building with Xamarin/Android. One of the tests was rotating the device while Google Maps fragment being shown. By default each time the orientation changes the activity and its views/fragments are recreated. IOW it is a good test for possible memory leaks because the recreation can be frequent.

I was quite surprised seeing a huge memory increase each time. Those eventually lead to an OutOfMemory in Java stack somewhere in Google Maps. After double checking that managed Xamarin code wasn’t leaking (i.e. retaining the said fragment somehow) anything I was starting to wonder whether Google Maps fragment is leaking internally. Perhaps only when combined with Xamarin. That’d be odd but not impossible.

Thus I started Android Studio and crafted a repro in pure Java. It wasn’t leaking. Thus it must have something to do with Xamarin. But what? Xamarin is providing a component to Google Maps (.net wrapping). Is it possible that there is a problem? Switching back to Xamarin and a few more tests later I couldn’t create a non leaking version. No matter what I did I still got leaks.

Suspecting a problem within Xamarin somewhere I decided to report a bug to bugzilla (Xamarin’s bug reporting web, not support) about it and mail a question to Xamarin support. The Jonathan Pryor’s response on bugzilla was lightning fast. In an hour or so he solved the mystery. The response from official support line was fast as well. (kudos to Xamarin on both).

It turns out that I was bitten with unmanaged memory pressure issue. Actually with unmanaged managed memory pressure issue. The thing is that Xamain/.net doesn’t know anything about unmanaged memory consumption. This is well known to .net developers, or at least, it should be. So, if you allocate a huge unmanaged piece of memory the .net won’t know about its size and won’t fire garbage collection automatically when it is released even it you are running low on memory (there are ways to let it know the memory consumption but that isn’t automatic). That’s usually valid for native code. But in the case of Xamarin, Java part is also unmanaged code to Xamarin (albeit Java is managed, but managed within Java with its own garbage collector).

Each time the Google Maps fragment was created and destroyed Xamarin created and “released” a single reference to maps fragment. By released I mean it was referenced from anywhere anymore and thus available for garbage collection by Xamarin garbage collector. But since .net saw only few bytes in that reference (which in turn referenced a ton of Java objects) it didn’t fire garbage collection automatically (and Java garbage collector couldn’t reclaim the memory because it was referenced by Xamarin) thus memory usage was increasing by huge steps. Strictly speaking this wasn’t a memory leak because all the memory would be reclaimed eventually – when garbage collection would run.

And that’s exactly how I solved it – I now run a manual garbage collection at least upon fragment creation (to reclaim the memory used by previous one). Problem solved. The bottom line is that you might run manual garbage collection after releasing a reference to Java object which internally uses plenty of memory. Also, calling Dispose on Xamarin objects helps (they might release reference to Java’s counterpart). In my case I couldn’t call Dispose because my fragment was created by layout inflation (actually I guess, I could by obtaining a reference to it, but that wasn’t obvious nor it might not help).

Here is more about Xamarin Garbage Collection.

Categories
.net Android Development DevExpress Profiling Xamarin

A memory profiler for Xamarin.Android

Here is a first ever snapshot of my home-grown memory profiler for Xamarin.Android.

While very spartan it does the core job – comparing two snapshots for objects with growing instances (aka memory leaks). An array of Autofac.Core.IRegistrationSource[] is showing its references (one root, one to a List<>).

There you. Interested?

PS. Sample features DevExpress WPF components, chiefly XpfGrid.

Categories
.net Deployment Xamarin

Using Autofac with Xamarin

Good news is that Autofac, my IoC container of choice, works with Xamarin and even within Portable Class Library.  However there is one potential pitfall and it seems it happens at least when you use factories.

Imagine resolving ITubo defined as:

public class Tubo: ITubo
{
    public Tubo(Func<ITubo> tuboFactory)
    {}
}

public interface ITubo
{}

Note the use of factory through Func<ITubo>. In this case Autofac uses reflection and perhaps some runtime IL code generation. Now, try running the following piece of code on Xamarin.Android:

ContainerBuilder builder = new ContainerBuilder();
builder.RegisterType<Tubo>().As<ITubo>();
var container = builder.Build();
container.Resolve<ITubo>();

It is simple registration and after that I do resolve the interface. When you run this code it will most probably work. But that’s only because you are running it in Debug configuration. Now try running in in Release configuration. It will most probably throw an exception at you:

Autofac.Core.DependencyResolutionException: An exception was thrown while executing a resolve operation.

Not very informative but at least the call stack shows that problem happens within System.Core assembly. And it isn’t Autofac’s fault at all.

The reason for the problem is simple but perhaps not the most obvious one. Default project settings are that at Release configuration it cuts out all of the unused code from SDK libraries (Xamarin stuff which is basically all .net BCL) and combines all of the assemblies into a single file – through its linker (at Debug time it uses shared libraries as would .net on Windows). And since Autofac is doing operations at runtime (at least when it comes to factories), linker doesn’t see those and simply cuts off unused types at compilation time to reduce the output size. Read more about Xamarin linking process here:

Linking

The nasty part is that you won’t know what types are cut off until you run the application in Release configuration. Remember, always try your applications in Release configuration!

The solution

Anyway, the solution is, as I’ve found out, rather simple. Just instruct linker to leave alone (don’t optimize) System.Core assembly. If you are using Visual Studio the go to Project/Properties, Android Options tab and enter System.Core text into Skip linking assemblies text box. If you are using Xamarin IDE the go to Project/Properies, Build/Android Build tab, Linker subtab and enter the same System.Core into Ignore Assemblies text box (didn’t try this one). That’s it, linker will leave alone that assembly and Autofac will happily run even in Release configuration.

Luckily the difference in output file size isn’t that significant: 450KB in worst case.

Categories
.net VS2013

Solving Blend 2013 interactivity error

I am playing with Blend 2013 Silverlight Sketchflow for creating web application mockups. Recently I’ve stumbled into an curios error when adding interactivity to a button.

Here is the repro:

Create two screens, and a button on a screen. So far so good. Right click on that button and select Navigate To/Screen 2. Blend will add a navigational behavior, like:

<i:Interaction.Triggers>
    <i:EventTrigger EventName="Click">
        <pi:NavigateToScreenAction 
TargetScreen="SilverlightPrototype2Screens.Screen_1"/> </i:EventTrigger> </i:Interaction.Triggers>

It will underline pi:NavigateToScreenAction with a red squiggle as well complaining that type NavigateToScreenAction from assembly Microsoft.Expression.Prototyping.Interactivity is built with an older version of the Blend SDK, and it is not supported in Silverlight 5 projects.

A puzzling error. After playing around I discovered that the problem is with the referenced System.Windows.Interactivity assembly. Somehow Blend added a reference to a version 4.0.5.0. instead of 5.0.5.0.

Not sure what triggered the referencing of the wrong version but the solution is quite simple. Just remove it (in both projects) and reference the proper version. And Blend application sparks to life again.

Categories
.net Profiling Red Gate

Investigating why an instance is kept alive in a .net application

Sometimes, when I want to verify .net memory management behavior, I fire up ANTS Memory Profiler and run it on a test application just to see how memory management behaves.

So today I went and created this application

class Program
{
    static void Main(string[] args)
    {
        A a = new A();
        B b = new B { Pointer = a };
        Console.WriteLine("One");
        Console.ReadLine();
        b.Pointer = null;
        b = null;
        Console.WriteLine("Two");
        Console.ReadLine();
        a = null;
        Console.WriteLine("Three");
        Console.ReadLine();
        a = new A();
        Console.WriteLine("Four");
        Console.ReadLine();
    }
}

class A
{

}

class B
{
    public A Pointer;
}

The ReadLine calls allow me to hit the “Take Memory Snapshot” in profiler. Later I examined these snapshots, specially the one between One and Two. What would you expect, how many instances are alive at that point? I’d say one, the instance of class A (referenced by a).

However, the profiler was showing, surprisingly, two. According to it, both an instance of A and an instance of B, were still very much alive. This result surprised me. Even more surprisingly, after Four there was still an instance of B around. How is this possible? There are no references to b and it is pointing to null. A bug in Memory Profiler? Hardly possible.

Right before I was going to post a question on RedGate’s forum I decided to check the IL code. With .net reflector of course. Immediately I saw the reason for that odd behavior. Can you spot it?

.method private hidebysig static void Main(string[] args) cil managed
{
    .entrypoint
    .maxstack 2
    .locals init (
        [0] class ConsoleApplication213.A a,
        [1] class ConsoleApplication213.B b,
        [2] class ConsoleApplication213.B b2)
    L_0000: nop 
    L_0001: newobj instance void ConsoleApplication213.A::.ctor()
    L_0006: stloc.0 
    L_0007: newobj instance void ConsoleApplication213.B::.ctor()
    L_000c: stloc.2 
    L_000d: ldloc.2 
    L_000e: ldloc.0 
    L_000f: stfld class ConsoleApplication213.A ConsoleApplication213.B::Pointer
    L_0014: ldloc.2 
    L_0015: stloc.1 
    L_0016: ldstr "One"
    L_001b: call void [mscorlib]System.Console::WriteLine(string)
    L_0020: nop 
    L_0021: call string [mscorlib]System.Console::ReadLine()
    L_0026: pop 
    L_0027: ldloc.1 
    L_0028: ldnull 
    L_0029: stfld class ConsoleApplication213.A ConsoleApplication213.B::Pointer
    L_002e: ldnull 
    L_002f: stloc.1 
    L_0030: ldstr "Two"
    L_0035: call void [mscorlib]System.Console::WriteLine(string)
    L_003a: nop 
    L_003b: call string [mscorlib]System.Console::ReadLine()
    L_0040: pop 
    …
}

For some reason, compiler decided to allocate two references for class B: local variables b and b2. When the instance of class B is created it is stored in b2. After the Pointer property is assigned the same reference is stored to b while b2 isn’t set to null. Then when b is set to null, the b2 is still very much alive and thus keeping the instances count for class B to 1 – even though b is null and there are no other C# variables for referencing instances of B.

Mystery solved.  The lessons learned are that compiler might generate code one wouldn’t expect and that profiling memory isn’t always black and white. Those 50 shades of gray happen as well. IOW experience and good understanding of .net is a necessity.

Categories
.net

When .net assemblies aren’t properly versioned odd errors happen

Today I’ve upgraded a SignalR library from 1.x to 2.0 in an MVC 5 (server) and WPF (client) projects I am developing. The upgrade itself went smooth but afterwards the client started yielding odd errors and refusing to connect anymore. It was yielding an exception saying something like Transport Connection time out (I can’t remember the exact message). Since it was a rather simple upgrade this error made no sense. Google didn’t help much either.

So I went debugging.

Investigation

First step is to create a simple repro sample – a solution with a basic server and a console client (see attached zip).

Second step is to turn on SignalR tracing on client:

hubConnection.TraceLevel = TraceLevels.All;
hubConnection.TraceWriter = Console.Out;

Armed with these two steps I was able to get an error that made a bit more sense although it was even more bizzare.

18:43:53.9073548 – null – ChangeState(Disconnected, Connecting)
18:43:55.4913444 – b8fd1874-483d-4d89-8a69-c2cfe33cf946 – WS Connecting to: ws://localhost:53705/signalr/connect?transport=webSockets&connectionToken=0dQ3scw2aJ7RbXuUsTfa4wlY%2FJlMzW%2FVL1sVb%2FyswewEO8n4qAth7Erpt0ga0laLV%2B8BCD833lZZy1MblOe0HuQs0O1mYi%2FfiiLSHc5%2F%2B1wk6tUsbFxMKVQFwRO9BvSW&connectionData=[{“Name”:”formsHub”}] 18:43:55.5800651 – b8fd1874-483d-4d89-8a69-c2cfe33cf946 – WS: OnMessage({“C”:”d-5AB67EA2-B,0|C,0|D,1|E,0″,”S”:1,”M”:[]})
18:43:55.5940751 – b8fd1874-483d-4d89-8a69-c2cfe33cf946 – OnError(System.MissingMethodException: Method not found: ‘System.Collections.Generic.IEnumerator`1 Newtonsoft.Json.Linq.JArray.GetEnumerator()‘. at Microsoft.AspNet.SignalR.Client.Transports.TransportHelper.ProcessResponse(IConnection connection, String response, Boolean& shouldReconnect, Boolean& disconnected, Action onInitialized) at Microsoft.AspNet.SignalR.Client.Transports.WebSocketTransport.OnMessage(String message) at Microsoft.AspNet.SignalR.WebSockets.WebSocketHandler.d__e.MoveNext())
18:43:55.6110864 – b8fd1874-483d-4d89-8a69-c2cfe33cf946 – WS: OnClose()

It says something like – I can’t find a method in the Newtonsoft.Json assembly. That’s totally weird as this kind of error should be handled at compile time.

I went looking into Newtonsoft.Json assembly referenced by SignalR 2.0. It correctly references version 5.0.8. The assembly in package folder has the method it was mentioned as missing. Mystery. One thing that caught my eye  while .net reflecting the assembly was its version. While the file version is 5.0.8. the assembly version is, oddly, 4.5.0.0. How come?

Fourth step was looking into modules loaded by my application. They are listed through Visual Studio-Debug/Windows/Modules. Amazingly, Visual Studio was listing Newtonsoft.Json v4.05.8.15203 from … GAC. Not from my package. And by looking at its date it was clear that it was an older version (4.8.2012). Heck, I didn’t even know it was in GAC. I didn’t put it, some other app had to.

 

From previous Googling I remembered an explanation somewhere that the missing GetEnumerator method was introduced in version 5.0.5. So this was probably it – .net was loading an older version from GAC – that was really missing that method. At this point I knew what was wrong.

Just in case, to make sure, I checked whether the assembly really was in GAC:

C:\Windows\system32>gacutil /l newtonsoft.json
Microsoft (R) .NET Global Assembly Cache Utility.  Version 4.0.30319.18020
Copyright (c) Microsoft Corporation.  All rights reserved.

The Global Assembly Cache contains the following assemblies:
  newtonsoft.json, Version=4.5.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed, processorArchi
tecture=MSIL

Number of items = 1

It was.

Remedy

The proper way would be to have a properly versioned Newtonsoft.Json assembly (those are strong key signed as well). That’s why there is versioning and .net wouldn’t make this confusion. I really wonder why James uses the same assembly version for assemblies that should really have different signatures. Hopefully he will fix this problem in next versions. But until then there is …

… the next best way is to force .net to not load it from GAC.  If the assembly is removed from GAC, .net won’t find the wrong version anymore. See, .net always tries GAC first and only if it doesn’t find a suitable assembly it will go looking elsewhere, like into the folder where your application is. Perhaps I could configure it to load the proper assembly through .config file but this solution is better – it’ll solve the problem unless an older newtonsoft.json is reinstalled again in GAC. Hm.

Removing assembly from GAC should be a rather simple process. Just fire

GACUTIL /U Newtonsoft.Json

and it should be removed. But not this time. Instead I got this warning:

C:\Windows\system32>gacutil /u newtonsoft.json
Microsoft (R) .NET Global Assembly Cache Utility.  Version 4.0.30319.18020
Copyright (c) Microsoft Corporation.  All rights reserved.

Assembly: newtonsoft.json, Version=4.5.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed, proces
sorArchitecture=MSIL
Unable to uninstall: assembly is required by one or more applications
Pending references:
              SCHEME: <WINDOWS_INSTALLER>  ID: <MSI>  DESCRIPTION : <Windows Installer>
Number of assemblies uninstalled = 0
Number of failures = 0

Basically it is saying that some installed application did install it into GAC and now it is preventing me from removing it from GAC. Uf, nasty. To make it worse, it doesn’t say which application. This article lists the way to “unreference it” to be able to remove it from GAC. Basically you have to remove its entry from the registry and then execute gacutil removal command again.

 

After registry modification it succeeded.

C:\Windows\system32>gacutil /u newtonsoft.json
Microsoft (R) .NET Global Assembly Cache Utility.  Version 4.0.30319.18020
Copyright (c) Microsoft Corporation.  All rights reserved.

Assembly: newtonsoft.json, Version=4.5.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed, proces
sorArchitecture=MSIL
Uninstalled: newtonsoft.json, Version=4.5.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed, pro
cessorArchitecture=MSIL
Number of assemblies uninstalled = 1
Number of failures = 0

The aftermath

Removing that old Newtonsoft.Json from registry did the trick. SignalR works like charm again. However, I had to manually remove a component of an unidentified application. And this removal might cause problems with that application in the future.

I really hope that Newtonsoft.Json gets proper versioning to avoid situations like this. This should be a lesson to every library developer out there – do use proper version numbering!.

SignalRTest.zip (4.69 mb)

UPDATES:

12.11.2013: James, the author, is looking at the possible solution. See https://json.codeplex.com/discussions/465332#post1122165.

Categories
.net Android Xamarin

Android activity life cycle and IoC

I was recently working on an Android (Xamarin, .net) application based on MvvmCross framework. Actually not just an Android app since it could be ported quite easily to other platforms, such as Windows Phone 8 or IPhone. Anyway, I was using inversion of control principle in a slightly incorrect way and thus done a mistake which revealed only a while after the deployment.

Here are the symptoms: Application would cold start fine, would resume fine when resume was done within reasonable time (no idea, depends on the device, in my case could be hours and it would work perfectly) but it wouldn’t resume well if the timespan was too much (i.e. a day or several hours). Instead of displaying the activity content it was just an actionbar with title without any content of menuitems.

By looking at android’s log on the device itself it was clear that there were problems with IoC resolve method. It yielded an “Object reference null” type of exception. I was resolving the reference within activity’s constructor. Odd error, since MvvmCross is supposed to trigger IoC registration  before the first activity is run. But somehow it wasn’t. I’ve mentioned that to Stuart (@slodge, man behind MvvmCross) and he instantly pointed to the mistake I made – I neglected the Android activity’s lifecycle. I immediately understood my mistake: I am used to put IoC references within constructors as arguments, which is mostly fine. Except when it comes to Android activities. The thing is that the entry point of a suspended application (with activity destroyed) is the activity itself, more precisely, its constructor. MvvmCross does trigger the IoC registration method correcly, but, of course, only after the activity is created and hence I was having errors in this particular situation.

The solution is fairly simple – move IoC resolving within OnCreate method, not sooner – that’s the point where you can be certain that MvvmCross initialization is done.

Before:

public abstract class SomeClass<T> : Activity
{
    protected readonly IFragmentPresenter fragmentPresenter;

    public MvxActivityFragmentHost(): this(Mvx.Resolve<IFragmentPresenter>())
    {}

    public MvxActivityFragmentHost(IFragmentPresenter fragmentPresenter)
    {
        this.fragmentPresenter= fragmentPresenter;
    }
    ...
}

after

public abstract class SomeClass<T> : Activity
{
    protected IFragmentPresenter fragmentPresenter;

    protected override void OnCreate (Bundle bundle)
    {
        base.OnCreate (bundle);
        fragmentPresenter = Mvx.Resolve<IFragmentPresenter>();
    }
    ...
}

This change did the trick. A bit more work to inject the mock reference when testing but not a big deal.

Now, if you followed the post you might be asking, why the heck does application cold starts just fine, since it should get the same error. The explanation is rather simple – I am using a splashscreen activity when application cold starts. This one doesn’t have any IoC resolving involved at all, but it does initialize MvvmCross. So when it gets to the my problematic activity, the IoC is already in place.

Now, there you have it. Respect the Android activity lifecycle otherwise it will bit you.

Categories
.net .net 3.5 .net 4.0 Visual Studio Visualizer VS 2008 VS 2010 VS 2012 VS2013

Righthand’s DataSet Debugger Visualizer supports VS2013

Highlights from new version to 1.0.11.

  • added VS2013 version
  • added a “separated assembly” versions. Until now I was using RedGate’s Smart Assembly to pack all referenced assemblies into a single DLL file for easier management and distribution. However, this black magic might cause problems in certain situations (Visual Studio add-ins screams for problems). Thus I’ve added another set that features assemblies in separate files. The bottom line, if you have problems or you want to be on the safe side, use the later set.

Go nuts!