Android Development Trivia for Beginners
Due to the rapid development of mobile technologies, IT companies are increasingly demanding mobile application developers for their products. Our company is no exception. I had at my disposal two Padawans who had to be taught the tricks of developing on Android (by the way, the guys were smart and capable, but with little or no experience). It was decided to write them a small memo on the main aspects of the development. I spread it to the court of habrakopolzovateley.
Descriptions of their reasoning lay out under spoilers.
First, do not use the visual designer. Never. The exception is quite a novice developer who does not know the basics of Android xml markup, and then, provided that he then manually goes through the markup and cleans up all the garbage.
Secondly, do not use RelativeLayout anywhere. If you want to put the View in order, then LinearLayout is at your service. If all your views are strictly positioned, you can always resort to FrameLayout.
Thirdly. Margin or padding? If you want to make a convenient clickable element, then padding and only it! If you need an indent that the inactive element will have, then you can use a margin.
Fourth. Don't forget, xml is no less code than the part you write in Java. Therefore, make sure that the duplication of the xml markup is minimized; if possible, create your own controls, if they are used in several places (and even if not in several, then it is also better to create them separately).
There will be only one point, regarding the most common database on Android - SQLite. She is slow. Highly. Do not neglect its optimization and asynchronous work with it.
It's no secret that a good application is a tested application. Therefore, one should not neglect such things as complex and modular testing, code review by another developer. There is nothing to be ashamed of, a good programmer is not one who does not make mistakes, but one who finds them and takes them into account in the future.
Speaking of tips, I can say that it is better to use interfaces for everything that works not only with the internal device of your application (for example, adapters for working with the network, for working with another application, or database). Then, when testing yourself, thank you.
Never use hard-coded strings. Use resources (R.string.your_string). Even if you don’t and will never have support for multiple languages.
Pay attention to how large the number of different resource groupings exists: by language, by screen resolution, orientation and size, by country, etc. Quite a large part of this may never be necessary, but you need to familiarize yourself with them. In the future, with problems drawing / positioning elements on different devices, this will save you a lot of time.
Descriptions of their reasoning lay out under spoilers.
Ui
First, do not use the visual designer. Never. The exception is quite a novice developer who does not know the basics of Android xml markup, and then, provided that he then manually goes through the markup and cleans up all the garbage.
Spoiler
The problem is that the visual designer is not Android, and the View displayed there is not your entire application, so when you try to set it correctly, the designer can use padding instead of centering, LinearLayout instead of FrameLayout, or in general, just nesting. Once I came across such a piece of typesetting (I’ll cut attributes for clarity), never do that:
')
And it was necessary to draw only two pictures under each other.
')
<RelativeLayout> <LinearLayout android:orientation=”vertical” > <LinearLayout android:orientation=”horizontal” > <FrameLayout> <!—- --> </FrameLayout> </LinearLayout> <LinearLayout android:orientation=”horizontal” > <FrameLayout> <!—- --> </FrameLayout> </LinearLayout> </LinearLayout> </RelativeLayout> And it was necessary to draw only two pictures under each other.
Secondly, do not use RelativeLayout anywhere. If you want to put the View in order, then LinearLayout is at your service. If all your views are strictly positioned, you can always resort to FrameLayout.
Spoiler
I meet almost everywhere, but for some reason not everyone understands that different types of View are loaded at different times. RelativeLayout is the hardest and longest, FrameLayout is one of the lightest (of the elements that can contain child View). And if for the root element of the Activity it does not affect in any way, then for the lists it will be a noticeable slowdown.
PS This is not a call to abandon RelativeLayout, in some cases, without it, really nothing. But only in some. Not all!
PS This is not a call to abandon RelativeLayout, in some cases, without it, really nothing. But only in some. Not all!
Thirdly. Margin or padding? If you want to make a convenient clickable element, then padding and only it! If you need an indent that the inactive element will have, then you can use a margin.
Spoiler
The truth is simple. The larger the item, the more convenient it is to press. Margin - eats space from the element itself, padding - from the environment. Not for nothing, there are even indentations in the images, with strictly specified and documented for all permissions. Please adhere to these rules, they will greatly facilitate the life of you and your users.
Fourth. Don't forget, xml is no less code than the part you write in Java. Therefore, make sure that the duplication of the xml markup is minimized; if possible, create your own controls, if they are used in several places (and even if not in several, then it is also better to create them separately).
Spoiler
This advice is more for the benefit of the developer and not for the user, because sooner or later you will still have to change the behavior or presentation of the various controls of your application. It will be easier for you if they are all in the same place and neatly sorted.
Database
There will be only one point, regarding the most common database on Android - SQLite. She is slow. Highly. Do not neglect its optimization and asynchronous work with it.
Spoiler
This fact is not noticeable on projects with a small or static data set, but if an application requires constant synchronization of large amounts of data (for example, an offline client for a large warehouse), simultaneous updating and operation of the application may be difficult or even impossible. This is due to one simple feature of SQLite: it either reads from the database, or writes, not at once (we disregard such a thing as dirty reading, because it is better for the beginner not to resort to it except for extremely necessary cases).
Testing
It's no secret that a good application is a tested application. Therefore, one should not neglect such things as complex and modular testing, code review by another developer. There is nothing to be ashamed of, a good programmer is not one who does not make mistakes, but one who finds them and takes them into account in the future.
Speaking of tips, I can say that it is better to use interfaces for everything that works not only with the internal device of your application (for example, adapters for working with the network, for working with another application, or database). Then, when testing yourself, thank you.
Spoiler
The whole point is that with unit testing it is much easier to write a test, if you are guaranteed to know that you will receive a specific request. In the case of working with external sources (even if they are 100% available), you can always spoil their data set with the previous test. In the case of working with the interface, you can simply create a stub class in the test that will return what you need.
Localization and resources
Never use hard-coded strings. Use resources (R.string.your_string). Even if you don’t and will never have support for multiple languages.
Spoiler
First, when your lines are uploaded to a separate file - it is much easier to work with them - both for you and the person who will check them for literacy (yes, there is such a bug for programmers that after writing thousands of lines of code, the native language begins to be forgotten, and it’s impossible to forget about banal misprints).
Secondly, even if you think that there will never be support for multiple languages ​​of the application, you are mistaken. If the project is at least worth something, then it makes sense to translate it at least into English. In this case, it is extremely difficult to pull out the string codes in this case.
Secondly, even if you think that there will never be support for multiple languages ​​of the application, you are mistaken. If the project is at least worth something, then it makes sense to translate it at least into English. In this case, it is extremely difficult to pull out the string codes in this case.
Pay attention to how large the number of different resource groupings exists: by language, by screen resolution, orientation and size, by country, etc. Quite a large part of this may never be necessary, but you need to familiarize yourself with them. In the future, with problems drawing / positioning elements on different devices, this will save you a lot of time.
Source: https://habr.com/ru/post/249471/
All Articles