How sometimes bad code and antipattern solve
Hi% username%!
Today I would like to tell you how bad code helped me in a project.
Who cares, I ask under the cat.
I inherited a project for maintenance. I do not know who was written, but this person hiccups to this day. The essence is this - there is an application for collecting photo reports in the store and sending them to the manual on the server.
')
Everything seems to be simple, but there were constant complaints of employees about the fall of the application when photographing. Analysis of the code showed that when the camera called the intent of the camera application, Android killed the application due to lack of resources and upon returning the result to the activation, the latter was re-created and did not contain the data needed for operation. Recreation of activation was simply not processed. Well, yes, there is configChanges * sarcasm *
Having tormented 2 days, having corrected the code, having thrown out repeating fragments I began to test. I threw a taskkiller into the emulator, launched the camera, killed the process. Fotkayu - beauty !!! Everything is beautiful, there is a photo. I click save and ... broads) The application has fallen.
The reason for the fall - no data on the current report. It turned out that the application was a miracle singleton, which was kept in himself EVERYTHING! Absolutely all the critical data needed for the application and even more. This includes an authorization token, and 40 report status fields and links to classes describing the report and user geodata and a couple of Bitmap collections. In an instant, we lost everything that could be lost.
The result was described to the customer. Refactoring is appreciated, but they did not have that much money. At the same time, tearfully asked to do something and tuck crutches.
All that occurred to me was to fix the singleton so that it would become reliable and without change its interface. The following was thought up - everything that can be pushed into the SharedPreferenses was saved there.
Roughly, stupidly, but there is no need to change the code in the whole project and our Singleton has become more stable (there are Bitmap collections with which we haven’t done anything yet). All objects that can only be serialized were serialized and stuffed into SharedPreferences too.
The application went to the test, in the product and the fall stopped at 70% of the devices. On the others, after sending the result from the camera, not the current one, but the previous activation in the stack was recreated. For me, this is still a mystery. Guru - explain in the comments.
The essence of this - Activi A starts Activi B with the result. Activation B launches the camera intent with the result.
When the process was killed during the operation of the camera, activation of A was recreated to create a photo. Activation B did not call either onCreate or onActivityResult. (PS Android 4.4)
google and stackowerflow did not respond, I had to go a different way and write more bad code.
If re-creation fails, you can prohibit the kill, I thought, and proceeded to step 4.
How to make Android not kill the process? My thoughts were: “If we tell OS, that we have an important foreground service that performs important calculations for us for exactly as long as we take pictures of goods. It could definitely work. ”
So born in the project foreground-garbage truck. He drove a cycle from 0 to 60 and fell asleep in the body for a second. As soon as the result came from the camera, the service was killed. The application has been collected and given for testing.
The result - KitKat was smarter and nailed the process. That is, nothing has changed.
I was already desperate when another thought occurred to me: “And if you stupidly save the link to activations in a singleton and call startActivityForResult right from the foreground garbage truck?”. I have never done this, and I hope no more.
The application is collected, given to the test and ... lo and behold, the process no longer closes.
Instead of a conclusion. The customer is warned that he has a bad application and I made it even worse, but it works as expected by the company's employees.
Finally. Tell us about your worst “code” in your career. Let's cheer each other up.
Today I would like to tell you how bad code helped me in a project.
Who cares, I ask under the cat.
I inherited a project for maintenance. I do not know who was written, but this person hiccups to this day. The essence is this - there is an application for collecting photo reports in the store and sending them to the manual on the server.
')
Everything seems to be simple, but there were constant complaints of employees about the fall of the application when photographing. Analysis of the code showed that when the camera called the intent of the camera application, Android killed the application due to lack of resources and upon returning the result to the activation, the latter was re-created and did not contain the data needed for operation. Recreation of activation was simply not processed. Well, yes, there is configChanges * sarcasm *
Step 1. Rebuild processing
Having tormented 2 days, having corrected the code, having thrown out repeating fragments I began to test. I threw a taskkiller into the emulator, launched the camera, killed the process. Fotkayu - beauty !!! Everything is beautiful, there is a photo. I click save and ... broads) The application has fallen.
Step 2. Singleton - Evil Evil
The reason for the fall - no data on the current report. It turned out that the application was a miracle singleton, which was kept in himself EVERYTHING! Absolutely all the critical data needed for the application and even more. This includes an authorization token, and 40 report status fields and links to classes describing the report and user geodata and a couple of Bitmap collections. In an instant, we lost everything that could be lost.
The result was described to the customer. Refactoring is appreciated, but they did not have that much money. At the same time, tearfully asked to do something and tuck crutches.
Step 3. Change Singleton
All that occurred to me was to fix the singleton so that it would become reliable and without change its interface. The following was thought up - everything that can be pushed into the SharedPreferenses was saved there.
public String getAuthToken() { return getStingFromPref(AUTH_TOKEN); } ..... // . Roughly, stupidly, but there is no need to change the code in the whole project and our Singleton has become more stable (there are Bitmap collections with which we haven’t done anything yet). All objects that can only be serialized were serialized and stuffed into SharedPreferences too.
The application went to the test, in the product and the fall stopped at 70% of the devices. On the others, after sending the result from the camera, not the current one, but the previous activation in the stack was recreated. For me, this is still a mystery. Guru - explain in the comments.
The essence of this - Activi A starts Activi B with the result. Activation B launches the camera intent with the result.
When the process was killed during the operation of the camera, activation of A was recreated to create a photo. Activation B did not call either onCreate or onActivityResult. (PS Android 4.4)
google and stackowerflow did not respond, I had to go a different way and write more bad code.
If re-creation fails, you can prohibit the kill, I thought, and proceeded to step 4.
Step 4. Final. Foreground garbage truck
How to make Android not kill the process? My thoughts were: “If we tell OS, that we have an important foreground service that performs important calculations for us for exactly as long as we take pictures of goods. It could definitely work. ”
So born in the project foreground-garbage truck. He drove a cycle from 0 to 60 and fell asleep in the body for a second. As soon as the result came from the camera, the service was killed. The application has been collected and given for testing.
The result - KitKat was smarter and nailed the process. That is, nothing has changed.
I was already desperate when another thought occurred to me: “And if you stupidly save the link to activations in a singleton and call startActivityForResult right from the foreground garbage truck?”. I have never done this, and I hope no more.
The application is collected, given to the test and ... lo and behold, the process no longer closes.
Instead of a conclusion. The customer is warned that he has a bad application and I made it even worse, but it works as expected by the company's employees.
Finally. Tell us about your worst “code” in your career. Let's cheer each other up.
Source: https://habr.com/ru/post/271703/
All Articles