Compatibility between mobile screens and improving your releases

This time, I going to show you some advice for “Compatibility between mobile screens and improve your releases”.

Compatibility between mobile screens

When we are using Xamarin working with app mobiles, we have a specific structure that we need to respect, if you don’t appreciate that’s rules you will have problems with Compatibility.

Images Resource

Resources Folder

In the resource folder, we’ve many resolution folders that begin with the name “drawable” (hdpi, mdpi, xhdpi, xxhdpi, xxxhdpi are a different container of resolution).

  • HDPI: 160 dpi
  • MDPI: 240 dpi
  • XHDPI: 320 dpi
  • XXHDPI: 480 dpi
  • XXXHDPI: 640 dpi

We can add images resource in whatever folder and use in our mobile app, but what is the problem? the problem is if you put a small image o big image in an incorrect folder, and try to adjust the images for the cellphone, when do you do the release and test the application in another mobile, the image won’t fit on the screen.

To avoid this type of problem put the image on the folder that more adjustments to your image.

Flex Design

This is an important topic that I won’t pass up, the incompatibility between mobile screens start when you don’t start to follow these rules.

  • Make sure that your screen allows different dimensions: That said, keep in mind to use “wrap_content” and “match_parent” in the best case.

wrap_content – The component will only display its content and going to take the component minimum height or width.

match_parent – This one, makes the component fit the size screen of the view.

Improving your releases

Keeping in mind that we have you have your application ready, now is time to make a deployment.

I’m ready but… I’m missing something.


The linker is used in iOS and Android Xamarin projects, to remove unused code from compiled assemblies. This helps to decrease the final size of the apk.

Linker example. Source: Microsoft.

Note: Though the linker is not a great idea when the code is used through reflection, it is usually too rude and starts stripping away methods and fields you are using. This is common if methods are only referenced by reflection.


When the methods or references of your application exceed 65,536 (maximum references or method that .dex file can have), you encounter a build error that indicates your app has reached the limit of the Android build architecture and you need to go to Multi-dex option.

A simple calculation of how many methods has my project:

A simple library of Android like a “AppCompat V7 ” contains 12,324 methods, now count the methods written by you + library third party + Android framework, etc..

so many, no?

Turn off logging

Make sure that you deactivate all logging in your code and disable the debugging option before you build your application in the release mood.

The logging would be very helpful at debugging time, but sometimes we keep it there and can bring consequence to us:

  • It can reveal sensitive data to the exterior(token, user credentials, active session, personal information, etc).
  • It can decrease the performance in your release application.

(You can deactivate logging by removing calls to Log methods in your source files.)


In the end, not going too fast to deployment your mobile application, do a checklist and evaluate all point before of all.

These were some tips to avoid problems with your release, later I’will creates a step-by-step tutorial.

Remember: one app without bug is a trustworthy app.

Feel free to leave me a message or suggestion, see you later on my next post friends of the Internet.



Leave a Reply

Your email address will not be published. Required fields are marked *