This should be agreed with the server and should not be changed easily. If it must be changed, you can use gson to create entity classes to parse, so that the added fields will not affect the program, and it is easy to change if you want. Data parsing can also be done by writing two methods, one is to parse the unchanged fields, and the other is to parse the fields that may change. In this way, even if it changes, it will not affect the normal operation, but the changed fields cannot be obtained
We only handled the exception. The server returned an exception, GONE the root layout, and then gave a prompt. The formal environment should not have problems such as json format changes that can easily cause crashes. Of course, if you do have this situation, add a method during initData and check the values one by one. I didn’t expect any very subtle method...
Use Gson. Even if there is one more or one less field, no error will be reported. The most fields are null. Just make more non-empty judgments on the layout! Generally speaking, background field changes must be notified to the front end
Generally, all possible fields are written into the bean, and then given an initial value. If the type of the field is uncertain, just use Object and List<Object>, and then determine the type. I have also encountered something even more exaggerated. The elements in the List have different types. At that time, I used List<?>
Report to your boss that your colleagues are making random changes to the background.
- Solving this kind of problem is pointless, it means writing extra code to deal with some human stupidity.
This kind of thing should be resolved during team communication. Don't use technology to solve things that should be solved through communication, which is like treating a headache.
1. Find the root cause of the problem. Is it arbitrarily changed by the server or the object fields given at the beginning were not clearly stated? 2. This involves the contractual nature of the server and needs to be determined; if the server violates the contractual nature, you can go to your leader directly. , let him coordinate with the server side
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Please follow the interface document for this. It is impossible to change this at will. If you want to make changes, change them when necessary.
This should be agreed with the server and should not be changed easily. If it must be changed, you can use gson to create entity classes to parse, so that the added fields will not affect the program, and it is easy to change if you want. Data parsing can also be done by writing two methods, one is to parse the unchanged fields, and the other is to parse the fields that may change. In this way, even if it changes, it will not affect the normal operation, but the changed fields cannot be obtained
We only handled the exception. The server returned an exception, GONE the root layout, and then gave a prompt. The formal environment should not have problems such as json format changes that can easily cause crashes. Of course, if you do have this situation, add a method during initData and check the values one by one. I didn’t expect any very subtle method...
Use Gson. Even if there is one more or one less field, no error will be reported. The most fields are null. Just make more non-empty judgments on the layout! Generally speaking, background field changes must be notified to the front end
Generally, all possible fields are written into the bean, and then given an initial value.
If the type of the field is uncertain, just use Object and List<Object>, and then determine the type.
I have also encountered something even more exaggerated. The elements in the List have different types. At that time, I used List<?>
Report to your boss that your colleagues are making random changes to the background.
- Solving this kind of problem is pointless, it means writing extra code to deal with some human stupidity.
This kind of thing should be resolved during team communication. Don't use technology to solve things that should be solved through communication, which is like treating a headache.
1. Find the root cause of the problem. Is it arbitrarily changed by the server or the object fields given at the beginning were not clearly stated?
2. This involves the contractual nature of the server and needs to be determined; if the server violates the contractual nature, you can go to your leader directly. , let him coordinate with the server side
Communicate clearly with the backend about which interface returns what fields + types. Remember to notify if there are any changes