1. About UI layout development
1. The aspect ratio of the imagined interface
During the development process, restoring the design effect given by the designer is only the most basic, but if you only restore the effect of the device in your hand to the effect of the design 1:1, I think it will not meet the passing line. Don't imagine the user's real device as the design drawing given by the UI designer. This is good for adapting to devices with more resolutions.
The design drawing shows 16:9, but there may be 18:9 or even 1:1 square devices in the real scene. When developing, it is necessary to consider how the same control is placed on devices with different aspect ratios. For example: When the screen becomes wider, it is necessary to consider whether the width of the control becomes larger or the horizontal space between the controls becomes larger. If the width of the control becomes larger, does its height change? etc.
To sum it up: the effect given by the designer is only one of many device effects, and the result we want to develop is _dynamic_ and can change with each device.
2. Fixed value, sometimes it is poison~
I seldom use the width or height in units of dp directly in the development process. Although dp will also do certain calculations and adaptations according to different pixel densities, there are other better implementation methods than the width or height in units of dp, such as percentages, aspect ratio constraints, filling remainder, etc.
wrap_contentI use even less... After all, I don't know how big it is~
3. Picture or drawable?
For some simple effects, both pictures and drawables can be used, so how to choose?
The advantages of using pictures are: the highest development efficiency and the best restoration. The disadvantages are: increase the installation package control, if you use the network map, the loading speed will be slow, the storage cost of the server will be increased, and so on.
The advantages of using drawable are: the layout is more adaptable, and the space of the installation package is saved. The disadvantage is: the restoration effect may not be good, and the development is difficult.
As the saying goes, you can't have both fish and bear's paw ~ analyze the specific situation in detail.
2. About the request interface
1. All interfaces are processed uniformly
Unified processing is convenient for unified modification and unified status judgment, which is the most basic aspect of the interface. This is also convenient for calling and debugging, or viewing request and return data.
Under normal circumstances, the encryption and decryption of the interface, and data verification are also carried out in a unified process. Some interfaces may have some default fields, which can also be added in unified processing.
2. Field names in the interface
Field names with the same meaning should be unified. Of course, if you develop as a mobile terminal, if you don’t have any say in the field name of the interface, just pretend I didn’t say it.
3. Don't fully trust that the interface is 100% available
The client issues traditional Chinese medicine for fault tolerance. For example, how to deal with interface errors? How to deal with missing fields? What should I do if the return value of the field is invalid?
My habit is that the return value type of all fields is String by default. To reduce the occurrence of accidents such as type mismatches. Key fields have default values to avoid accidents when missing fields.
4. Sometimes numbers make more sense
In some enumerated fields that represent switches and presence or absence, I am used to using numerical values to represent meaning. For example: "1" means on and "0" means off. If you use strings, there may be typos and capitalization errors.
3. About APP Architecture
1. Significance of APP architecture
Android has developed for so many years, and many development architectures have emerged, such as: MVC, MVP, MVVM...
What is the significance of the emergence of so many types of architectures?
Improve development efficiency, constrain team development rules, and facilitate code reading.
But I think it's all bullshit~~~
2. Something more meaningful than APP architecture
Choose a variable or method name that is easier to understand, which is more convenient for code reading.
Add a note or two, and your future self will thank your present self.
Leave a footprint with every commit and talk about what you did. Of course, before pressing the submit button, confirm all the submitted content again, and don’t submit the code you tested yourself.
If you use a third-party SDK, remember to leave a note stating where you found the SDK, whether it is a GitHub address or a blog address, so that you can find it when something goes wrong, and it is also convenient for subsequent SDK version update iterations.
at last
If you want to become an architect or want to break through the 20-30K salary range, then don't be limited to coding and business, but you must be able to select models, expand, and improve programming thinking. In addition, a good career plan is also very important, and the habit of learning is very important, but the most important thing is to be able to persevere. Any plan that cannot be implemented consistently is empty talk.
If you have no direction, here is a set of "Advanced Notes on Eight Android Modules" written by a senior architect of Ali, to help you organize the messy, scattered and fragmented knowledge systematically, so that you can systematically and efficiently master various knowledge points of Android development.
Compared with the fragmented content we usually read, the knowledge points of this note are more systematic, easier to understand and remember, and are arranged strictly according to the knowledge system.
Welcome everyone to support with one click and three links. If you need the information in the article, you can directly scan the CSDN official certification WeChat card at the end of the article to get it for free↓↓↓
PS: There is also a ChatGPT robot in the group, which can answer your work or technical questions
