Good evening, habravchane! Today I would like to write about cross-platform development in general. After all, in fact, people now share the desktop, server and mobile clients and try to look for cross-platform tools in each sector, without looking beyond the scope of each sector. This happens for various reasons. One of the reasons - Vasya knows how to make a desktop in Java, and Petya - how to make apps for iPhone on Objective-C. And no one can even guess that there are technologies that bring all the platforms together.

There is a lot of text and statistics behind the cut.

My performance on the Apps4All Forum. Speech the first, all the errors in the presentation of the material already wound on a mustache.

')

Solvable problems

The first group of problems - product problems

Why do people even go into cross-platform development? What is she for? Let's try to collect a list of problems that arise if you write for each platform separately.

• Does the code for each platform have a single flow? This problem occurs when there is a lack of coordination and relationships in teams writing for different platforms. From the fact that people do not see other code and write each - their own.
• Whether anywhere did not disperse on API? It arises for the same reasons, but another one is added to them: one of them received information about the changes, and the second did not. And if this section of the API is rarely used, then the discrepancy may not be noticed at all.
• Synchronized according to the DB scheme? The roots of this problem will stretch if there is no common storage of documentation (as, incidentally, in the previous example). Each program that uses, for example, local storage, can start to disperse from some kind of a scheme from other platforms simply because people got carried away and forgot to notify others of changes.
• Unit tests for each platform. Has the API changed ??? This is a huge problem. If the business logic is covered with tests (which should be in a good project), then if you change the API or database scheme, in addition to the code, you will have to rewrite all the related unit tests N times, where N is the number of platforms.

Management has no less problems:

• You need to coordinate veneret from Java / Objective-C / ... developers . Well if the manager understands each of the platforms perfectly. And if he had dealt with only one before, and the developers were not experienced ones? Then they will be able to broadcast noodles on their ears, saying that some things are not possible to do, for example (although in reality it’s just too lazy to look for a solution). And if the customer is the developer himself, he will have to blush every time for their antics.
• Depart developer? It is necessary to find under the same platform . This would not be a problem if it were not for the impending release, for example. If you use a cross-platform toolset, you can move developers from other projects. At a minimum, the programming language will be familiar to them. And this is a big help.
• The customer pays for the same code many times . Agree, you must have great skills in selling snow to the Eskimos in order to push through the same thing for 3 platforms. “How much can you integrate with our API? You have already done this twice! ” And you silently understand them, but you continue to insist on your own.
• Has the external API changed? Here, the management is nervously fidgeting in the chair, since they have just paid for three platforms, and starting today, it is necessary to rewrite everything the changes relate to.
• Fix-price adds pain, because you need to very accurately estimate for each platform. And if at the same time the manager does not cook in some platforms, a problem arises: you will have to rely on the evaluations of programmers who cannot evaluate. "Vasya, did you accurately multiply Pi?"
• The customer asked for the same thing, just under another platform . And, again, the whole bunch of problems above.

What would solve the listed problems? They would be solved if all people would use a single platform and the most uniform code. Then all changes would be made only once, and errors would be corrected only once. And if you go through the points above, you will understand that such an approach would reduce almost all of them.

The second group of problems - development tools

Whatever you say, and the development is determined by the tools. After all, if they are convenient and allow you to quickly refactor, simplify the input of routine text, autocomplete input, helping to work in an unknown API, then the code becomes better and more quickly written, which means it is cheaper. Understanding this leads to the idea of ​​using the best development tools on the market without being greedy for buying licenses. Often, the lack of a competent IDE does not allow programmers to make a choice in the direction of a new player in the market for development tools. IDE - scary? Does the transition to the definition of the symbol not work? Your IDE will not become popular. Agree: the transition to cross-platform development means that you most likely will not know the API. And often there will be absolutely your own API and you will have to learn it. If the IDE does not provide support for the code documentation, and by outputting documentation in the tooltips when you hover on methods and classes, it becomes very difficult and you begin to hate, because any access to the Internet is a waste of time and a way out of the stream of consciousness.

The third group of problems - differences in GUI platforms

