Geekly Articles each Day
📜 ⬆️ ⬇️

Automate non-automated, or about Xamarin in real projects

Today we asked one of the pioneers of Xamarin in Russia, Vyacheslav Chernikov, to tell in more detail about his report “The benefits of DevOps and Xamarin.Forms for developing business applications”, which was held during the Developer Day 2017 conference. He also mentioned why his company cultivates an approach to software development, when the product becomes not an artifact, but a working process for creating and developing a product.



Further, the story will be on behalf of the author.

In April 2017 in the wonderful city of Ivanovo, in which there are many beautiful girls, Akvelon organized Developer Day 2017 “Cross-platform development of mobile applications” , where we had a chance to talk about how DevOps and Xamarin.Forms allow us to simplify and speed up the release of mobile business products.


The conference was held at the Ivanovo State Energy University and gathered a full assembly hall of both experienced developers and students. Our colleagues from Notissimus and Akvelon told about interesting things, showed in action a bunch of Xamarin + Azure, as well as the possibilities of ReactNative and Electron.js. The event turned out great and special thanks to the wonderful girls from Akvelon for organizing!



')

In an experimental format, we have prepared for you a transcript of the speech. In this article you will find an abbreviated version. Full version in our blog on Medium .




In my report, I will cover the entire process of developing applications on Xamarin.Forms, and not just the features of the framework, which is just a tool in the hands of the development team. Separately, we will look at how and why DevOps practices are needed in modern mobile application development.




At Binwell, we develop customized mobile and cloud applications. We focus on the .NET stack and Microsoft tools. We carry out the development of a full cycle and proceed from the fact that the product of our work is not an artifact (build or publication), but a process of product development taking into account the business requirements of our customers.


Since 2008 I have been engaged in cross-platform development of mobile applications. Wrote for Qt, mobile web, native, Xamarin. He participated in more than 40 mobile projects based on various technological stacks.




With the advent of the global network, the process of information exchange has greatly accelerated, which in turn led to the transformation of business processes in companies. The speed at which consumers deliver value is becoming critical. The time it takes for releases with new functionality is usually called the Time-To-Market and this parameter becomes very important for many businesses.


I also want to highlight the importance of mobile apps. You, for certain, heard that recently by the number of devices Android bypassed Windows. You need more applications and they will be needed quickly. In this case, both ready-made and custom products of varying complexity will be needed.




I want to start with Xamarin.Forms (for which Microsoft stands now), as one of the most promising mobile application development frameworks, which is gaining increasing popularity and sharing the philosophy of reducing the Time-To-Market parameter.




Everything leads to the fact that for the development of business applications in the future 4 technology stacks will be mainly used: iOS + Swift, Android + Java, Xamarin and ReactNative. Each of the stacks has its pros and cons, which must be weighed before the start of the project.


But the key parameter actually is not just the possibilities of one or another stack, but the presence of competencies and an experienced team that can take into account all the features and offer a solution in difficult situations. We, as techies, usually go off the stack, arrange holivars, although business thinks in the logic of risks, budgets and deadlines.




Speaking of Xamarin, it is worth noting right away that this is primarily the name of the company that was recently bought by Microsoft. But the company currently has three key products: Xamarin Classic (Xamarin.iOS and Xamarin.Android), Xamarin.Forms and Xamarin Test Cloud.


What is now called Xamarin Classic was originally MonoTouch and MonoDroid. Just in case, I’ll clarify that Xamarin creates fully native mobile apps. Yes, there is a minimum overhead due to the conversion of calls and basic data structures, but they are minimal and are compensated for on real projects by acceleration in other places. Classic Xamarin is close in capabilities to development in Swift and Java.


Ever since the early versions of MonoTouch and MonoDroid, enthusiasts have attempted to logically continue what was started and propose solutions that were similar to the current Xamarin.Forms. But the solutions were often raw and limited, so before Xamarin.Forms you still had to implement the interface separately for each platform.




