this post was submitted on 21 Aug 2023
176 points (91.1% liked)

Mildly Infuriating

35446 readers
642 users here now

Home to all things "Mildly Infuriating" Not infuriating, not enraging. Mildly Infuriating. All posts should reflect that.

I want my day mildly ruined, not completely ruined. Please remember to refrain from reposting old content. If you post a post from reddit it is good practice to include a link and credit the OP. I'm not about stealing content!

It's just good to get something in this website for casual viewing whilst refreshing original content is added overtime.


Rules:

1. Be Respectful


Refrain from using harmful language pertaining to a protected characteristic: e.g. race, gender, sexuality, disability or religion.

Refrain from being argumentative when responding or commenting to posts/replies. Personal attacks are not welcome here.

...


2. No Illegal Content


Content that violates the law. Any post/comment found to be in breach of common law will be removed and given to the authorities if required.

That means: -No promoting violence/threats against any individuals

-No CSA content or Revenge Porn

-No sharing private/personal information (Doxxing)

...


3. No Spam


Posting the same post, no matter the intent is against the rules.

-If you have posted content, please refrain from re-posting said content within this community.

-Do not spam posts with intent to harass, annoy, bully, advertise, scam or harm this community.

-No posting Scams/Advertisements/Phishing Links/IP Grabbers

-No Bots, Bots will be banned from the community.

...


4. No Porn/ExplicitContent


-Do not post explicit content. Lemmy.World is not the instance for NSFW content.

-Do not post Gore or Shock Content.

...


5. No Enciting Harassment,Brigading, Doxxing or Witch Hunts


-Do not Brigade other Communities

-No calls to action against other communities/users within Lemmy or outside of Lemmy.

-No Witch Hunts against users/communities.

-No content that harasses members within or outside of the community.

...


6. NSFW should be behind NSFW tags.


-Content that is NSFW should be behind NSFW tags.

-Content that might be distressing should be kept behind NSFW tags.

...


7. Content should match the theme of this community.


-Content should be Mildly infuriating.

-At this time we permit content that is infuriating until an infuriating community is made available.

...


8. Reposting of Reddit content is permitted, try to credit the OC.


-Please consider crediting the OC when reposting content. A name of the user or a link to the original post is sufficient.

...

...


Also check out:

Partnered Communities:

1.Lemmy Review

2.Lemmy Be Wholesome

3.Lemmy Shitpost

4.No Stupid Questions

5.You Should Know

6.Credible Defense


Reach out to LillianVS for inclusion on the sidebar.

All communities included on the sidebar are to be made in compliance with the instance rules.

founded 1 year ago
MODERATORS
 

I have an app that I released a couple years ago (plus another legacy app that I maintain for one of my company's clients). My game has a long-ish title, but it was fine until some asshat at Google decides that 33 characters is too long. On top of that, every time I'm forced to update the target SDK, I need to spend several hours figuring out a bunch of new build errors. This is not how I wanted to spend my vacation time.

all 24 comments
sorted by: hot top controversial new old
[–] [email protected] 42 points 1 year ago (2 children)

Developers when they have to update their programs: this is annoying bullshit

[–] [email protected] 23 points 1 year ago (3 children)

If you have to update it, just to meet some arbitrary metric: Yeah.

[–] [email protected] 11 points 1 year ago (2 children)

It's not an arbitrary metric though... They want apps to stop using old APIs so they can deprecate them at some point. Platforms that aren't Windows (and Linux, to a lesser extent) don't have the resources to support old stuff forever. Be glad they don't make breaking changes more frequently, like Apple does :)

[–] [email protected] 9 points 1 year ago (1 children)

Google's definition of "Old API" though is like, 3 months. I don't know Apple but as mentioned in my other comment when I did stuff on GCP I remember breaking changes coming every month or 2. It's honestly terrible. Pub/Sub was the worse, a message broker that had breaking changes so frequently that I just spun up a kafka instance.

I get what you're saying, you should stay up to date, but Google just gives devs the middle finger. It really does feel like "Lol this isn't even a feature you use, and it's not like it's a security fix or anything, our developers are just bored and rewrote something again so drop everything now and go fix it."

[–] [email protected] 4 points 1 year ago

Google's definition of "Old API" though is like, 3 months.

Oh, okay. Admittedly I haven't done a lot of Android development and didn't realise how quickly Google deprecate APIs.

[–] [email protected] 6 points 1 year ago

As the other guy said, we're not talking hugely outdated. And I don't see why they should have fewer resources for supporting old stuff. Android has more users than Windows. Less corporate users, sure, but still, I imagine Google could easily finance that and I do not see it as rational that they don't.
Like, if Google hadn't made the Play Store a monopoly, devs would gladly be distributing elsewhere. Many of those who aren't looking for commercial success, do.

[–] [email protected] 3 points 1 year ago* (last edited 1 year ago) (1 children)

Wdym arbitrary metric? If nothing would have changed then there would be no build errors and the whole process would take a few mins.

Now since something does break, that means that there's some (soon to be) deprecated code which needs updating.

[–] [email protected] 2 points 1 year ago

