Precautions during Android development and Android Development

Precautions during Android development and Android Development

1. The interface cannot be updated in the Child thread. The interface must be updated in the main thread.

2. Notes for Fragment:

A) The Activity calls the method in Fragment.

B) the Thread or Handler calls the method in Fragment.

Note that getActivity () may be empty. Add the following code to avoid null pointers.

If (getActivity () = null |! IsAdd ()){

Return;

}

3. For constants and variables of the String type, use the constant equals variable because the variable may be empty;

If (constant. equals (variable )){

...

}

4. The BroadCastReceiver setting listening and canceling listening in Activity or Fragment must appear in pairs. The external class called in the onReceive method must be empty.

5. network operations cannot be called in the main thread

6. Before the Activity is destroyed, the Dialog attached to the Activity must be destroyed first. The Dialog object cannot be operated after the Activity is destroyed.

7. When using the database, you should notice the database deadlock problem. If the database is not synchronized, you must call the database in the main thread to ensure that the database is not locked.

8. Try catch cannot use log to print error messages to avoid null pointers. Print error messages using e. printStackTrace ()

9. Open stream resources must be closed, such as file read/write and database read/write.

10. The Map or List set referenced by Static must be manually released. Do not use static reference set whenever possible.

11. When traversing a set, you cannot add or delete the set. It often appears in multiple threads.

12. A method cannot be too long. If the method is too long, it must be split into several methods.

13. If there are many judgment conditions, try to replace nested condition expressions with Wei statements, for example:

If (! File. exist ()){

Return;

}

In this way, you can avoid too deep layers. When maintaining code, you should pay more attention to the main logic and ignore illegal situations.

14. Do not keep long-lived references to a context-activity (a reference to an activity shoshould have the same life cycle as the activity itself)

15. Try using the context-application instead of a context-activity

16. Avoid nonstatic inner classes in an activity if you don't control their life cycle, use a static inner class and

Make a weak reference to the activity inside. The solution to the issue is to use a static inner class

A WeakReference to the outer class, as done in ViewRoot and its W inner class for instance.

(Use static internal classes when creating handler; otherwise, memory leakage may occur)

17. sp units are used for text in the Android UI layout. Other units use dp, and px units cannot be used.

18. The level of a method is too deep. You can use the Wei statement to reduce the level. You can extract multiple methods to reduce the amount of code.

19. Use BroadcastReceiver as few as possible, and frequent use of broadcast will cause

A) multiple to multiple calls

B) the passing parameters are not controlled at will.

C. There is no stack information like a pointer, and it is difficult to solve problems.

D) damages the encapsulation of classes and violates the High Cohesion and low coupling principle.

20. If Handler is not used, try to use less Handler.

A) parameters are not controlled at will, resulting in high maintenance costs.

B) after an asynchronous message is received, the interface status must be determined and the interface may have been destroyed.

C) When Handler is used, you must control the scope of a class. Handler cannot be passed to other classes, because this will damage the encapsulation of the class.

D. There is no stack information like a pointer and it is difficult to solve the problem. This is relatively easier to find than BroadcastReceiver, because it is relatively easy to find in a class.

21. Programming should follow the principles of high cohesion and low coupling. Minimize coupling between classes. A class should be less dependent on the attributes or methods of other classes.

22. The image management method can adopt Universal-image-loader.

23. Use has or is as the prefix of a Boolean variable

24. You cannot use System. out. println to print logs.

25. Variable names cannot be 1, 2, 3, 4... suffixes, depending on the name

26. The If method must have a {} package

27. The Log tag cannot be ""

28. Uniform development using format and import formats

29. Hard encoding is not allowed in the Code (separation from configuration, parameter-based, or interface-Oriented Programming)

In Android development, sometimes the code is hard-coded for convenience. In fact, this is a bad habit. Writing code on the PC platform may be used more directly. On the mobile platform, you sometimes need to consider multi-language issues. Android designed the getString () method to read String strings from the resource Res folder, which are saved in the Values. xml file as xml. The Android platform is more object-oriented to a certain extent. In addition to Java, the framework still uses the UI and code logic separation such as MVC. The UI can focus on designing the user interface, code can be re-released using Jar or MIDL files, greatly improving code reuse and maintainability.

The above are the disadvantages of hard coding. In fact, there are also some advantages. From a single language and a simple program, it has high operating efficiency and simple design methods, however, it is recommended that the MVC design be reasonable for complex projects. Android caches resource files and registers them globally in the R class. That is to say, findViewById caches the xml file, such as Layout or String.

30. Independent database operations cannot be performed in the for Loop

31. You cannot use ScrollView to wrap ListView/GridView/ExpandableListVIew. This will load all items of ListView into the memory, which consumes a lot of memory and cpu to draw a drawing.

The above is a summary based on past development experience (from yourself and colleagues). If you have any mistakes, please correct them. You are welcome to come up with your own ideas, I will keep updating this blog ..., hope everyone can make progress together!

 

Copyright Disclaimer: This article is an original article by the blogger and cannot be reproduced without the permission of the blogger.