Details about Xamarin
Do you have a good command of the C # language and the .NET platform as a whole? Are you tired of standing apart and watching someone else write cool mobile apps for you? I have something interesting for you! Something that will help you change the current situation and allow you to write great mobile applications without requiring separate study of Objective-C and Java. I will tell you about the product Xamarin. Detailed and true.
Xamarin is a framework for cross-platform development of mobile applications (iOS, Android, Windows Phone) using C #. The idea is very simple. You write code in your favorite language, using all of your usual language features such as LINQ, lambda expressions, Generic `s and async` s. At the same time, you have full access to all the capabilities of the SDK platform and the native UI creation mechanism, receiving an application as a result, which, strictly speaking, is no different from the native ones and (at least according to assurances) is not inferior to them in performance.
The framework consists of several main parts:
Some time ago, a number of frameworks (for example, PhoneGap ), which offer the development of cross-platform mobile applications in HTML5 using JavaScript, became quite widely known. The idea is that the application is developed as a regular site for mobile devices using the appropriate js libraries, for example, Jquery Mobile. Then all this is packaged in a container that looks to the user as a native application. The disadvantages of these frameworks are obvious: firstly, you do not have access to native UI elements. That is, even if you want to use the standard “Back” button for the iPhone, you must draw it and impose it. Secondly, you get a stripped-down and generalized API for working with the platform. Thus, certain features inherent in a particular platform will not be available to you. Well, the third and most important thing is that such an application is physically launched inside the phone's browser (more precisely, within the WebView control). There is no need to paint for a long time what this means: poor performance (especially “good” of WebView on older versions of Android) and huge display problems (well, gentlemen, this is the browser). Although, of course, in certain cases, these frameworks may be very appropriate.
')
Xamarin is about something else. Since I hope that we are all here -stupid guys, developers, I will tell you about how it works inside. This will allow you to understand the potential of this technology. Xamarin is based on the open-source implementation of the .NET platform - Mono . This implementation includes its own C # compiler, runtime, as well as the main .NET libraries. The goal of the project is to allow programs written in C # to run on non-Windows operating systems — Unix, Mac OS, and others. It is important that the same people are involved in the development of Xamarin as the development of Mono. And (attention here) is NOT Microsoft with all the resulting advantages and disadvantages.
From the point of view of the execution of applications between iOS and Android, there is one key difference - the way they are precompiled. As you know, for the execution of applications in Android uses a virtual Java-machine Dalvik. Native applications that are written in Java are compiled into some intermediate byte-code that Dalvik interprets into processor commands at the time the program is executed (that is, like the CLR works in .NET). This is the so-called Just-in-time compilation (compilation on the fly). IOS uses a different compilation model - Ahead-of-Time (compile before execution). Xamarin takes this distinction into account by providing separate compilers for each of these platforms, which allow you to get real, native applications that run outside the context of the browser and can use all the hardware and software resources of the platform.
For iOS, the situation is simple - there is no virtual machine and the program code should simply be compiled into the machine one in advance. For this purpose, AOT compiler Mono is used.
For Android more interesting. When the application is compiled, the code is translated into C # into an intermediate byte-code that is understandable to the Mono virtual machine and this virtual machine itself is also added to the packaged application. Both Mono and Dalvik are written in C and work on top of the Linux kernel (and we remember that Android is based on Linux). You already understand what is happening. When you run an application on Android, both virtual machines start to work side by side and exchange data through a special wrapper mechanism.
I'll tell you more about the libraries themselves on the example of Xamarin.iOS (Monotouch), since experience with it is much more than with Xamarin. Android (but everything is the same there).
The class library Monotouch.dll provides access to all features of the iOS SDK. For a developer, it's just a set of C # classes with good annotation. Inside, these classes are used by Xamarin engineers developed binding mechanisms for native classes and methods. It is important that the same mechanism can be used to bind any libraries written in objective-c. Most of the classes and methods are named the same as in the original iOS SDK, although there are exceptions (in this case, you have to use the search in the Xamarin documentation for the original name, since it appears in the binding attributes). Classes actively use the C # event mechanism, which allows you to write beautiful and compact handler code using lambda expressions:
And in general, the code written in C # looks much more readable and more pleasant. Look at the difference for an example of code creating a string with attributes:
For asynchronous development, Xamarin provides the ability to use both the classes from the System.Threading.Thread and System.Threading.ThreadPool namespaces, as well as the full range of features provided by Task Parallel Library . The use of the latter, however, is considered preferable. In addition, at the time of this writing, the next Stable version was released, in which support for .NET 4.5 appeared, in particular, you can now use the keywords async / await. Although this feature was available before, but for this it was necessary to use the beta channel of updates.
The limitations in Xamarin.iOS are mainly due to the fact that in iOS, as mentioned above, in contrast to .NET and Mono there is no virtual machine. Therefore, there are difficulties with the support of Generic. The reason is clear - the compiler has the task of analyzing the code and determining all possible instantiations in a particular class and method. From here there are such restrictions:
Other restrictions, for example, the lack of support for dynamic code generation, in my opinion, are not very significant. Read more about them here for iOS and here for Android .
For each platform, Xamarin provides the ability to use native UI development tools and native user interface elements. For Android, creating a UI can occur directly in the code or using a declarative approach with a description of the interface in XML. For iOS, this is also either code or the use of native interface design tools — individual xib files or one large Storyboard. Editing of these files occurs in the usual for the iOS-developer Xcode environment. And that means you need a Mac. Yes, in order to develop iOS applications, you will need a Mac anyway for two reasons:
First, as I said, to edit the UI in the Xcode environment. Secondly, to debug applications, an iPhone / iPad simulator is required, which is also available only on Mac.
Xamarin, according to the developers, is a means of cross-platform development, i.e. It is expected that an application written once may be launched on various mobile platforms. But, in this case there is a conflict with the previous paragraph. How so?
In fact, the situation is as follows. For each platform, you need to implement your own UI layer. Ie the code that is responsible for the appearance of the application, you have to write for each platform separately. This is the price for the possibility of using native UI mechanisms. If you break the application into layers, you get the following scheme:
Cross-platform are all layers located above the Application Layer. The proportion of portable code depends quite strongly on the application itself, but, in my opinion, it can hardly exceed 50-60%. Xamarin engineers understand this, and therefore strive to increase this share. As achievements in solving this problem, we can consider the Xamarin.Mobile library. It provides a single API for working with the camera, contacts and geo-location. But the use of this library does not limit you in any way in the application of the platform-dependent API, for example, using the mechanism of delegates.
Xamarin has its own third-party component store, Xamarin Components . It integrates into the IDE and allows you to connect various components to your project, written by both Xamarin engineers and third-party developers, in a few clicks. The number of components, by the way, is growing by leaps and bounds. There are both paid and free (at the moment most of them). All components can be divided into two parts. Some provide additional elements of the user interface, others are class libraries. For example, the option for Mono known library for working with Json - Json.NET or the library for interacting with Rest-services - RestSharp . Not all components are cross-platform, many are only available for a specific platform. As I mentioned above, Xamarin uses a bindings mechanism to associate with native class libraries, which allows you to port any native class libraries to C #. In addition, for Xamarin.iOS, for example, there is a special utility that can generate such bindings automatically. Actually, this allows Xamarin engineers to keep up with all the innovations of iOS. So, in particular, in Xamarin.iOS almost immediately after the release it became possible to use the Dropbox API, as well as new features of iOS 7.
Xamarin has excellent documentation containing detailed tutorials, snippets, and an impressive base of examples. The documentation directly on all classes of the Monotouch and Monodroid libraries are part of the general Mono documentation . But, unfortunately, this is still not enough to cover the whole layer of questions that may arise during the development process. Xamarin has a developer community, which is focused on the official forum and on StackOverlow . I cannot boast about the activity and initiative of people in the community. Of the five questions asked in the official forum, I received an answer for only one. Maybe not asked. In this regard, private assistance provided invaluable assistance. support with engineers by email, available in a business license. They answer, as a rule, within a few hours and not with standard replies “try to turn it off and on”, but really understand the problem and help to solve it. It should be understood that the base of questions and answers accumulated for native development is much broader than for Xamarin, therefore, no matter how you would like, you will have to understand the specific syntax of objective-c (there should not be any problems with Java) to understand code examples on the same StackOverflow. In addition, it will give you access to reading and understanding the official documentation for the platform, which at a certain stage can become very important. On the other hand, there is a positive point in this: having obtained such a basis, it will be easier for you to switch to native development if necessary.
The developers of Xamarin as a development environment suggest using either their own IDE - Xamarin Studio, or Visual Studio (in the business license, see below).
Xamarin Studio is a cross-platform IDE that works on both Mac OS X and Windows. In appearance, it looks very simple and friendly, but behind the external simple one is a rather powerful tool that includes many features familiar to us in Visual Studio and Resharper:
Time of the bitter truth! In the process of use, other interesting features have also opened. I used Xamarin Studio on Mac, so all of the following applies to Mac OS X:
Xamarin offers the opportunity to develop in Visual Studio after installing a special plug-in, which is available in a business license (at the time of publication of the article - $ 999), but there is a trial month. The advantages are obvious: you become a mobile application developer, without changing the location, and you can use all the heavy artillery in the person of Resharper and your other favorite plug-ins. After installing the plug-in for Visual Studio, you will need to set up a connection with your Mac, which will be used when you run the project for execution. Those. after launch, the application is automatically sent to the Mac, where it is compiled and downloaded either to the simulator or to the device, while the process itself is debugging, setting breakpoints, etc. will occur in visual studio.
There are several options for working in Visual Studio. Either you are using a virtual machine inside a Mac (for example Parallels), where you install Windows and Visual Studio. Or use two different physical machines, while using one Mac for several PC developers is difficult, because debugging requires manipulation with the simulator. And the last option is to use a virtual machine with Mac OS X (the so-called hackintosh). Quite a viable option, although there are some limitations. For example, in Xcode you will have to navigate the Storyboard only using scroll bars, since windows-mouse is not very similar to a real mouse from a Mac with all the consequences.
Time of the bitter truth. There are occasional problems with debugging in Visual Studio. The most noticeable is that with a remote build of the application, the debugging process could fall off by timeout. Although, again, it is worth paying tribute to the developers - they fix errors rather intensively, and now at the time of this writing, the debugging process has become stable. Although it is worth noting that at the moment, the time between running the application and its appearance on the simulator screen when using Visual Studio requires a bit more than when using Xamarin Studio on a Mac.
At the time of writing, Xamarin has the following license types:
Please note that for each platform (iOS, Android) you need a separate license. Despite the fact that the Business license says “per developer”, at the moment each license can be activated on 4th workstations and these workstations can be changed. Those. hypothetically, two developers can use one license, while each of them will use Visual Studio for development.
Currently, Xamarin technology is a serious tool for solving complex problems in the development of mobile applications. Despite this, the development team does not stop and continues its active development and improvement. Over the past two months, significant improvements have been observed in the overall stability of the product. In my opinion, technology has a great future, and every day the number of developers using it as the main development framework will grow steadily. However, the rather high cost of a license can be an obstacle to use in the way of indie-developers. In general, I consider my experience with this framework to be positive and will continue to use it.
You can download the framework on the official website - www.xamarin.com . Excellent start up guides: iOS , Android .
Thanks to everyone who has found the strength to read to the end :)
What is it?
Xamarin is a framework for cross-platform development of mobile applications (iOS, Android, Windows Phone) using C #. The idea is very simple. You write code in your favorite language, using all of your usual language features such as LINQ, lambda expressions, Generic `s and async` s. At the same time, you have full access to all the capabilities of the SDK platform and the native UI creation mechanism, receiving an application as a result, which, strictly speaking, is no different from the native ones and (at least according to assurances) is not inferior to them in performance.
The framework consists of several main parts:
- Xamarin.IOS is a class library for C # that provides developers with access to the iOS SDK;
- Xamarin.Android - class library for C #, which provides developers with access to the Android SDK;
- Compilers for iOS and Android;
- IDE Xamarin Studio;
- Plugin for Visual Studio.
Let's more
Some time ago, a number of frameworks (for example, PhoneGap ), which offer the development of cross-platform mobile applications in HTML5 using JavaScript, became quite widely known. The idea is that the application is developed as a regular site for mobile devices using the appropriate js libraries, for example, Jquery Mobile. Then all this is packaged in a container that looks to the user as a native application. The disadvantages of these frameworks are obvious: firstly, you do not have access to native UI elements. That is, even if you want to use the standard “Back” button for the iPhone, you must draw it and impose it. Secondly, you get a stripped-down and generalized API for working with the platform. Thus, certain features inherent in a particular platform will not be available to you. Well, the third and most important thing is that such an application is physically launched inside the phone's browser (more precisely, within the WebView control). There is no need to paint for a long time what this means: poor performance (especially “good” of WebView on older versions of Android) and huge display problems (well, gentlemen, this is the browser). Although, of course, in certain cases, these frameworks may be very appropriate.
')
Xamarin is about something else. Since I hope that we are all here -
From the point of view of the execution of applications between iOS and Android, there is one key difference - the way they are precompiled. As you know, for the execution of applications in Android uses a virtual Java-machine Dalvik. Native applications that are written in Java are compiled into some intermediate byte-code that Dalvik interprets into processor commands at the time the program is executed (that is, like the CLR works in .NET). This is the so-called Just-in-time compilation (compilation on the fly). IOS uses a different compilation model - Ahead-of-Time (compile before execution). Xamarin takes this distinction into account by providing separate compilers for each of these platforms, which allow you to get real, native applications that run outside the context of the browser and can use all the hardware and software resources of the platform.For iOS, the situation is simple - there is no virtual machine and the program code should simply be compiled into the machine one in advance. For this purpose, AOT compiler Mono is used.
For Android more interesting. When the application is compiled, the code is translated into C # into an intermediate byte-code that is understandable to the Mono virtual machine and this virtual machine itself is also added to the packaged application. Both Mono and Dalvik are written in C and work on top of the Linux kernel (and we remember that Android is based on Linux). You already understand what is happening. When you run an application on Android, both virtual machines start to work side by side and exchange data through a special wrapper mechanism.This is all good, but come closer to working out.
I'll tell you more about the libraries themselves on the example of Xamarin.iOS (Monotouch), since experience with it is much more than with Xamarin. Android (but everything is the same there).
The class library Monotouch.dll provides access to all features of the iOS SDK. For a developer, it's just a set of C # classes with good annotation. Inside, these classes are used by Xamarin engineers developed binding mechanisms for native classes and methods. It is important that the same mechanism can be used to bind any libraries written in objective-c. Most of the classes and methods are named the same as in the original iOS SDK, although there are exceptions (in this case, you have to use the search in the Xamarin documentation for the original name, since it appears in the binding attributes). Classes actively use the C # event mechanism, which allows you to write beautiful and compact handler code using lambda expressions:
button.TouchUpInside += (s, o) => { message.Text = "Hello!"; }; And in general, the code written in C # looks much more readable and more pleasant. Look at the difference for an example of code creating a string with attributes:
For asynchronous development, Xamarin provides the ability to use both the classes from the System.Threading.Thread and System.Threading.ThreadPool namespaces, as well as the full range of features provided by Task Parallel Library . The use of the latter, however, is considered preferable. In addition, at the time of this writing, the next Stable version was released, in which support for .NET 4.5 appeared, in particular, you can now use the keywords async / await. Although this feature was available before, but for this it was necessary to use the beta channel of updates.
What with restrictions?
The limitations in Xamarin.iOS are mainly due to the fact that in iOS, as mentioned above, in contrast to .NET and Mono there is no virtual machine. Therefore, there are difficulties with the support of Generic. The reason is clear - the compiler has the task of analyzing the code and determining all possible instantiations in a particular class and method. From here there are such restrictions:
- It is not recommended to use Virtual Generic methods, as the compiler is not omnipotent and may not take into account all possible uses;
- You cannot create Generic-descendants from the NSObject class, which is the base class in the Objective-C hierarchy. Quite a serious limitation, which can in some way spoil your slim and beautiful architecture.
Other restrictions, for example, the lack of support for dynamic code generation, in my opinion, are not very significant. Read more about them here for iOS and here for Android .
UI development
For each platform, Xamarin provides the ability to use native UI development tools and native user interface elements. For Android, creating a UI can occur directly in the code or using a declarative approach with a description of the interface in XML. For iOS, this is also either code or the use of native interface design tools — individual xib files or one large Storyboard. Editing of these files occurs in the usual for the iOS-developer Xcode environment. And that means you need a Mac. Yes, in order to develop iOS applications, you will need a Mac anyway for two reasons:
First, as I said, to edit the UI in the Xcode environment. Secondly, to debug applications, an iPhone / iPad simulator is required, which is also available only on Mac.
Code Portability
Xamarin, according to the developers, is a means of cross-platform development, i.e. It is expected that an application written once may be launched on various mobile platforms. But, in this case there is a conflict with the previous paragraph. How so?
In fact, the situation is as follows. For each platform, you need to implement your own UI layer. Ie the code that is responsible for the appearance of the application, you have to write for each platform separately. This is the price for the possibility of using native UI mechanisms. If you break the application into layers, you get the following scheme:
- Data Layer (DL) - Data storage, for example, SqlLite database or xml files;
- Data Access Layer (DAL) - Wrapper over storage for CRUD operations;
- Business Layer (BL) - The layer containing the business logic of the application;
- Service Access Layer (SAL) - The layer responsible for interacting with remote services (Rest, Json, WCF);
- Application Layer (AL) - A layer containing platform-specific code, in other words, it is code that depends on the monotouch.dll or monodroid.dll libraries;
- User Interface Layer (UI) - The user interface layer.
Cross-platform are all layers located above the Application Layer. The proportion of portable code depends quite strongly on the application itself, but, in my opinion, it can hardly exceed 50-60%. Xamarin engineers understand this, and therefore strive to increase this share. As achievements in solving this problem, we can consider the Xamarin.Mobile library. It provides a single API for working with the camera, contacts and geo-location. But the use of this library does not limit you in any way in the application of the platform-dependent API, for example, using the mechanism of delegates.
Third Party Components
Xamarin has its own third-party component store, Xamarin Components . It integrates into the IDE and allows you to connect various components to your project, written by both Xamarin engineers and third-party developers, in a few clicks. The number of components, by the way, is growing by leaps and bounds. There are both paid and free (at the moment most of them). All components can be divided into two parts. Some provide additional elements of the user interface, others are class libraries. For example, the option for Mono known library for working with Json - Json.NET or the library for interacting with Rest-services - RestSharp . Not all components are cross-platform, many are only available for a specific platform. As I mentioned above, Xamarin uses a bindings mechanism to associate with native class libraries, which allows you to port any native class libraries to C #. In addition, for Xamarin.iOS, for example, there is a special utility that can generate such bindings automatically. Actually, this allows Xamarin engineers to keep up with all the innovations of iOS. So, in particular, in Xamarin.iOS almost immediately after the release it became possible to use the Dropbox API, as well as new features of iOS 7.
Documentation and community
Xamarin has excellent documentation containing detailed tutorials, snippets, and an impressive base of examples. The documentation directly on all classes of the Monotouch and Monodroid libraries are part of the general Mono documentation . But, unfortunately, this is still not enough to cover the whole layer of questions that may arise during the development process. Xamarin has a developer community, which is focused on the official forum and on StackOverlow . I cannot boast about the activity and initiative of people in the community. Of the five questions asked in the official forum, I received an answer for only one. Maybe not asked. In this regard, private assistance provided invaluable assistance. support with engineers by email, available in a business license. They answer, as a rule, within a few hours and not with standard replies “try to turn it off and on”, but really understand the problem and help to solve it. It should be understood that the base of questions and answers accumulated for native development is much broader than for Xamarin, therefore, no matter how you would like, you will have to understand the specific syntax of objective-c (there should not be any problems with Java) to understand code examples on the same StackOverflow. In addition, it will give you access to reading and understanding the official documentation for the platform, which at a certain stage can become very important. On the other hand, there is a positive point in this: having obtained such a basis, it will be easier for you to switch to native development if necessary.
Development environment
The developers of Xamarin as a development environment suggest using either their own IDE - Xamarin Studio, or Visual Studio (in the business license, see below).
Xamarin studio
Xamarin Studio is a cross-platform IDE that works on both Mac OS X and Windows. In appearance, it looks very simple and friendly, but behind the external simple one is a rather powerful tool that includes many features familiar to us in Visual Studio and Resharper:
- Nice syntax highlighting;
- Auto-completion code (including the ability to simultaneously import namespaces);
- Convenient universal search by file names, types, members of classes, etc .;
- Developed project navigation capabilities: Quick transition to class description, transition to base class, list of class use points, etc .;
- Various refactoring mechanisms and quick help (like alt + Enter in Resharper);
- Well-developed debug mechanisms, including tracking, viewing the current value of a variable during hover, stream visualization and the Immediate window analogue in VS;
- Built-in integration with version control systems: SVN, Git and TFS (for TFS, however, third-party utilities are needed);
Time of the bitter truth! In the process of use, other interesting features have also opened. I used Xamarin Studio on Mac, so all of the following applies to Mac OS X:
- Hot keys (including copy-paste) work only in the English layout. Developers are aware of this issue. Bug in the bugtracker;
- Periodically, when trying to put a breakpoint, the studio hangs. Despite the presence of an autosave mechanism, this is a bit frustrating.
- When using the built-in integration with SVN, adding new files to a project is not automatically tracked. Those. the change in the .csproj file zachinkinitsya, but the files themselves - no. For each file you need to right-click and add it to the repository. Technical support reported that they know about this bug and they will fix it in one of the next updates.
- Sometimes the project stops compiling. It is treated by restarting the studio.
Visual studio
Xamarin offers the opportunity to develop in Visual Studio after installing a special plug-in, which is available in a business license (at the time of publication of the article - $ 999), but there is a trial month. The advantages are obvious: you become a mobile application developer, without changing the location, and you can use all the heavy artillery in the person of Resharper and your other favorite plug-ins. After installing the plug-in for Visual Studio, you will need to set up a connection with your Mac, which will be used when you run the project for execution. Those. after launch, the application is automatically sent to the Mac, where it is compiled and downloaded either to the simulator or to the device, while the process itself is debugging, setting breakpoints, etc. will occur in visual studio.
There are several options for working in Visual Studio. Either you are using a virtual machine inside a Mac (for example Parallels), where you install Windows and Visual Studio. Or use two different physical machines, while using one Mac for several PC developers is difficult, because debugging requires manipulation with the simulator. And the last option is to use a virtual machine with Mac OS X (the so-called hackintosh). Quite a viable option, although there are some limitations. For example, in Xcode you will have to navigate the Storyboard only using scroll bars, since windows-mouse is not very similar to a real mouse from a Mac with all the consequences.
Time of the bitter truth. There are occasional problems with debugging in Visual Studio. The most noticeable is that with a remote build of the application, the debugging process could fall off by timeout. Although, again, it is worth paying tribute to the developers - they fix errors rather intensively, and now at the time of this writing, the debugging process has become stable. Although it is worth noting that at the moment, the time between running the application and its appearance on the simulator screen when using Visual Studio requires a bit more than when using Xamarin Studio on a Mac.
Licenses
At the time of writing, Xamarin has the following license types:
- Starter - Free. Calculated rather for review, because has a limit on the size of the application (it feels very small, because even some sample projects have not compiled) and on the use of third-party components;
- Indie - $ 299 per job. The restriction on the size of the application is removed. Development is possible only in Xamarin Studio;
- Business - $ 999 per job. There is a possibility of development in Visual Studio and private tech. support from Xamarin engineers;
- Enterprise -1899 $ per workplace. As part of this license, it is possible to get Hotfixes (I don’t see much sense, since updates are released very often), as well as the opportunity to send the project with the source code to the engineers and say "Something I can’t change the width of the cell in table, help! Plus a number of not very useful, in my opinion, options.
Please note that for each platform (iOS, Android) you need a separate license. Despite the fact that the Business license says “per developer”, at the moment each license can be activated on 4th workstations and these workstations can be changed. Those. hypothetically, two developers can use one license, while each of them will use Visual Studio for development.
Conclusion
Currently, Xamarin technology is a serious tool for solving complex problems in the development of mobile applications. Despite this, the development team does not stop and continues its active development and improvement. Over the past two months, significant improvements have been observed in the overall stability of the product. In my opinion, technology has a great future, and every day the number of developers using it as the main development framework will grow steadily. However, the rather high cost of a license can be an obstacle to use in the way of indie-developers. In general, I consider my experience with this framework to be positive and will continue to use it.
You can download the framework on the official website - www.xamarin.com . Excellent start up guides: iOS , Android .
Thanks to everyone who has found the strength to read to the end :)
Source: https://habr.com/ru/post/188130/
All Articles