I'll give an example. At my previous company there was a program where you basically select a start date, select an end date, select the system and press a button and it reaches out to a database and pulls all the data following that matches those parameters. The horrors of this were 1. The queries were hard coded.

They were stored in a configuration file, in xml format.
The queries were not 1 entry. It was 4, a start, the part between start date and end date, the part between end date and system and then the end part. All of these were then concatenated in the program intermixed with variables.
This was then sent to the server as pure sql, no orm.
Here's my favorite part. You obviously don't want anyone modifying the configuration file so they encrypted it. Now I know what you're thinking at some point you probably will need to modify or add to the configuration so you store an unencrypted version in a secure location. Nope! The program had the ability to encrypt and decrypt but there were no visible buttons to access those functions. The program was written in winforms. You had to open the program in visual studio, manually expand the size of the window(locked size in regular use) and that shows the buttons. Now run the program in debug. Press the decrypt button. DO NOT EXIT THE PROGRAM! Edit the file in a text editor. Save file. Press the encrypt button. Copy the encrypted file to any other location on your computer. Close the program. Manually email the encrypted file to anybody using the file.

you are viewing a single comment's thread
view the rest of the comments

[–] NotMyOldRedditName@lemmy.world 16 points 2 days ago* (last edited 2 days ago) (1 children)

For anyone who knows and understands Android development, process death, and saved state...

The previous dev had no understanding of any of it, and had null checks with returns or bypassing important logic littered all over the app, everywhere.

I could only assume he didn't understand how all these things were randomly null or why it was crashing all the time so he thought oh, i'll just put a check in.

Well, you minimize that app for a little bit, reopen it, and every screen was fucked visually and unusable, or would outright crash. It was everywhere. This was before Google introduced things like view models which helped but even then for awhile weren't a full solution to the problem.

It was many many months of just resolving these problems and rewriting it the correct way to not have these problems.

[–] Kazumara@discuss.tchncs.de 10 points 2 days ago (1 children)

Oh I remember. There are tons of events and associated handlers. Even just switching to landscape view stops and restarts an android view I think. Friends at uni handled that problem by disallowing landscape view instead of handling it hahah

[–] NotMyOldRedditName@lemmy.world 6 points 2 days ago* (last edited 2 days ago)

Friends at uni handled that problem by disallowing landscape view instead of handling it hahah

😭

Such a tragic and common 'solution' because it doesn't actually solve it, it just delays it until someones minimizes the app for 30 minutes and re opens it, or one of the many many other ways that also trigger it.

I've had some apps that I do lock to portrait, but I would disable that flag on debug builds, since rotating the phone was the easiest way to test for some of those bugs. I didn't worry about a good looking UI since it'd be locked in portrait, I just used it to test for bugs.