After the classic Xamarin matured and assembled a decent army of developers, Xamarin.Forms was released, which solves a kind of “last mile” task, providing a single API for working with the user interface with minimal involvement of features of each of the target platforms. At the same time, the interface itself remains completely native. That is, in fact, XF is a virtualization of the user interface and a set of additional subsystems like support for the XAML markup language, the common event bus, and the dependency service.


Currently, Xamarin.Forms officially supports iOS, Android, Windows, and Tizen OS previews. Soon they will add support for macOS, plus there is a project on porting XF to WPF.




In order to better understand how XF works, let's consider a simple button. One of the basic mechanisms are renderers, thanks to which when displaying the Xamarin.Forms button, the native control is actually added to the screen, and the properties of the XF buttons are dynamically thrown into the properties of the native button on each platform.




When creating applications on Xamarin.Forms, it is worth paying attention to the user interface performance, so the best practices and component base are very helpful in development.




Architecture occupies a key place in real business projects, since applications need not only to be written, but also developed further. The more problems with architecture, the more difficult will be the further development of the project. In our practice, we use a multi-layered architecture, where each module is isolated from each other and can be moved to a separate subproject.


DAL - data abstraction level.


BL - the level of business logic.


UI - user interface level.




The framework itself, or the stack, is just a tool, but its features must be taken into account from the very first steps of the project. Xamarin.Forms in this case is not an exception, therefore we will consider the development process entirely later.




There are various types of software development processes, among which Waterfalls and Iterative / Spiral have become most popular due to their simplicity. Our company currently uses a hybrid approach, when in the early stages detailed specifications of the project requirements are carried out and the balance between informativeness and formalism (the number of letters in the TK) is maintained.


The first step is to make a list of Feature Points and general application requirements.


Mobile business applications are primarily an interface for interacting with an external business process, so the second step is designing a user interface at the screen level (UX prototype, User Experience), when only rectangles, icons and text are used. This allows you to determine the necessary navigation model (for example, lower tabs or sidebar) and split the functionality and data on the screens and blocks. In our practice, we use the Proto.io service, which at the same time allows us to receive an interactive prototype right on the phone. The main thing - as simple as possible, without design. Based on the UX-prototype, we make a map of transitions and states, which we will talk about later. And already on the basis of this map we formalize the user scripts used in testing.


After coordination with the client, we draw up a unified Private Specification (ČTZ), including an extended description of the functionality, diagrams and descriptions of the screens, as well as a transition map.


Based on the UX prototype, we are preparing the design specifications for each of the screens. After that, the cutting, the necessary icon fonts are already prepared and the specifications and design styles are described.


Further development itself begins, which we will not detail, although there too there are certain regularities and parallelization. At the exit of each development cycle, assemblies appear that go into test (= internal beta testing) or actual operation (= publication and real users), during which events are collected, bugs are generated, crashes are analyzed and product development recommendations are prepared. All this forms a new pool of tasks and so on throughout the product life cycle.


Please note that our process has no ending, since all products live and develop.


Thus, the product of our work is not artifacts (assemblies, publications), but the workflow for the formation of new versions of applications and services. Here's the last loop just fits perfectly on DevOps.




If you were engaged in the development of user interfaces for sites or applications, then you have seen the approach when all screens are printed almost in full size and the interrelations between them are shown with arrows. This is a design-from approach. It only works well if you have less than 10 screens. However, business applications are usually much more complicated and have up to 100 screens (there are more, but this is rather the exception). Therefore, in our work we came to the approach shown in the diagram, when only the names and key states of the screens, as well as transitions between them, are indicated.


Now we can smoothly go over to the description of the Mobile DevOps practices.




By itself, DevOps is not just a set of tools, but a culture and approach to software development, when the product becomes not an artifact, but a working process for creating and developing a product. Mobile DevOps is no exception. And since we have moved into the era of Mobile First, DevOps should also be mobile here. We wrote about this in more detail in an article for Hacker Magazine # 217 .




