June 6, 2017 at 12:5212 hours in the shoes of an Android developer through the eyes of a JS developer
It all started with Kotlin. By chance I came across an article about a new language that you can write on it for Android. Touching the topic, I learned that initially applications for Android are written in JAVA. I decided to find out how laborious it is to write applications for Android, what are the advantages of the platform in practice. Indeed, in essence, JS applications and Android applications perform the same function. At the same time I decided to conduct an experiment. What can be done in 12 hours without knowing what JAVA and the subtleties of Android development are, using only Google as an assistant. An idea came which I developed in the statement of the problem.
Take from the external service a list of all Airports in the world and, using the Airport code, get an online scoreboard with information on flight statuses from the external service. In 100% of the applications that lie in google play and implement such a function, you need to go through a chain of actions, look inside the application. Personally, I did not find an aggregator that would allow you to enter any Airport on the first page and get its online scoreboard. The idea and the application itself is simple, but it is a function that anyone who makes a flight uses. Access to such information should be instant.
I found an amazing service that opens up many opportunities in terms of development for Aviation. developer.flightstats.com Registered I got a free account for a month.
He acted intuitively, relying on his JavaScript development experience. Sketched screen sketches in Photoshop. Compiled application requirements.
Next was Me, Google and Android Studio.
From experience I understand that the code needs to be organized. Intuitively defined the structure of the project. I distinguished the following groups (Models, Stores, Views, Fields, API, Adapters) The unconscious, or rather, the experience, moved me at this moment. Then he began to have fun with Layouts. Android Studio is a very intuitive editor, this is one of the reasons that inspired me to try to write an Android application. If kind of intellij idea - then everything is comfortable. Plus, the editor is in free access, no restrictions, it is developed and updated regularly. Layouts took shape two times. Not a single glitch for the entire period of work, everything is in 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. It’s generally accepted that working with IDs is bad practice; Android has proven to be a normal practice. Google, one of the drugs DataBinding, a great thing, allows you to get away from 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 your implementation so that DataBinding was complete. Based on the implementation in JS, I was surprised by the concept that the Data Binding Library currently offers (you can see it in most cases on the network), the ViewModel contains the logic for processing handlers from visual components, which in turn can have direct access to the data that lies in ViewModel. It looks like some kind of hybrid controller and ViewModel.
Next came the questions of communication, what was googled the first time plunged into shock. To make a normal AJAX request, you had to pull lines of code 70. Create a background process and do the connection magic there, and then collect the response through the buffer. “It can't be that hard!” and continued the search. An article about Retrofit2 came across in one of the results. Retrofit has become more fun and in general you can live in terms of communications. I decided on the interfaces for interacting with the server and began to pair data with visual components.
I had to tinker with the spinner filter (aka combobox), possibly due to inexperience. Along the way, a bunch of questions arose from converting one type to another to how OOP is implemented in JAVA, but everything was elementary in stack overflow with answers and examples, plus intuition. In general, everything went like clockwork, except for some points. What I did not expect to get a headache with a date. For some reason, JAVA (or maybe it happened to me like that) defaul showed everything in UTC.
In general, there weren’t any insurmountable moments that caused a complete stop. What I didn’t understand (why did they do it like dafault behavior ?!) When changing the screen orientation (or configuration), your View that is present on the screen is destroyed and re-recreated in the new rotated screen (large-scale work is going on). What causes a headache if you have dynamic data in the View class (aka “Activity”), they are simply lost when the View is destroyed and something needs to be done. Give this opportunity, but optionally, for those who want to replace screens when turning. It is interesting to hear the opinion of the Android developer on this matter, maybe I do not see the whole picture as a whole.
Shocked interface performance under heavy load. For the test, I made 8 spinners, threw 4000 records in each (each record has a set of properties) and the application did not even quack. In such a situation, the JS application would strain, and if it were still necessary to display all the records at once, and have access to work with them, then there is a high probability of catching a screen hang or, in general, “Aw,”. I would have to drag output buffering or solve it somehow algorithmically. But there are tasks when the whole volume is needed immediately.
Multithreading and background processes on the fly. What you need to do in JS with the help of webworkers, but there are some difficulties that can be solved once or twice when developing for Android. Moreover, the background can pull really significant volumes. This is a huge value for the development of off line applications with complex engineering calculations.
The application for the browser has its own performance ceiling, when it comes to highly loaded interfaces (output of a large amount of data at the same time) or when the background needs to do volumetric calculations. Here I take off my hat to Android applications. But if you need to do something average statistical, then javascript will take its speed of development.
I admit, it’s time-consuming to write for Android and requires several times more time than writing applications in JS, but google is intensively developing and expanding the platform. A week of sitting behind books and the theory of Android development would probably kill the idea of trying to make an Android application and would not give the skills and experience gained in these 12 hours. Really encounter problems and see the world from the inside out, get the first assessment of the capabilities of Android applications and in the future, faced with tasks that are difficult to implement in JS, have in stock knowledge where you can still take a look. Practice is a quick way to achieve skills and experience.
What happened: An Android application for viewing the online scoreboard of any airport in the world.
If you have 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 Airports in the world and, using the Airport code, get an online scoreboard with information on flight statuses from the external service. In 100% of the applications that lie in google play and implement such a function, you need to go through a chain of actions, look inside the application. Personally, I did not find an aggregator that would allow you to enter any Airport on the first page and get its online scoreboard. The idea and the application itself is simple, but it is a function that anyone who makes a flight uses. Access to such information should be instant.
I found an amazing service that opens up many opportunities in terms of development for Aviation. developer.flightstats.com Registered I got a free account for a month.
He acted intuitively, relying on his JavaScript development experience. Sketched screen sketches in Photoshop. Compiled application requirements.
Search Form
- The application should load the list of all airports in the world into a component of the "Drop-down list" type.
- Allow using the filter to select the airport, switch the UTC / LT time (local time)
Result Form
- Table output
- 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 defined the structure of the project. I distinguished the following groups (Models, Stores, Views, Fields, API, Adapters) The unconscious, or rather, the experience, moved me at this moment. Then he began to have fun with Layouts. Android Studio is a very intuitive editor, this is one of the reasons that inspired me to try to write an Android application. If kind of intellij idea - then everything is comfortable. Plus, the editor is in free access, no restrictions, it is developed and updated regularly. Layouts took shape two times. Not a single glitch for the entire period of work, everything is in 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. It’s generally accepted that working with IDs is bad practice; Android has proven to be a normal practice. Google, one of the drugs DataBinding, a great thing, allows you to get away from 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 your implementation so that DataBinding was complete. Based on the implementation in JS, I was surprised by the concept that the Data Binding Library currently offers (you can see it in most cases on the network), the ViewModel contains the logic for processing handlers from visual components, which in turn can have direct access to the data that lies in ViewModel. It looks like some kind of hybrid controller and ViewModel.
Next came the questions of communication, what was googled the first time plunged into shock. To make a normal AJAX request, you had to pull lines of code 70. Create a background process and do the connection magic there, and then collect the response through the buffer. “It can't be that hard!” and continued the search. An article about Retrofit2 came across in one of the results. Retrofit has become more fun and in general you can live in terms of communications. I decided on the interfaces for interacting with the server and began to pair data with visual components.
I had to tinker with the spinner filter (aka combobox), possibly due to inexperience. Along the way, a bunch of questions arose from converting one type to another to how OOP is implemented in JAVA, but everything was elementary in stack overflow with answers and examples, plus intuition. In general, everything went like clockwork, except for some points. What I did not expect to get a headache with a date. For some reason, JAVA (or maybe it happened to me like that) defaul showed everything in UTC.
In general, there weren’t any insurmountable moments that caused a complete stop. What I didn’t understand (why did they do it like dafault behavior ?!) When changing the screen orientation (or configuration), your View that is present on the screen is destroyed and re-recreated in the new rotated screen (large-scale work is going on). What causes a headache if you have dynamic data in the View class (aka “Activity”), they are simply lost when the View is destroyed and something needs to be done. Give this opportunity, but optionally, for those who want to replace screens when turning. It is interesting to hear the opinion of the Android developer on this matter, maybe I do not see the whole picture as a whole.
Awesome
Shocked interface performance under heavy load. For the test, I made 8 spinners, threw 4000 records in each (each record has a set of properties) and the application did not even quack. In such a situation, the JS application would strain, and if it were still necessary to display all the records at once, and have access to work with them, then there is a high probability of catching a screen hang or, in general, “Aw,”. I would have to drag output buffering or solve it somehow algorithmically. But there are tasks when the whole volume is needed immediately.
Multithreading and background processes on the fly. What you need to do in JS with the help of webworkers, but there are some difficulties that can be solved once or twice when developing for Android. Moreover, the background can pull really significant volumes. This is a huge value for the development of off line applications with complex engineering calculations.
The application for the browser has its own performance ceiling, when it comes to highly loaded interfaces (output of a large amount of data at the same time) or when the background needs to do volumetric calculations. Here I take off my hat to Android applications. But if you need to do something average statistical, then javascript will take its speed of development.
Summary
I admit, it’s time-consuming to write for Android and requires several times more time than writing applications in JS, but google is intensively developing and expanding the platform. A week of sitting behind books and the theory of Android development would probably kill the idea of trying to make an Android application and would not give the skills and experience gained in these 12 hours. Really encounter problems and see the world from the inside out, get the first assessment of the capabilities of Android applications and in the future, faced with tasks that are difficult to implement in JS, have in stock knowledge where you can still take a look. Practice is a quick way to achieve skills and experience.
What happened: An Android application for viewing the online scoreboard of any airport in the world.
Afterword
If you have another 12 hours, there is a desire to develop the idea further.
Igor