Xamarin Dependencies: Android App Just Doesn't Start After Deployment
Take a journey through frustration with one developer as he attempts to correct an error message from Xamarin.
Join the DZone community and get the full member experience.Join For Free
Being relatively new to Xamarin, I naively expected any errors to just show up, you know, like when you run a console app after headbutting the keyboard, it gives you some vague indication that there's a problem with your code.
My story starts with the default template of Xamarin, running just an Android application. I just want to mention again that this is the default template (admittedly I am running VS2019 and .NET Core 3.0 - at the time of writing, .NET Core 3.0 is still in preview).
Anyway, I start writing my app, and everything is running fine. I add a button, and it appears, I do something on button press: it does it - I'm on a roll! Then I add a chunk of code that calls an API... and suddenly the app just doesn't run. It compiles and deploys fine, but it doesn't run. At all.
It occurred to me that this does, potentially, make sense. The code that's generated may now be complete garbage. In the same way as if you headbutted the keyboard in your console app, the C# compiler will simply run and JIT your C# into invalid IL... Except, that's not what happens. No sane (statically typed) compiled system would compile a bunch of crap and deploy it... but hey ho.
So, why would my app not run?
Well, it was down to the following line:
var data = JsonConvert.DeserializeObject<List<MyData>>(contentString);
The reason being that, by default, JSON.Net is not installed in the default template; however, because it (or a version of it) is a dependency of one of the other libraries, it is accessible! Presumably there's a conflict somewhere, or when this compiles it produces a big pile of steaming Java!
(I realiZe it doesn't compile down to Java — but I think you'll agree, steaming IL doesn't have the same ring to it.)
Anyway, the moral of the story is: check your Newtonsoft dependencies, and liberally distribute try/catch blocks everywhere — it seems to be the only way to get a half sensible error from Xamarin.
Published at DZone with permission of Paul Michaels, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
What Is Plagiarism? How to Avoid It and Cite Sources
How to Implement Istio in Multicloud and Multicluster
From CPU to Memory: Techniques for Tracking Resource Consumption Over Time
How to Format Articles for DZone