This group is a group of unsolvable problems. Rather, they can be solved by making a single GUI for all platforms, however, no one user will like this solution: it will not be convenient or familiar. I heard that they tried to solve this problem in Delphi, but the product is quite new and I did not touch it: I can’t say anything. So what differences make solving problems so difficult to do?

• Working with a keyboard and mouse against touching your fingers over small (physically) screens.
• Sustainable, permanent Internet against the rarely included Internet, which sometimes disappears.
• Expandable iron against slow and limited
• On the desktop application open for a long time. Mobile - for a short time.
• UI is different everywhere. Even if it looks like (desktops), there are various hotkeys, various indents and layout rules everywhere.

However, let's try to highlight the pros and cons of both approaches:

• Native UI
  
  • plus: familiar to the user of the platform
  • plus: works fast
  • plus: gives rich opportunities (there are opportunities present on one platform and missing on the rest)
  • plus: the usual UX
  • minus: everywhere is different.
  
  
• Cross-platform UI
  
  • plus: do it once
  • minus: looks the same everywhere
  • minus: not equally familiar to all users
  • minus: often it is a slow decision (due to the need for unification, not always hardware)
  • minus: platform features are not used
  • minus: not the usual UX
  
  

What conclusions can be drawn from here? In order for us to release a product not for ourselves, but for the user, we need to have a toolset that allows us to write the UI for each platform separately.

Trying to choose a development tool.

So, the criteria is selected:

• There is a great IDE, in which a lot of rich and necessary functionality
• Writing code in the same language using a single SDK
• UI is written separately for each of the platforms.
• The maximum amount of a single code. Those. in our case, all that is not UI

Cross-platform categories

• Applications Factories. Application generators We will not consider them, because our goal is to find a rich platform, not a trimmed one.
• Web App Toolkits. We will browse casually
• Cross-platform IDE.

In order to understand yourself, you have to personally use a huge number of cross-platform development tools, of which there are now about 90 pieces (according to research2guidance). And it's not easy to use, but to write on each of them a rather complicated application and hand it over to the application store. This is quite a laborious and costly process, so I decided to look for research on this topic. The investigation led me to the sites of two organizations: research2guidance and VisionMobile.

Consider, perhaps, not all the statistics, but only the one about Xamarin, since the full statistics takes 40 pages and is extensive both for reading and understanding. Everyone will be able to read the full statistics, but my personal conclusions will be given below and briefly.

Recognizability

An important factor for both the developer and the customer is the recognition of what will be used. For a developer, recognition is important because it is easier to enter into a discussion with an employer when looking for work, and they will more often look at resumes. And for the customer, recognition of the toolset is important, because when choosing a contractor, a meticulous customer will look for familiar letters in the company's services. If, at the same time, he was not too lazy to search the Internet for what is currently being used, then if you name something from the set of columns on the left as tools, this will increase the chances of starting cooperation. As you can see, the most recognizable now are Adobe Air, Phone Gap, Xamarin, jQuery Mobile, Unity and Titanium. Among these platforms, Adobe stands alone. Perhaps this is due to the fame of the company itself Adobe. However, the full range of platforms covers only it, Xamarin and Unity 3D. Moreover, Unity is a gaming platform and is not designed for normal applications. And for games, it is number one. However, for business applications, the choice goes like this: If you select the Web frameworks, you need to look in more detail. If the cross-platform IDE, then Xamarin wins in this category.

© research2guidance

Already used in development

The second important statistics: how many people are already used in the development of the toolset.

© research2guidance

However, let me remind you that this chart is extremely not grateful for beginners. For example, Delphi XE3, which came out a few months before they conducted this study. It's a miracle that she got here at all. However, I will return to the favorites and add the first release date for each of the platforms:

1. PhoneGap - 2005 (~ 31%)
2. Adobe Air - 2008 (~ 17%)
3. Unity 3D - 2008 (iPhone / iPad) - (~ 13%)
4. Titanium - 2008 (~ 13%)
5. jQuery Mobile - 2010 (~ 28%)
6. Sencha - 2010 (~ 12%)
7. Marmelade - 2011 (~ 12%)
8. Xamarin - 2011 (~ 12%)
9. Qt Creator - 2012 (not mobile) (~ 14%)

