Cross-platform developer experience
GuideAndreia Gaita delivered a speech entitled cross-platform developers self-white at the OSCON open-source conference. She has been engaged in open-source work for a long time and is committed to creating Mono projects.. NET open-source projects used in Linux), mainly for C #/C ++ development. Andreia works at GitHub and focuses on building the GitHub Extension Manager for Visual Studio.
Before giving her a speech, I couldn't wait to ask her about cross-platform development and ask her what she learned as a cross-platform developer over the past 16 years.
In cross-platform code development, what are the simplest and most difficult code languages you have used?A: I seldom discuss the quality of A language, but more about the libraries and tools used in those languages. The language compiler, interpreter, and build system determine the difficulty of using them for cross-platform development (or whether they may be used for cross-platform development ), the available UI Library and the ability to access the local system determine the closeness of integration with the operating system. In my opinion, C # is the most suitable for cross-platform development. This language includes the ability to allow fast local calls and precise memory ing. If you want your code to interact with the system and local function libraries, you need these features. When I need very special system functions, I will switch to C or C ++.
What are your cross-platform development tools or abstraction layers?A: most of my cross-platform work is to develop tools, libraries, and Bindings for other people who need to develop cross-platform applications. MONO/C # and C/C ++ are generally used. At the abstract level, I have not used much, but mostly in the glib library and youyuan. Most of the time, I use Mono to complete a variety of cross-platform applications, including the UI, or occasionally use Unity3D in game development. I often use Electron (the brother project of the Atom Editor, which can be used to develop desktop applications ).
Which building systems have you ever touched on? Is the difference between them caused by different languages or platforms?I tried to select a build system that fits my language. In this way, there will be very few problems that will cause me headaches (hopefully ). It needs to support the selection between the platform and the architecture, build the output result location to be more intelligent (multiple parallel builds), and easy to configure. Most of the time, my project uses C/C ++ and C # in combination #, I want to build different configuration environments (debugging, publishing, Windows, OSX, Linux, Android, iOS, etc.) from the same source code at the same time ), this usually requires selecting different compilers with different parameters for each build output result. Building a system can help me do this without worrying about it. I often try to build different systems to see some new changes. But in the end, I still went back to using makefile, combined with shell and batch processing scripts or Perl scripts (because if I want users to build my software, I 'd better select a command line scripting language that can be used everywhere ).
How do you balance the demand for native appearance and experience on a unified user interface?It is difficult to implement cross-platform user interfaces. I have used some cross-platform guis over the past few years, and I don't think there is an optimal solution for these things. There are basically two options. You can choose a cross-platform tool to create a UI that is not fully suitable for all supported platforms, but the code library is relatively small and the maintenance cost is relatively low. Or you can choose to develop the platform-specific UI, which looks more native and better integrated, but requires a larger code library and higher maintenance costs. This decision depends entirely on the APP type, how many features it has, how many resources you have, and how many platforms you want to run it on?
Finally, I think users accept this kind of "One UI clearance", such as the Electron framework. I have a framework-side project of Chromium + C #. One day I hope to use C # To build an Electron app, so that I can achieve the best of both worlds.
Does the dependency on building/packaging systems affect you?The usage of my dependencies is quite conservative. I 've been plagued by problems such as the crashed ABI (LCTT: Application binary Interface), conflicting symbols, and lost packages too many times. I decided on the OS version I wanted to target and selected the lowest public part to minimize the problem. This usually means there are five different Xcode and OSX framework libraries. You need to install five different Visual Studio versions on the same machine: C language, C ++, Object-C, C ++ lightweight compilers) and gcc versions, a series of virtual machines running a variety of Release versions. If I cannot determine the status of the operating system package I want to use, I sometimes connect to the database statically, and sometimes sub-modular dependencies to ensure that they are always available. Most of the time, I will avoid these tough issues unless I need them very much.
Do you use CI, code review, and related tools?It is usually used every day. This is the only way to maintain efficiency. The first thing I do in a project is to configure a cross-platform build script to automate everything as much as possible. Continuous integration is crucial when you are developing on multiple platforms. No one can build different combinations of platforms on one machine, and once your build process does not include all the platforms, you will not notice what you 've screwed up. In a shared multi-platform code library, different people have different platforms and functions, so the only way to ensure quality is to combine continuous integration and other analysis tools for cross-team code reviews. This is different from other software projects. If you do not use the relevant tools, you will face failure.
Do you rely on automated build tests, or are you inclined to build on each platform and perform local tests?For tools and libraries that do not include the UI, I usually use automated build tests. If there is a UI, I will use both methods-there is almost no reliable and scripted UI automation for existing GUI tools, therefore, I either want to create a UI automation tool for the platform I want to support, or manually perform a test. If a project uses a custom UI Library (such as an Unity3D OpenGL UI), it is quite easy to develop programmable automation tools and automate most of the work. However, there is nothing that will be tested by double-clicking just like a human.
Which cross-Editor building system do you prefer?I like to use a cross-Editor build system. I prefer to save project files on different IDES (which makes it easier to add IDE) and build the IDE on the platforms they support by using build scripts. For a developer, editors are the most important tools. Learning them takes time and effort, and they are irreplaceable. I have my favorite editors and tools that everyone can use.
During cross-platform development, what kind of editor, development environment, and IDE do you prefer?Cross-platform developers are limited to one of the few choices that can only work on most platforms. I love Visual Studio, but I cannot rely on it to complete work other than Windows platform (You may not want Windows to be your main cross-compilation platform ), so I won't use it as my main IDE. Even if possible, the core skills of cross-platform developers are as much as possible to understand and use a large number of platforms. This means you must be familiar with them-use the editors and libraries on the platform to understand the operating system, its applicable scenarios, running methods, and its limitations. To do these things, you need to be clear-headed (my shortcut is to strengthen the memory), and I must rely on cross-platform editors. So I use Emacs and Sublime.
What is your favorite cross-platform project?I have always liked Mono, and I am very comfortable with it. Most of other projects are centered around it in some way. Gluezilla is a Mozilla binding I developed many years ago. It can embed C # development applications into Web browser pages and looks very distinctive. I have developed a Winform application, which is developed on linux and runs on Windows in the GTK view embedded on a Mozilla Browser page. CppSharp Project (formerly called Cxxi, or CppInterop earlier) is a project where I started to generate C # Bindings for the C ++ library, in this way, you can call, create instances, and subclass C ++ classes in C. In this way, it can detect the platform in use and the compiler used to create the local Runtime Library, and generate the correct C # binding for it. This is so interesting.
How do you see the future trend of cross-platform development?The way we build local applications has changed. I feel that the obvious differences in various desktop operating systems are gradually becoming blurred. Therefore, it is easier to build cross-platform applications, in addition, system integration does not require full localization. Worse, it may mean that the application is easier to use and can do less in terms of operating system features. Cross-platform development of libraries, tools, and runtime environments is a kind of method that we know how to do better, but the development of cross-platform applications still requires our efforts.
From: https://linux.cn: 443/article-7743-1.html
Address: http://www.linuxprobe.com/cross-paltform-talk.html