5 Xamarin.Forms Debugging Nightmares And Their Solutions

Xamarin.Forms debugging

What’s up everyone ?. This week we are going to talk about Xamarin.Forms debugging. I know, it’s been a while since I made a blog post about Xamarin.Forms. But, I had to explore other lands of the vast software development kingdom ?. My journey away from Xamarin.Forms could have been longer, but I decided to get back home earlier. I hopeat least that readers of Planet Xamarin missed me (Though the probability is low ?).

Let’s get serious ?. So, as a Xamarin.Forms developer, you may have come across several issues while debugging. These issues may sometimes come in the form of error messages in your code. Or in the form of unexpected difficulties in performing simple tasks with the framework. I have faced the frustration which comes with such issues. But with the help of online communities like (the Xamarin Forum, Stackoverflow…) and Google, I overcame most of them. I’m not yet a Xamarin.Forms expert, but thanks to the tips I gathered from these sources, and countless hours spent working with this framework, I could solve these issues, adopt a way of debugging my code which permits me to go through these issues more easily than before. This article is a small summary of 5 Xamarin.Forms debugging issues anyone may face and their solutions.

5 Xamarin.Forms Debugging Nightmares And Their Solutions

1- Install Xamarin Suport Package issues

This issue comes most often in Xamarin.Android projects. It is very confusing at first sight. It comes in the form of an error message very similar to this : Please install package: ‘Xamarin.Android.Support.Design’ available in SDK… .The solution for this is tricky. here it is : navigate this directory: C:\Users\you\AppData\Local\Xamarin\ delete the packages present there. After that, rebuild your project, and it should be fine. If it persists, follow this video with detailed instructions about how to solve this issue.

2- Illegal State Exception

This exception is also very common. This exception often appears as : Java.Lang.IllegalStateException: Can not perform this action after onSaveInstanceState. Like what James Montemagno explained in his blog post;

This is due to the heavy use of async/await, plugins, and developers attempting to navigate too quickly.

As what he says in this same article, the solution is to not try to perform navigation directly after an async/await operation. You should wait and even delay the thread for some time before continuing with navigation (Be it a Pop or Push).

3- Deploys fail on android emulator, Android emulator is too slow …

There are some issues which are unexpected when you encounter them for the first time, and in my opinion, this is one of them. You may have one of these two issues when using the emulator. Or you may even have other emulator related issues. In the case where deploys fail on the android emulator, doing the following can save your day.

Get your emulator’s ip address as it is running, most often, 127.0.0.1 worked for me.
Open the adb.exe command line tool. Go to the location of your sdks and navigate to (android-sdk\platform-tools).
Run this tool on your command prompt and type in adb connect [the emulator ip address] . “without the square brackets”.
Run your app normally on the emulator and it should deploy now.

If you are facing any other Xamarin.Forms debugging issue related to the emulator. Or this solution did not work for your, this documentation will surely work for you and help you solve your problem.

4- Break points are not hit on UWP

If you are debugging on UWP, and you set breakpoints but they are not hit, don’t worry. The solution is simple. Do the following.

Open the .Net standard shared project in edit mode
Paste the following code in it
<PropertyGroup> <DebugType>pdbonly</DebugType> </PropertyGroup>
1
2
3
<PropertyGroup>
<DebugType>pdbonly</DebugType>
</PropertyGroup>

After building and deploying the solution, it should now work. And break points should be hit normally.

5- A ghost exception is thrown (unhandled exception occurred)

What I call a ghost exception is an exception which comes from nowhere and has little or no information about its occurrence. Most of the time, these exceptions are nested. So, to get their real meaning, either surround them with a try catch. Or wait for it to break at run-time and in both cases, examine their Inner Exceptions with much attention, and chances are, you will find the real cause of the exception. Else, sometimes, just cleaning, and rebuilding the solution works or even restarting your IDE.

Conclusion

Those are 5 Xamarin.Forms debugging nightmares you may face and solutions to overcome them. This list is very small, and I plan to do another very soon, containing more tips.You may have several difficulties while debugging, but most of the time, paying much attention to your code, adopting the habit of inspecting elements of an exception which occurred (Like its message, stack-trace, inner exception…) and a Google search may save your day.

You may be interested about 5 Reasons why LINQ can be addictive to .Net developers.

If this post was useful to you, follow me on Twitter, Github, Linkedin, or like my Facebook page to stay updated.

Follow me on social media and stay updated