I personally had questions with QT Creator: it was not released for mobile platforms and, probably, an error crept in the report. However, if you look at the growth index and current popularity, I will highlight the following favorites:

1. jQuery (almost as long in 3 years as PhoneGap in 8 years)
2. Marmelade and Xamarin (steady growth over 2 years)

But having recollected our creations, we understand that neither jQuery nor Marmelade suit us. Neither the first nor the second give access to platform features, which is important for us. And in this category remains Xamarin.

Development Performance

© research2guidance

This diagram shows how much development on a particular development tool speeds up the development and testing process, right up to the market. From the diagram we can conclude that Unity 3D and Xamarin are the fastest toolsets in development, and Marmelade and Titanium are the most losing ones. Moreover, note that both favorites are based on the same technology.

Well and the last diagram: if I still haven’t persuaded to use cross-platform tools

© by research2guidance

The vertical axis shows the percentage of people surveyed, and the horizontal one shows their answer to the question: how fast / slowed cross-platform development was your time? Accordingly, the majority answered that it accelerated and the smaller one - which slowed down.

About Xamarin Platform

So, let's begin. If we dig a little bit of history, we will find out that the Xamarin platform of the company I am talking about is far from new. It is rather ancient and takes its roots from the Microsoft .Net Framework cross-platform implementation. This implementation is called mono runtime and it contains almost everything from the .Net world with the exception of the graphical output libraries (they are, but not completely made). However, this disadvantage is easily compensated by a huge plus: it works everywhere on desktops. On Windows, Linux and Mac OS, and it’s fine debugged.

Since the platform is distributed with sources, and is free, the developers did not have any money from it and once decided to start monitoring it with the help of mobile applications. After all, if we compare, then it turns out that there are not so many reasons for a desktop to look for orders for developing cross-platform applications. But for mobile devices, orders to make an application for a part of the platforms or for all the platforms are much more. And there is to remove from the .Net Framework everything that relates to the UI, you get a rich infrastructure with excellent architecture, debugged code and excellent support among the already existing IDEs.

The main problem is to forward the platform API for each platform.

For Java, its own virtual machine rises, because Java is not satisfied with several parameters, among which are not honest generics (which are discussed later), while iOS uses translation of ready-made assemblies obtained from C # in Obj-C. What do we have at the exit?

• A huge number of programming languages ​​in which you can write cross-platform applications. Among them are C #, VB.NET, Boo, Nemerle, JavaScript.

  
  

• The richest .Net Framework infrastructure, and an incredible number of libraries already written under .Net and waiting for you in the github, codeplex, and other, other, other repositories

  
  

• The ability to use any existing libraries with android and ios;

  
  

• The widest community of the most popular at the moment programming language - C # will not leave your questions unanswered.

  
  

• Stable development team, in love with their product, and a fast-growing community (at the moment there are about 500,000 registrations and this number does not think to stop)

  
  

• Reduction of the staff of programmers and the opportunity to hire programmers from other platforms. For example, Windows programmers familiar with C #.

  
  

• Reducing the cost of developing the final product and, consequently, more interested customers.

  
  

I see in front of me an uncultivated field for software companies and freelancers. After all, I myself came from development under Windows and consider this platform to be an excellent toolset for a quick start. Having come to Touch Instinct a little more than half a year ago, today I can write for any platform.

Why is it worth learning C #?

The statisticians who published the programming language popularity index for 2012 called C # the language of the year. They calculated that the popularity of C # grew by as much as 2.3%, which was the largest number of all the languages ​​in the index. Of course, the fact that Microsoft launched Windows 8, where C # is the main programming language, also played its role. But in fact, everything is somewhat different. Nat Friedman, co-founder of Xamarin, outlined in his post 8 reasons why C # is the best programming language for mobile platforms:

1. First-class language support for parallel code execution turns everything that was previously boring and nasty in implementation, which gave rise to a huge amount of potential for errors, places in an easy-to-maintain code. And if we add to this the automatic type inference, lambda expressions, LINQ language and other goodies of the language, then programming turns into a very pleasant process, for which you do not notice how time flies;

   
   

2. Rich features - object-oriented programming and encapsulation make it very easy to structure the code for maximum reuse. And features such as Reflection and Injection of dependencies provide truly rich possibilities for extensibility and application flexibility;

   
   

