Clients often want their website available in the app store, mostly just for app store presence. I got asked to do app wrapping at work a while ago, because the client purchased a tool that did not have a native app available, only a mobile website. It just had to be made available in the internal app store. Colleagues had to be able to install it by themselves and use it on their own devices without too much fuzz.
In this post I want to show you some of the hurdles while developing a website wrapper and how to overcome them.
Last week, the nightly build of my Android project failed all of a sudden. It was apparently related to the 64k method limit than Android poses for DEX-files. I wasn’t aware how much impact the NuGet packages have on that method count. I want to show you my journey to resolving this issue.
When you run into the 64k limit, you can use ProGuard and Multi-Dex to resolve the issue. Make sure to update ProGuard when you use Xamarin.Android 7.2 or lower and target API level 24+.
64k method limit
Android apps run on Dalvik or ART (Android Runtime), depending on the Android version you use. Dalvik has a few limitations, including the 64k method limit. In a DEX-file (which stands for Dalvik Executable), you can only reference the first 65,536 methods. If you exceed that limit you get the following build error in Xamarin:
Tool exited with code: 2.
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Common.targets : error : trouble writing output: Too many field references: 74105; max is 65536.
My app itself was only consuming 2500 methods of the total. So the rest was added through NuGet packages. The biggest method consumers were the Android support libraries (40503 methods), Google for Analytics (19930 methods) and Firebase for notifications (7258 methods).
Have you always wondered how Xamarin Forms does it’s “magic”? Knowing how things work under the hood is super valuable, especially when things go wrong. This enables you to detect the issue yourself, without having to rely on the knowledge of other developers. In this article a part of the magic of Xamarin Forms will be unraveled, as we take a look under the hood.
Choosing the right tool for the job is always a tricky task. There are so many things to take into consideration. The saying “choosing is losing” is certainly applicable here. Every choice has its pro’s and con’s, and as a colleague said: “you will always be looking for the one thing that’s harder to do in the choice you made”. All it boils down to is making a choice, and sticking to it for a while. Since development lifecycles go so fast, expecially open-source, there might even be a better choice by tomorrow. This can create something we all know as “developers block”, not being able to deliver a single thing. And you will drive yourself crazy over all the options. Same goes for the choice between Xamarin or other platforms, and even for choices within the Xamarin platform itself. In this case the choice between Xamarin Native vs Xamarin Forms.