Fortsätt till huvudinnehåll

Switching to Android Studio

I thought Xamarin.Forms and Visual Studio would be a mature and stable development environment for developing apps for Android, iOS and UWP. I was wrong.

First, as I wrote in the previous post, it does not work to start the Android Emulator from within Visual Studio. I filed a bug report towards Visual Studio and was informed that the development team is aware of the issue and are planing to release a fix on the 15.8 branch of VS. Not very prioritized to fix apparently.

Second, Xamarin.Forms defaults to using a shared project for the common, not target specific, source files. Shared C# projects uses the new .NET project system by default. The support for XAML and code behind files still has problems in the new system. So, adding new XAML files to your project will not work from within Visual Studio, manual editing of the project files are needed. Also the static code analysis does not work well with XAML files in the new project system so you will get a lot of false errors.

Third, building the Xamarin.Forms projects when targeting Android is painfully slow. It takes minutes to re-compile even a minimal change. I did some tests with Android Studio and similar changes takes a couple of seconds to re-compile compared to minutes with Xamarin.Forms.

Ok, so a lot of complaining. What to do about it? Well, since I don't need multi-platform support right now (I am only targeting Android), I searched for the recommended development suite for just Android and found Android Studio.

Android Studio, as the name implies, is solely meant to be used for building Android apps. If the Android Emulator can't be started from within Android Studio, that will be top priority to fix. Also the build times are A LOT faster than what I experienced with Xamarin.

I will have to code in Java instead of C#, but that's no biggie. Will write more on Android Studio once I have made some more progress on the app.

Kommentarer

Populära inlägg i den här bloggen

C# Enum as bit field

Bit field enum Whenever you wish to express combinations of properties of an object, bit fields are a good way to accomplish this. As a simple example, consider a file in the file system. It can be Readable , Writable , Hidden or a combination these. The different attributes can be defined as an enum : [Flags] public enum FileAttribute {   None      = 0b0000;   Readable  = 0b0001;   Writeable = 0b0010;   Hidden    = 0b0100; } To indicate that this enum is expected to be used as a bit field I have defined it with the FlagsAttribute . It is important to understand that the FlagsAttribute does nothing more than making some changes to how the ToString method of the enum works, making it possible to print out all flags. It does not introduce any validation or special treatment of the enum in any other way. I have defined the values of the different fields of the enum using binary representation, this should make it even more clear that this is a bit field and which bi

Codility tasks - Part I

I was recently faced with two codility tasks when applying for a job as an Embedded Software Engineer. For those of you who arn't familiar with Codility you can check out their website here:  www.codility.com Task one - Dominator The first task was called Dominator. The goal was to, given a std::vector of integers, find an integer that occurs in more than half of the positions in the vector. If no dominator was found -1 should be returned. My approach was to loop through the vector from the first to the last element, using a std::map to count the number of occurences of each integer. If the count ever reached above half the size of the vector I stopped and returned that integer and if I reached the end without finding a dominator I returned -1. So was that a good approach? Well, the reviewer at the company rated the solution as 'pretty ok'. His preferred solution was store the first integer in the array and set a counter to 1. Then loop through the remaining i