12 hours in the skin of the Android developer through the eyes of the JS developer
It all started with Kotlin. Accidentally came across an article about a new language that you can write on it under Android. Touching the topic, I learned that initially Android applications are written in JAVA. I decided to find out how difficult it is to write applications for Android, what are the advantages of the platform in practice. After all, in fact, JS applications and Android applications perform the same function. At the same time decided to conduct an experiment. What can be done in 12 hours without knowing what JAVA and the subtleties of development for Android are, using only Google as an assistant. An idea came up that I developed in the formulation of the problem.
Take from the external service a list of all the airports in the world and, using the Airport code, obtain from the external service an online scoreboard with information on flight status. In 100% of applications that are in google play and implement such a function, you need to go through a chain of actions, look inside the application. I personally, did not find an aggregator that would allow on the first page to enter any Airport and get it online. The idea and the application itself is simple, but this is a function that is used by anyone who makes the flight. Access to such information should be instant.
I found a terrific service that opens up many possibilities in terms of development for Aviation. developer.flightstats.com I got a free account for a month.
')
He acted intuitively, relying on his development experience in JavaScript. Sketched sketches of screens in Photoshop. Made up the requirements for the application.
Next was Me, Google and Android Studio.
From experience I understand that the code needs to be organized. Intuitively determined the structure of the project. Highlighted the following groups (Models, Stores, Views, Fields, API, Adapters) At that moment I was moved by an unconscious, or rather, experience. Then I began to have fun with layouts. Android Studio is a very intuitive editor, this is one of the reasons that prompted to try to write an Android application. If kind of intellij idea - then everything is comfortable. Plus, the editor is free, no restrictions, it is developed and updated regularly. Layouts have developed at times two. Not a single glitch for the entire period of work, everything is in its place.
The moment that alerted me at the very beginning, in 90% of the sources, the search and work is carried out by the component ID. Generally accepted, working with ID is bad practice, in Android it turned out to be normal practice. Googling, one of the DataBinding drugs, a great thing, lets go of findViewById. But, the principle in the initial stage and a year ago the connection worked in one direction. Sounds weird, databinding but one way. It was necessary to write the implementation that DataBinding was full. Based on the implementation in JS, I was surprised by the concept that currently offers the Data Binding Library (can be seen in most cases on the network), the ViewModel hosts the logic for handling handlers from visual components, which in turn can have direct access to the data that lies in viewmodel. It looks like a hybrid of the controller and ViewModel.
Next came the questions of communication, something that gobbled up the first time shocked. To make an ordinary AJAX request, you had to pull 70 lines of code. Create a background process and there already create the magic of the connection, and then collect the answer through the buffer. "It can not be so difficult!" And continued the search. In one of the results came across an article about Retrofit2. With Retrofit it became more fun and in general you can live in terms of communication. I decided on the interface with the server and began to match the data with visual components.
I had to tinker with the spinner filter (aka combobox), possibly due to inexperience. Along the way, a lot of questions arose from converting one type to another, to how OOP was implemented in JAVA, but everything was elementary in a stack overflow with answers and examples, plus intuition. In general, everything went like clockwork, except for some moments. What did not expect to get a headache with the date. For some reason, JAVA (or maybe it happened to me like this) by defaul gave everything in UTC.
In general, there were no absolutely insurmountable moments due to which a complete stop occurred. What did you not understand (why did they do this as a dafault behavior ?!) When you change the screen orientation (or configuration), your View that is present on the screen is destroyed and the newly rotated screen is recreated again (large-scale work is in the background). What causes a headache if you have dynamic data in the View class (also called “Activity”), they are simply lost when you destroy the View and something needs to be done about it. Give this opportunity, but optionally, for those who want to replace the screens when turning. It is interesting to hear the opinion of the Android developer about this, perhaps I do not see the whole picture as a whole.
I was shocked by the performance of interfaces under heavy load. For the test, I made an 8 spinner, in each I scored 4,000 entries (in each entry there was still a set of properties) and the application did not even grunt. In such a situation, the JS application would be strained, and if you still needed to display all the records at once, and have access to work with them, then you are more likely to catch the screen hang or “Opanka” in general. I would have to drag the output buffering or decide somehow algorithmically. But there are tasks when you need the whole volume at once.
Multithreading and background processes on the fly. What you need to do in JS is with the help of webworkers, but they have their own difficulties, which, when developing for Android, are solved once or twice. And the background can really weighty volumes. This is a huge value for developing off-line applications with complex engineering calculations.
The application for the browser has its own ceiling in terms of performance when it comes to highly loaded interfaces (outputting a large amount of data at the same time) or when volume calculations need to be done in the background. Here, before Android applications, I take off my hat. But if you need to do something average statistical, then javascript will take its development speed.
I admit, it’s time consuming to write for Android and takes much more time than writing applications on JS, but google is intensively developing and building up the platform. A week of sitting behind books and the theory of Android development would most likely kill the idea of ​​trying to make an Android application and would not give the skills and experience gained during these 12 hours. Really face problems and see the world from the inside, get a first assessment of the capabilities of Android applications and in the future, faced with problems difficult to implement in JS, have knowledge in reserve where you can still cast your eyes. Practice is a quick way to achieve skills and experience.
What happened: Android-application for viewing the online scoreboard of any airport in the world.
With the presence of another 12 hours, there is a desire to develop the idea further.
Igor
Formulation of the problem
Take from the external service a list of all the airports in the world and, using the Airport code, obtain from the external service an online scoreboard with information on flight status. In 100% of applications that are in google play and implement such a function, you need to go through a chain of actions, look inside the application. I personally, did not find an aggregator that would allow on the first page to enter any Airport and get it online. The idea and the application itself is simple, but this is a function that is used by anyone who makes the flight. Access to such information should be instant.
I found a terrific service that opens up many possibilities in terms of development for Aviation. developer.flightstats.com I got a free account for a month.
')
He acted intuitively, relying on his development experience in JavaScript. Sketched sketches of screens in Photoshop. Made up the requirements for the application.
Search form
- The application must download a list of all airports in the world in the drop-down list component.
- Enable the filter to select the airport, switch the time UTC / LT (local time)
Result form
- Data output in the form of a table
- Sort by time Arrival / Departure
Development
Next was Me, Google and Android Studio.
From experience I understand that the code needs to be organized. Intuitively determined the structure of the project. Highlighted the following groups (Models, Stores, Views, Fields, API, Adapters) At that moment I was moved by an unconscious, or rather, experience. Then I began to have fun with layouts. Android Studio is a very intuitive editor, this is one of the reasons that prompted to try to write an Android application. If kind of intellij idea - then everything is comfortable. Plus, the editor is free, no restrictions, it is developed and updated regularly. Layouts have developed at times two. Not a single glitch for the entire period of work, everything is in its place.
The moment that alerted me at the very beginning, in 90% of the sources, the search and work is carried out by the component ID. Generally accepted, working with ID is bad practice, in Android it turned out to be normal practice. Googling, one of the DataBinding drugs, a great thing, lets go of findViewById. But, the principle in the initial stage and a year ago the connection worked in one direction. Sounds weird, databinding but one way. It was necessary to write the implementation that DataBinding was full. Based on the implementation in JS, I was surprised by the concept that currently offers the Data Binding Library (can be seen in most cases on the network), the ViewModel hosts the logic for handling handlers from visual components, which in turn can have direct access to the data that lies in viewmodel. It looks like a hybrid of the controller and ViewModel.
Next came the questions of communication, something that gobbled up the first time shocked. To make an ordinary AJAX request, you had to pull 70 lines of code. Create a background process and there already create the magic of the connection, and then collect the answer through the buffer. "It can not be so difficult!" And continued the search. In one of the results came across an article about Retrofit2. With Retrofit it became more fun and in general you can live in terms of communication. I decided on the interface with the server and began to match the data with visual components.
I had to tinker with the spinner filter (aka combobox), possibly due to inexperience. Along the way, a lot of questions arose from converting one type to another, to how OOP was implemented in JAVA, but everything was elementary in a stack overflow with answers and examples, plus intuition. In general, everything went like clockwork, except for some moments. What did not expect to get a headache with the date. For some reason, JAVA (or maybe it happened to me like this) by defaul gave everything in UTC.
In general, there were no absolutely insurmountable moments due to which a complete stop occurred. What did you not understand (why did they do this as a dafault behavior ?!) When you change the screen orientation (or configuration), your View that is present on the screen is destroyed and the newly rotated screen is recreated again (large-scale work is in the background). What causes a headache if you have dynamic data in the View class (also called “Activity”), they are simply lost when you destroy the View and something needs to be done about it. Give this opportunity, but optionally, for those who want to replace the screens when turning. It is interesting to hear the opinion of the Android developer about this, perhaps I do not see the whole picture as a whole.
Awesome
I was shocked by the performance of interfaces under heavy load. For the test, I made an 8 spinner, in each I scored 4,000 entries (in each entry there was still a set of properties) and the application did not even grunt. In such a situation, the JS application would be strained, and if you still needed to display all the records at once, and have access to work with them, then you are more likely to catch the screen hang or “Opanka” in general. I would have to drag the output buffering or decide somehow algorithmically. But there are tasks when you need the whole volume at once.
Multithreading and background processes on the fly. What you need to do in JS is with the help of webworkers, but they have their own difficulties, which, when developing for Android, are solved once or twice. And the background can really weighty volumes. This is a huge value for developing off-line applications with complex engineering calculations.
The application for the browser has its own ceiling in terms of performance when it comes to highly loaded interfaces (outputting a large amount of data at the same time) or when volume calculations need to be done in the background. Here, before Android applications, I take off my hat. But if you need to do something average statistical, then javascript will take its development speed.
Summary
I admit, it’s time consuming to write for Android and takes much more time than writing applications on JS, but google is intensively developing and building up the platform. A week of sitting behind books and the theory of Android development would most likely kill the idea of ​​trying to make an Android application and would not give the skills and experience gained during these 12 hours. Really face problems and see the world from the inside, get a first assessment of the capabilities of Android applications and in the future, faced with problems difficult to implement in JS, have knowledge in reserve where you can still cast your eyes. Practice is a quick way to achieve skills and experience.
What happened: Android-application for viewing the online scoreboard of any airport in the world.
Afterword
With the presence of another 12 hours, there is a desire to develop the idea further.
Igor
Source: https://habr.com/ru/post/330314/
All Articles