How sometimes bad code and antipattern decide

    Hi% username%!

    Today I would like to talk about how bad code helped me in the project.

    Who cares, please, under the cat.

    I inherited an escort project. I don’t know who wrote it, but this person hiccups to this day. The bottom line is that there is an application for collecting photo reports in the store and sending them to the management on a server.

    Everything seems to be simple, but there were constant complaints from employees about the application crashing when taking photos. The analysis of the code showed that when calling the intent of the camera application, Android killed the application due to lack of resources and upon returning the result to the activity, the latter was recreated and did not contain the data necessary for work. The recreation of activity was simply not processed. Well yes, there is configChanges * sarcasm *

    Step 1. Recreation Processing


    After a torment of 2 days, correcting the code, throwing out the repeating fragments, I began to test. I threw it into the taskkiller emulator, launched the camera, and killed the process. Fotkayu - beauty !!! Everything is beautiful, there is a photo. I click save and ... broads) The application crashed.

    Step 2. Singleton - Evil Evil


    The reason for the fall - there is no data on the current report. It turned out that the application had a miracle singleton, which kept EVERYTHING in it! Absolutely all the critical data necessary for the application to work and even more. This is an authorization token, and 40 report status fields and links to classes that describe the report and the user's 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 didn't have that much money. At the same time, they asked tearfully to do something and instruct crutches.

    Step 3. Change Singleton


    All that came to mind was to fix the singleton so that it became reliable and at the same time its interface did not change at all. The following was invented - all that can be shoved into SharedPreferenses was saved there.
    public String getAuthToken() {
            return getStingFromPref(AUTH_TOKEN);
    }
    .....
    // и так далее.
    


    It’s rude, stupid, but you don’t need to change the code in the whole project and our Singleton has become more stable (there are Bitmap collections with which I haven’t done anything yet). All objects that can only be serialized were serialized and also crammed into SharedPreferences.

    The application went to the test, in prod and crashes stopped on 70% of devices. On the rest, after sending the result from the camera, not the current but the previous activity in the stack was recreated. For me, this is still a mystery. Guru - explain in the comments.
    The bottom line is - Activity A starts Activity B with the result. Activity B launches intent cameras to get the result.
    When the process was killed during the operation of the camera, activity A was recreated to create the photo. Activity on B was not called either onCreate or onActivityResult. (PS Android 4.4)

    google and stackowerflow did not give an answer, I had to go a different way and write more bad code.

    If you can’t recreate it, you can forbid killing, I thought, and went on to step 4.

    Step 4. Final. Foreground Garbage Truck


    How to make Android not kill the process? My thoughts were: “If we tell the operating system that we have an important foreground service that performs the calculations that are important to us exactly as much time as we take pictures for the goods. It could definitely work. ”

    So he was born in the foreground garbage truck project. He drove a cycle from 0 to 60 and fell asleep in his body for a second. As soon as the result came from the camera, the service was killed. The application was compiled and submitted for testing.
    Result - KitKat turned out to be smarter and nailed the process. That is, nothing has changed.

    I was already desperate when another thought occurred to me: “And if you stupidly keep the link to the activity in the singleton and call startActivityForResult directly from the foreground garbage truck?” I have never done so and hopefully no longer have to.

    The application is compiled, put to the test and ... lo and behold, the process no longer closed.

    Instead of a conclusion. The customer is warned that he has a bad application and I made it worse, but it works as the company employees are waiting for this.

    Finally. Tell us about your “worst code” in your career. Let's cheer each other up.

    Also popular now: