Hacker News Reader

Comment by gleenn | Hacker News Reader

Fragments were way over engineered. Many people completely ignored them because you basically had to rewrite a significant portion of your app to support the type of flexibility they were supposed to give you. The lifecycle of apps is already complicated enough, and fragments added even more complexity. Like another poster mentions, completely ignoring fragments is a pretty reasonable choice.

View on HN

It was around the time I started playing with fragments that I realized that the native Java android toolkit was a giant pile of crap.

Android, I think, is not even supposed to be a well-engineered system. It is not central to its purpose. Its purpose is to eat marketshare, collect data, and ensure there is an outlet for ads. It only has to work well enough to do those things :)

I get the sense that it was all slapped together as quickly as possible.

Well, yeah, that's the goal of everything commercial. Being well-engineered is a means, not an end.

Nah, tons of companies are incredibly passionate about quality in itself. Sometimes to a fault!

iOS and UWP are both commercial and the quality of their tooling and OS frameworks runs circles around Android's.

Sadly it is hard to win over free beer.

I got the same impression, it's just filled with hacks to get proper behavior and don't get me started on the support libraries, oof how I hate those.

> I get the sense that it was all slapped together as quickly as possible.

It was, historically. Android was a startup that had to get to market as fast as they could. To make matters worse, once the iPhone came out they had to quickly switch from a Treo-like interface to a iOS-like one in order to stay relevant.

To Google's credit, they've been trying for years to clean it up, but there's only so much they can do…

Sorry just got stuck and smiled over your first sentence "Fragments were way over engineered." and couldn't restrain myself of thinking about all Googlers that passed the whiteboard tests

True I don't think I have ever had an interview question that questioned my ability to keep simple. I think this is where experience comes in valuable, the ability to "keep things as simple as possible and no simpler".

I find the best approach to KISS is to write it as simple as possible under the assumption you'll have to throw it away. If it turns out you don't have to (after measuring), then all the better.

I host interviews for Google. A simpler design that solves a problem is definitely valued better than an unnecessarily-complicated one.

Reply on news.ycombinator.com