About mobile library and love for React Native
In April, a conference for mobile application developers Mobius took place. The unified frontal system program was represented by the leaders of the mobile development team Dmitry Evstratov and Daniil Kalintsev ( EFS platform development department of SberTech SA ) with a story about scalable VIP architectural design for components using React Native.
For those who are interested in the mobile development of the ESF program, who did not attend or did not have time to talk with the guys at the conference, we prepared a short interview. In the comments to it, you can ask the speakers directly a question.
- Tell us about mobile development in the Program, what are you working on?
- Note that mobile development in the Program appeared relatively recently, about a year. We mainly develop applications for the internal client, i.e. bank employees. At the moment, our team supports one mobile application developed entirely on native technologies, but in the near future we plan to completely move from creating native applications from scratch to rapid application development on the EFS Mobile Platform using React Native technology. React Native allows us to solve the problem by ensuring omnichannel output of bank products in mobile and desktop clients, since application code now uses the same technology stack - TypeScript (we are for typed JavaScript), React and Redux. Mobile platform is a combination of a set of back-end services and front-end component libraries for building mobile interfaces and convenient communication with the back-end services of the Mobile Platform. On the Mobile platform, a number of mobile user services and about a dozen large-functional blocks are being developed, which can be reused for other functionalities.
')
- Interesting, tell me more about the mobile library.
- The EFS Mobile Library includes two major areas: visual components (buttons, switches, stylized tables, drop-down menus, etc.) and non-visual services (logging, authentication, remote configuration, networking, etc.)
The tasks of our team include the entire product life cycle: design, development, testing, support, and strategic development planning to support a dynamically changing business.
We try to approach the development of the library with the utmost rigor and scrupulousness. We try to bring components and services to perfection. In the development process, of course, we have difficulties and problems indicating the imperfection of the chosen architecture. But we do not despair and iteratively improve it.
The library gave us the opportunity to closely get acquainted with the world of JavaScript and TypeScript in particular. We discover new approaches, architectural patterns (such as Flux) and we like it, because it expands our horizons and gives us ideas for new, unique solutions.
It is worth noting that at the moment we plan to use the mobile library only for internal projects. The next two tasks, in addition to developing and extending the capabilities of components, are developing mobile workstations for employees (MRM), dynamically updating their content using JS on-the-fly interpretation capabilities, and moving to a library-compatible version of the desktop that allows developing cross-platform front-end scripts. These tasks help us solve React Native.
- How long can it take to develop a library component?
- On components leaves from a week to a month. Simple can be done in a week, not counting the time for testing. For complex components, it will take about a month of active development to ensure the stability of the component and its full test coverage.
Inside, we do not stop discussing the stability of the technology: now React Native itself is 0.46, and the final version 1.0 will not be soon, we note that the release of new versions has slowed down significantly.
On the other hand, in each new version there are fewer fixes. Now the version has been released once a month and for release notes it can be concluded that the number of corrections has not increased in comparison with 2-week release iterations. We are inclined to think that Facebook will not give up on React Native technology - too much energy has been spent on it and many Facebook products are spinning on it.
Although there are risks, but we are not very worried because we use the smallest part of React Native, for us it is a low-level engine that is a bridge between JS and Objective-C, as well as a builder of the application interface on the DOM tree generated by React JS. 80% of the functionality of our components does not come into contact with the features of React Native, so if Facebook suddenly refuses it, we can write a similar thing ourselves. People already have experience and understanding of technology.
- In mobile development, you appreciate the “availability of low-level software capabilities,” and how does this combine with working with React Native? From the outside, it seems that it must inevitably be less low-level than traditional mobile development.
- Probably, this combination is how we use it. We write all low-level things in Objective-C, in the mobile application development language. We use all the native features of the iOS platform, nothing prevents us from using anything, for example, any additional frameworks that are used only in the IOS community. React Native does not limit us at all and allows us to use our mobile development experience in full force. We are experimenting and trying new technologies in the process of creating a library.
What is interesting can be noted in the technological stack in general: the use of frameworks Kiwi, Realm and Typhoon, Generamba to create templates for our modules. React Native with Typhoon is a one-of-a-kind thing. In general, a lot of things that we do in the ESF Program are unique, there are no analogues on the market due to the specifics of the tasks and the scale.
We are often asked when to use React Native and why. Specifically, in our case, React Native is needed in order to unify the development stack of application developers, to create opportunities for cross-platform solutions, as well as dynamic mobile workplaces. React Native allows people with no experience in Objective-C, Swift, Java, Kotlin to create mobile applications on the same technological stack as web applications.
- Some developers have a prejudice not against JavaScript in general, but against its going beyond the frontend (like Node.js) - especially. React Native is also such a way out of the frontend?
- You can say that and so. React Native allows you to work with databases, and with the internal mechanisms of the device itself, for example, geolocation. It allows you to use the capabilities of the mobile device to the maximum.
- Most new developers are now learning Swift right away. What do you think of Swift? And what is better to learn Objective-C or Swift?
- It is impossible to know both languages ​​perfectly, but for new developers, you need to know at least a little Objective-C and well Swift: Objective-C is still needed to some extent by developers, some chips are better understood on it. And so Swift is a very pleasant language, which is now stabilizing. He had difficulties when they released new versions. Everyone had a headache associated with the transition to the new version, because very often the syntax changed. But now he has only become better. There are already many libraries and articles on Swift. Objective-C over the past year has become much to the background.
- What results have been achieved?
- Completed the first stage of development with React Native, while there is no mass launch of mobile applications using our library. Now we have the next round, when we know many of the chips that JavaScript and React Native provides. Now we rely on our experience and go further: there is a dynamic loading of parts of the application, a team of applied developers will not make separate applications, but the business processes themselves.
There is no full-fledged feedback to our library, only from one development team, they like everything, they quickly make their applications using the library. When you make a mobile application on a native code, the most painful thing is that when you have to make a complex UI, it always takes a lot of time. They do not do this and simply design the process. They get this prototyping, but more advanced. In general, they are satisfied, and if they are satisfied, then we are happy, and when the increase in speed really goes and there is a real tangible benefit, there will be a real breakthrough.
There are 11 people in the mobile development team of the ESF Program - 9 developers, product owner and scrum master. There are only two girls in the team, one of which is a developer. They are very smart!
There is a prospect, a lot of work. It does not give us time to be bored and pushes us to continuous improvement!
In the near future, we are planning to hold a meeting on mobile development topics.
Please share what topics you were interested in hearing and discussing at a meeting. The options below may seem general, please specify your suggestions in the comments.
For those who are interested in the mobile development of the ESF program, who did not attend or did not have time to talk with the guys at the conference, we prepared a short interview. In the comments to it, you can ask the speakers directly a question.
- Tell us about mobile development in the Program, what are you working on?
- Note that mobile development in the Program appeared relatively recently, about a year. We mainly develop applications for the internal client, i.e. bank employees. At the moment, our team supports one mobile application developed entirely on native technologies, but in the near future we plan to completely move from creating native applications from scratch to rapid application development on the EFS Mobile Platform using React Native technology. React Native allows us to solve the problem by ensuring omnichannel output of bank products in mobile and desktop clients, since application code now uses the same technology stack - TypeScript (we are for typed JavaScript), React and Redux. Mobile platform is a combination of a set of back-end services and front-end component libraries for building mobile interfaces and convenient communication with the back-end services of the Mobile Platform. On the Mobile platform, a number of mobile user services and about a dozen large-functional blocks are being developed, which can be reused for other functionalities.
')
- Interesting, tell me more about the mobile library.
- The EFS Mobile Library includes two major areas: visual components (buttons, switches, stylized tables, drop-down menus, etc.) and non-visual services (logging, authentication, remote configuration, networking, etc.)
The tasks of our team include the entire product life cycle: design, development, testing, support, and strategic development planning to support a dynamically changing business.
We try to approach the development of the library with the utmost rigor and scrupulousness. We try to bring components and services to perfection. In the development process, of course, we have difficulties and problems indicating the imperfection of the chosen architecture. But we do not despair and iteratively improve it.
The library gave us the opportunity to closely get acquainted with the world of JavaScript and TypeScript in particular. We discover new approaches, architectural patterns (such as Flux) and we like it, because it expands our horizons and gives us ideas for new, unique solutions.
It is worth noting that at the moment we plan to use the mobile library only for internal projects. The next two tasks, in addition to developing and extending the capabilities of components, are developing mobile workstations for employees (MRM), dynamically updating their content using JS on-the-fly interpretation capabilities, and moving to a library-compatible version of the desktop that allows developing cross-platform front-end scripts. These tasks help us solve React Native.
- How long can it take to develop a library component?
- On components leaves from a week to a month. Simple can be done in a week, not counting the time for testing. For complex components, it will take about a month of active development to ensure the stability of the component and its full test coverage.
Inside, we do not stop discussing the stability of the technology: now React Native itself is 0.46, and the final version 1.0 will not be soon, we note that the release of new versions has slowed down significantly.
On the other hand, in each new version there are fewer fixes. Now the version has been released once a month and for release notes it can be concluded that the number of corrections has not increased in comparison with 2-week release iterations. We are inclined to think that Facebook will not give up on React Native technology - too much energy has been spent on it and many Facebook products are spinning on it.
Although there are risks, but we are not very worried because we use the smallest part of React Native, for us it is a low-level engine that is a bridge between JS and Objective-C, as well as a builder of the application interface on the DOM tree generated by React JS. 80% of the functionality of our components does not come into contact with the features of React Native, so if Facebook suddenly refuses it, we can write a similar thing ourselves. People already have experience and understanding of technology.
- In mobile development, you appreciate the “availability of low-level software capabilities,” and how does this combine with working with React Native? From the outside, it seems that it must inevitably be less low-level than traditional mobile development.
- Probably, this combination is how we use it. We write all low-level things in Objective-C, in the mobile application development language. We use all the native features of the iOS platform, nothing prevents us from using anything, for example, any additional frameworks that are used only in the IOS community. React Native does not limit us at all and allows us to use our mobile development experience in full force. We are experimenting and trying new technologies in the process of creating a library.
What is interesting can be noted in the technological stack in general: the use of frameworks Kiwi, Realm and Typhoon, Generamba to create templates for our modules. React Native with Typhoon is a one-of-a-kind thing. In general, a lot of things that we do in the ESF Program are unique, there are no analogues on the market due to the specifics of the tasks and the scale.
We are often asked when to use React Native and why. Specifically, in our case, React Native is needed in order to unify the development stack of application developers, to create opportunities for cross-platform solutions, as well as dynamic mobile workplaces. React Native allows people with no experience in Objective-C, Swift, Java, Kotlin to create mobile applications on the same technological stack as web applications.
- Some developers have a prejudice not against JavaScript in general, but against its going beyond the frontend (like Node.js) - especially. React Native is also such a way out of the frontend?
- You can say that and so. React Native allows you to work with databases, and with the internal mechanisms of the device itself, for example, geolocation. It allows you to use the capabilities of the mobile device to the maximum.
- Most new developers are now learning Swift right away. What do you think of Swift? And what is better to learn Objective-C or Swift?
- It is impossible to know both languages ​​perfectly, but for new developers, you need to know at least a little Objective-C and well Swift: Objective-C is still needed to some extent by developers, some chips are better understood on it. And so Swift is a very pleasant language, which is now stabilizing. He had difficulties when they released new versions. Everyone had a headache associated with the transition to the new version, because very often the syntax changed. But now he has only become better. There are already many libraries and articles on Swift. Objective-C over the past year has become much to the background.
- What results have been achieved?
- Completed the first stage of development with React Native, while there is no mass launch of mobile applications using our library. Now we have the next round, when we know many of the chips that JavaScript and React Native provides. Now we rely on our experience and go further: there is a dynamic loading of parts of the application, a team of applied developers will not make separate applications, but the business processes themselves.
There is no full-fledged feedback to our library, only from one development team, they like everything, they quickly make their applications using the library. When you make a mobile application on a native code, the most painful thing is that when you have to make a complex UI, it always takes a lot of time. They do not do this and simply design the process. They get this prototyping, but more advanced. In general, they are satisfied, and if they are satisfied, then we are happy, and when the increase in speed really goes and there is a real tangible benefit, there will be a real breakthrough.
There are 11 people in the mobile development team of the ESF Program - 9 developers, product owner and scrum master. There are only two girls in the team, one of which is a developer. They are very smart!
There is a prospect, a lot of work. It does not give us time to be bored and pushes us to continuous improvement!
In the near future, we are planning to hold a meeting on mobile development topics.
Please share what topics you were interested in hearing and discussing at a meeting. The options below may seem general, please specify your suggestions in the comments.
Source: https://habr.com/ru/post/332884/
All Articles