With arbitrary metric, I mean that Google doesn't detect whether you're actually using deprecated APIs, they just detect that you've declared to be targeting Android API version 27 and that 27 is smaller than 31. Especially with smaller apps, you may have to go through the whole release process just to increment that number, with no actual code changes.

Another rather arbitrary metric is how often and quickly they want to deprecate APIs. In other ecosystems, you update your app to fix security issues or because you're developing new features. On Android, you often end up updating, because your Googly overlord demands an update.

[–] [email protected] 2 points 1 year ago

Honestly I was more annoyed at the reduced character limit.

[–] [email protected] 27 points 1 year ago (2 children)

The second word in your title is unnecessary.

Over the years I've had to work with Google maps, geocoding, Play, GCE, and more. Every time I have to work with any of it I swear it takes a time off my life. And then it's virtually guaranteed that, just about the time I forget what a horror show the last event was, they'll arbitrarily make some other massive breaking change to the SDK or APIs... or kill the product entirely. I've sworn off as much of google as I can both personally and professionally.

Now I'm doing the same with Microsoft since they don't seem to give two shits about security anymore.

[–] [email protected] 7 points 1 year ago

Google APIs are terrible to work with, but Microsoft is way worse in my experience. An API for one product may have been worked on by multiple teams that each had a different idea of how it should work.

[–] [email protected] 16 points 1 year ago (1 children)

It's a mad rule really.. it means work that was done for clients sometimes years ago and paid for has to be dug up and recompiled, when they were perfectly happy with the way they worked now.

Requiring 33 for new apps is fine, you're working on them already, upgrading is just part of it (which is more or less how apple work, you must use the latest xcode otherwise they reject). Requiring it for older ones probably means a heck of a lot of stuff is about to vanish from the play store on somewhat short notice.

There are some apps we've already decided to let die because the maintenance work isn't worth it.

[–] [email protected] 1 points 1 year ago (1 children)

Each and every line of code you write is a liability. Even more so when you wrote it for someone else. You must always be able to rebuild it from source, at least as long as your client expect the software to work. If you feel it's not worth it, you probably low-balled the contract. If you don't want to maintain code, have the client pay a yearly maintenance fee, give the code and the responsibility to maintain it to your client at the end of development, or add a time limit to it's support.

There's no "maintenance mode" software: either it's in use and must be kept updated with regard to it's execution environment, or it's not used anymore and can be erased and forgotten. Doing differently opens too much security issues, which shouldn't be acceptable for us all as a trade.

[–] [email protected] 3 points 1 year ago (1 children)

Customers won't pay maintenence. And code can't be maintained forever that isn't bringing in money. This is just the harsh reality.

[–] [email protected] 2 points 1 year ago (1 children)

Plus the code I wrote myself isn't usually what I have a problem whith changing. It's the various included packages and dependencies that in some cases may no longer be supported, and may not even have a similar replacement. I usually deal with this when updating an old web app that uses the Laravel framework. Some Composer packages are locked in to older versions. And when the client has a 20 hr/month budget, these types of updates can be tough to fit in the schedule.

[–] [email protected] 1 points 1 year ago

Yeah we have some tooling that isn't up to API 33 yet.. one app has been abandoned because of that - it'll be ios only for a while until there's resources for a rewrite.

[–] [email protected] 15 points 1 year ago (1 children)

Okay I'm siding with OP here. Google is dogshit when it comes to compatibility. When I was coding for GCP I counted how many breaking changes they rolled out and it totaled about 2 a month, I spent on average 4 days a month (almost a full working week) just upgrading Google's bullshit API changes.

Now, I'm all for upgrading stuff and keeping things ready to go, but there's a cadence to that. Most companies will treat downstream developers well, things like security updates are mandatory but rarely include breaking changes, new features may have breaking changes but they're optional (for a year or maybe even 2, to give you time to upgrade your app).

Google just throws that all out the window and quite literally sends out messaging like "You need to drop everything you're working on and upgrade to this <> because <> for <>.

I have successfully prevented 2 companies from going over to GCP based on this. They're too fickle, they see a shiny new feature and want to cram it in but don't care about anything that was made over 3 months ago. Avoid developing on Google products.

[–] [email protected] 2 points 1 year ago (1 children)

I can't speak for GCP as I've never used it, and as much as I love to jump on the Google hate train (they really do suck in so many ways), I am an Android app developer who also has to deal with the target API upgrades and they're usually not terrible. Most of the time, just a single line change, build, and push.

But most of my apps don't do any sort of tracking or access the file system, so outside of the whole permissions change a few years back, these have been easy to do.

The name truncation thing here is silly, though. Very annoying.

I say all this to say that I do think Google is doing a good thing here. In this one regard. I can't stress enough how specific I'm being with my praise here.

[–] [email protected] 2 points 1 year ago

That's fair, I'm not an app developer so I don't know that side of the house. Cloud and live services I hated, so much churn.

[–] [email protected] 5 points 1 year ago

It's super annoying on my phone.

Every single time I open the app it shows one notification. That notifcation say "Turn on important notifications!". How about no?