3. Advanced Runtime . The Garbage collection greatly simplifies development by taking the burden of memory management off the developer. Developers can focus on solving algorithmic and other problems, instead of dealing with pointers and monitoring memory leaks;

   
   

4. As in a strongly typed language, C # does most of the type checking during compilation, which reduces the number of annoying errors and thus speeds up development.

   
   

5. Easy to adapt . C # is a very simple language and is very easy to get used to. But if you are used to, it will be very difficult to break the habit of it, believe me. And if we add to this an insane amount of material, which lies just everywhere, it guarantees any beginner developer that he will never be stuck in one place.

   
   

6. Quick execution . C # on iOS uses the LLVM optimizing compiler, which is used by the C and C ++ languages ​​on which the operating system is based, which gives you the best of both worlds: high C # programming productivity and high efficiency of low-level programming languages. On Android, things are no worse: C # works even better than Java. What can be explained in several ways: C # supports Value Types, real, unlike Java, generics, and non-virtual default methods. Also, of course, this can be explained by the fact that Dalvik is younger than the proven and more verified Mono Runtime.

   
   

7. Access to platform functions makes it possible to use not only the functions of the operating system, but also third-party libraries, originally written for a specific platform, adding to the arsenal of supported, years-old libraries.

   
   

8. And the most important reason: the ability to sport the application on various rafts . If you are writing on the mono platform, then including all supported platforms, you can reach an audience of 2.2 billion devices worldwide with your application. Just think about this figure. This figure alone will force anyone to at least try this platform in development.

   
   

And then, when a customer comes to your office, he wants to order not an application for Android, for example ... Or under iPhone. The customer first wants a mobile application. To his application stood on the maximum number of devices. And if you are on this platform, it allows you to talk about reducing development costs. After all, you not only reduce the development itself. But the alignment of errors. Business logic code will be fixed on Android, on iOS, and on Windows Phone. Yes, it is necessary to develop everything that relates to the UI again on each of the platforms. But the rest of the code will be shared, unchanged. Work with the database, game logic, anything.

Minuses

Among such a variety of advantages, it would not be fair not to talk about some of the disadvantages. Here, I think, those of you who are starting to fall asleep, sharply doused in kraslakh. Well, finally, they say, reached. As with any development of this scale, of course, there are minuses.

• Xamarin Studio is a great IDE, but sometimes there are problems with the debugger. There are problems, everyone knows about them, and I hope this is the number one priority in the near future, sometimes the falling off debugger makes life a little more sad than we would like

  
  

• It is necessary to configure bindings to the platform libraries. If you want to use some kind of compiled, native library, you will have to suffer a little by building a binding. A toolset that makes life easier, but it doesn't always work as we would like: sometimes you have to finish handles

  
  

• We'll have to podparitsya with clearing the memory. The fact is that since we are working not instead of, but together with Java / Obj-C, for example, two Garbage Collectors work in Java. Just do not get scared! Do not leave the hall! Everything is fine, they get along perfectly. But in order to release objects in both, it is necessary to carry out an additional action - release the link. Something like C ++. But what to do. There's nothing you can do.

  
  

However, these drawbacks are more than compensated for by the ease and enjoyment of developing a truly cross-platform code, where only the UI of the application can be made platform-dependent by separating the general application logic into a separate library and using, for example, MVVM. And thereby reduce the time to develop code for the final platform to 80%. This is a huge percentage.

Yuzkeysy

• As all of you, maybe, know, in order to program under iOS you need to have Macs. This is some financial constraint that can upset you if you go from a Windows platform. However, do not be sad. If you already have a license for Visual Studio, have a favorite product from all of us, JetBrains, ReSharper and other Windows platform delights, you can install just one Mac Mini or any other Mac and use it as a build server, while developing Visual Studio.

  
  
• If you don’t have the money for such a cheap tool like Visual Studio, Xamarin has a solution for it. IDE Xamarin Studio is available for you absolutely free, which is MonoDevelop 4.0 version and contains a huge number of refactorings and other handy buns that are needed in development.
  
• You can also develop for Mac using Xamarin Studio. Our whole company does just that. Windows we use only for WinPhone applications.