Let me remind you that the main task of DevOps is to accelerate the production cycle of products (or their new versions) due to reasonable automation and continuous monitoring (= receiving feedback). This is critical for reducing the Time-To-Market setting and introducing flexible work practices.


The figure shows a simplified scheme of the product release cycle. Separately, it is worth noting that of the entire development process it is reasonable to automate. Obviously, it is not yet possible to automate the coding process adequately, since this is a very difficult task requiring complex knowledge and skills. But the assembly, monitoring and even testing (with reservations) is very easy to automate, so the market is now experiencing a real boom of such services.


Of the above works, the most interesting is the testing process. And if with unit tests everything is clear for a long time and any development or build environment can do them, then testing the user interface is more complicated.




What are automated UI tests, experienced developers and testers probably know.


In order for testing to have controlled and controlled targets, the described user scenarios (Use Cases) easily fall on special scripts, instead of which testers previously had to stick their hands into the application to look for errors on a BIG device park. Automation can significantly reduce such checks.


Immediately it should be said that automation does not cancel manual testing, but simply reduces its volume.


So, what does automated UI testing provide? The ability to verify that the required group of scenarios will work correctly on the required fleet of devices and supported versions of operating systems from different manufacturers. For example, an application might work well on Android 6.0, but fall on Android 5.0 or 4.1. Or on any particular device model. Such errors will be immediately revealed during automated testing.


Another very important thing is to check the design on different screen sizes and operating system versions. Nothing should be clipped or floated. All cloud device farms take screenshots of each step for each device, so you will be the first to know about such problems with layout.


So, what tools for DevOps will suit mobile application developers?




If everything is clear with the repository for the code, then many developers can try to build the build system on their lap. If you need adventures, you have a shaman tambourine, a beard and a sweater - this is your way. The rest can be recommended ready-made solutions. One of the best and most inexpensive build tools at the moment is Bitrise, which supports all the popular mobile development stacks, including Xamarin and ReactNative.


For automated UI testing, there are already about a dozen different farms, including services from Amazon and Google. However, Xamarin Test Cloud is one of the most functional and convenient. Therefore, we recommend using it.


If the UI tests were successful, then the application can be passed to manual testing. To do this, it can be downloaded to the HockeyApp service, which also collects statistics and crashes when applications are running.


Now the cycle is closed and there is an understanding about the quality of the product. It is worth adding that Microsoft not so long ago presented its integrated DevOps pipeline based on the Xamarin Test Cloud and HockeyApp called Visual Studio Mobile Center . It is still in the Preview stage and has significant limitations, but it is quite suitable for dating. We talked about him in Hacker # 218 .


Summarizing, we give a few numbers.




The slide shows the average figures for our projects based on Xamarin.Forms using the described DevOps pipeline. These are typical numbers from the start of the project to the release of the first version:



In general, the described approach not only saves time, but also significantly simplifies the development process, eliminates the routine, and leaves only the coding to the developers.


PS Ask your questions in the comments!



about the author


Vyacheslav Chernikov - head of development at Binwell . In the past, he was one of the Nokia Champion and Qt Certified Specialists, currently he is the Xamarin and Azure platform specialist. He came to the sphere of mobile in 2005, since 2008 he has been developing mobile applications: he started with Symbian, Maemo, Meego, Windows Mobile, then switched to iOS, Android and Windows Phone. Articles Vyacheslav you can also read the blog on Medium .

Other articles by the author:



On May 20, a unique event for Xamarin developers will take place in St. Petersburg - the first Xamarin Dev Days in Russia . It is focused on strengthening the Xamarin community, gaining practical skills and training, so it is perfect for novice mobile device developers. These skills will help to create, test and connect native applications for iOS, Android and Windows. Join now , the event is designed for only 50 people.

Source: https://habr.com/ru/post/327900/

More articles:


All Articles