Who needs this HTML: “How I wrote down a payment service in 2 months - and sent it to a landfill”
The choice between stand and wheeling - HTML5 and the native programming environment - is sooner or later confronted by any mobile developer who needs to be present on different platforms. He did not bypass us in UBANK either.
In 2011, we started with the html-version, which worked on Android. We were preparing to port it to other platforms, despite the difficulties that had to be faced. But in the end, after two years, this project was turned off and the project was replaced with native applications.
')
In this post , UBANK Lead Developer Alexander Putilin will try to talk about our experience in creating a cross-platform application, as well as share some ideas about why HTML5 is still needed and how you can beat it. Those interested in practical matters are invited to comment.
Alexander Putilin:
- In HTML, of course, we were attracted to multiplatform. UBANK was faced with the task of being present on all popular devices. It seemed that creating a web application once and then porting it to all platforms would be much easier than writing a native one for each.
Development began in 2011. We decided to start with the Bada platform. Samsung for our startup was a strategic partner. And this was his native platform, on it the Koreans released about 200 phone models. In 2010-2011, it occupied about 10% of the Russian mobile market and seemed promising.
I started writing an application using the PhoneGap framework. The task was managed in a couple of months. By the end of 2011, our version of the application reached the level of a fairly stable beta.
But then a little trouble happened: Samsung, unexpectedly for everyone, decided to roll the Bada. Koreans began to develop the Tizen operating system, planning to merge it with Bada in the future. To release our application to Bada was no longer meaningful, even though it was ready.
We, however, were not very upset. After all, the non-native version allowed us to easily port the application to any device, right? That's fine. We started to port our development to Android, without releasing UBANK to Bada.
But it turned out to be more complicated than we thought.
The first problem was encryption. Initially, the framework is designed simply for creating applications - forms, texts, data output, in general, nothing complicated. And for our payment application, encryption was required. In this case, the math in java-script is frankly weak - by orders of magnitude slower than in the native code.
To implement encryption and not to force the user to wait for the operation to complete a couple of minutes, we had to write pieces of native code that would interact with the html interface. Thus, the native code in the application was about 10%. And it would probably be nice if the rest of the code worked as it should. But no.
Android, as we know, has too many modifications that are very different from each other. New features are added to iOs in new versions, but usually the old ones do not fall off. On Android, something that works fine on 2.2 does not work on 4 for some reason.
A lot of problems and delivered the keyboard. In the browser on Android, she behaved as she wanted: she could close at the entrance to the field, could stay in the old field when switching to a new field. C had to fight - and again with native code.
With the solution of such minor problems, I had to pretty much tinker. Moreover, in native development, at least there is documentation, and here it was necessary to get to the whole experimentally, that is, using the method of scientific poking. The experiments, however, ended fairly well: the first version of UBANK was an HTML-based application ported to Android. However, the glorious history of this project is over.
Of course, UBANK as a mobile payment service had the task of being present on all major smartphones. Therefore, in parallel, we wrote down versions for iOS and Windows Phone.
Here we repeated the path already made. In each case, about 10% of the code had to be rewritten to provide native encryption. And also to deal with various flaws that appeared during porting.
This beautiful work never saw the light of day. When our marketers watched it, they immediately hacked her off without any extra sentiment. And, in general, they did quite right.
As you know, iOS is a highly unified environment. IPhones users have become accustomed to standard design elements. And reworking the appearance of our web application so that it looked adequate on iOS, turned out to be almost impossible. Although we tried. But still it was clear that something was wrong. About Windows Phone with its tiled interface and say nothing.
We also attempted to release an application for Symbian - Nokia was then relevant. But it turned out that Simbian did not allow encryption in the native code. We simply could not provide it with the proper degree of security.
As a result, we in UBANK came to the inevitable solution: serious cross-platform development in HTML for mobile platforms is a complete utopia. Porting is not as painless and easy as we would like if your application has really serious tasks. And the design features of each platform do not allow the product to look at five on all devices, having the same interface appearance.
Now all our services, which we rolled out six months ago, are completely native applications. Does this mean that HTML5 should be sent to the dustbin of history?
I do not think. It seems to me that each tool has its advantages - you just need to use it correctly. Based on my experience, I would say that HTML is great for prototyping. It gives you the opportunity to see how everything will work with lightning speed.
For a quick start, HTML is a good tool. But to lay it as the main technology of the company is not worth it, because the ported application will always be worse than the native - and work and look.
If you are developing a mobile application in HTML right now and are faced with a problem, write in the comments. Perhaps I can help you, since I’m already looking for a way to solve the same problem. I couldn’t find any clues on the Internet at the time — I’ve got it all myself. And now I will be glad to share them.
In 2011, we started with the html-version, which worked on Android. We were preparing to port it to other platforms, despite the difficulties that had to be faced. But in the end, after two years, this project was turned off and the project was replaced with native applications.
')
In this post , UBANK Lead Developer Alexander Putilin will try to talk about our experience in creating a cross-platform application, as well as share some ideas about why HTML5 is still needed and how you can beat it. Those interested in practical matters are invited to comment.
Beta on Bada
Alexander Putilin:
- In HTML, of course, we were attracted to multiplatform. UBANK was faced with the task of being present on all popular devices. It seemed that creating a web application once and then porting it to all platforms would be much easier than writing a native one for each.
Development began in 2011. We decided to start with the Bada platform. Samsung for our startup was a strategic partner. And this was his native platform, on it the Koreans released about 200 phone models. In 2010-2011, it occupied about 10% of the Russian mobile market and seemed promising.
I started writing an application using the PhoneGap framework. The task was managed in a couple of months. By the end of 2011, our version of the application reached the level of a fairly stable beta.
But then a little trouble happened: Samsung, unexpectedly for everyone, decided to roll the Bada. Koreans began to develop the Tizen operating system, planning to merge it with Bada in the future. To release our application to Bada was no longer meaningful, even though it was ready.
We, however, were not very upset. After all, the non-native version allowed us to easily port the application to any device, right? That's fine. We started to port our development to Android, without releasing UBANK to Bada.
But it turned out to be more complicated than we thought.
Wrestling with Android
The first problem was encryption. Initially, the framework is designed simply for creating applications - forms, texts, data output, in general, nothing complicated. And for our payment application, encryption was required. In this case, the math in java-script is frankly weak - by orders of magnitude slower than in the native code.
To implement encryption and not to force the user to wait for the operation to complete a couple of minutes, we had to write pieces of native code that would interact with the html interface. Thus, the native code in the application was about 10%. And it would probably be nice if the rest of the code worked as it should. But no.
Android, as we know, has too many modifications that are very different from each other. New features are added to iOs in new versions, but usually the old ones do not fall off. On Android, something that works fine on 2.2 does not work on 4 for some reason.
Animation from Android 2.2, in the four was in gray stripes. And the one we did under the four, on the second stupidly braked. But still there would be a third Android, and neither one nor the other would work on it.
A lot of problems and delivered the keyboard. In the browser on Android, she behaved as she wanted: she could close at the entrance to the field, could stay in the old field when switching to a new field. C had to fight - and again with native code.
With the solution of such minor problems, I had to pretty much tinker. Moreover, in native development, at least there is documentation, and here it was necessary to get to the whole experimentally, that is, using the method of scientific poking. The experiments, however, ended fairly well: the first version of UBANK was an HTML-based application ported to Android. However, the glorious history of this project is over.
Work at the table
Of course, UBANK as a mobile payment service had the task of being present on all major smartphones. Therefore, in parallel, we wrote down versions for iOS and Windows Phone.
Here we repeated the path already made. In each case, about 10% of the code had to be rewritten to provide native encryption. And also to deal with various flaws that appeared during porting.
This beautiful work never saw the light of day. When our marketers watched it, they immediately hacked her off without any extra sentiment. And, in general, they did quite right.
As you know, iOS is a highly unified environment. IPhones users have become accustomed to standard design elements. And reworking the appearance of our web application so that it looked adequate on iOS, turned out to be almost impossible. Although we tried. But still it was clear that something was wrong. About Windows Phone with its tiled interface and say nothing.
We also attempted to release an application for Symbian - Nokia was then relevant. But it turned out that Simbian did not allow encryption in the native code. We simply could not provide it with the proper degree of security.
As a result, we in UBANK came to the inevitable solution: serious cross-platform development in HTML for mobile platforms is a complete utopia. Porting is not as painless and easy as we would like if your application has really serious tasks. And the design features of each platform do not allow the product to look at five on all devices, having the same interface appearance.
No man is an island
Now all our services, which we rolled out six months ago, are completely native applications. Does this mean that HTML5 should be sent to the dustbin of history?
I do not think. It seems to me that each tool has its advantages - you just need to use it correctly. Based on my experience, I would say that HTML is great for prototyping. It gives you the opportunity to see how everything will work with lightning speed.
Compare: first, a fully functional HTML version, I did it alone in two months. Development of native applications for iOS, Android and Windows Phone took about a year of work of a whole team of programmers, the number of which during this time at different stages varied from two to seven people.
For a quick start, HTML is a good tool. But to lay it as the main technology of the company is not worth it, because the ported application will always be worse than the native - and work and look.
If you are developing a mobile application in HTML right now and are faced with a problem, write in the comments. Perhaps I can help you, since I’m already looking for a way to solve the same problem. I couldn’t find any clues on the Internet at the time — I’ve got it all myself. And now I will be glad to share them.
Source: https://habr.com/ru/post/230161/
All Articles