2 ms·
iOS developers are pretty lucky if that's the biggest problem they have with the official documentation. Story time: I started my career in programming with An
by jmfayard 7y ago
iOS developers are pretty lucky if that's the biggest problem they have with the official documentation.
Story time: I started my career in programming with Android development in the years 2012-2014.
And it was quite painful.
In 2012, I thought that iOS and Android were going to be the two only huge mobile platforms, and here I was right. I randomly chose Android because that was the smartphone I had at that point.
I thought it was going to be cool. And here I was mistaken.
After some months, it became obvious that it was going to be hard. The coolness effect disappeared quickly. I struggled a lot to write good Android code. No matter how much I RTFMed, it seems that I was only able to copy/paste things on a trial and error basis. Building the simplest feature (login/subscription screen) took a looong time. The iOS colleagues generally seems significantly faster than us (although they have their own rabbit holes). I never (even now) understood how to make things look nice. But worse than that it was never reliable.
The code I produced was hard to write, hard to understand, harder to maintain, with traps everywhere. I went to Android conferences and the Android team asked us: are you writing tests? I didn't dare to answer "not really" but that was the truth. I RTFMed once more how to write tests on Android, but it never made sense to me.
To give you some context, it was a number of years ago, I was a junior developer and my colleagues were quite young as well. Things would be very different if you start now and have the luck to have a good Android mentor to guide you.
But what I had was the official Android documentation.
And now that I am more experienced, I can see clerly that it was horribly written.
Even today, it continues to mislead every new generation of developers in a dark path.
The worst part is the so-called "Android Burrito Design Pattern" where you just put everything - your business logic, your application lifecycle, your views, you bindings, your threading, ... - in one big fat BurritoActivity or BurritoFragment that wraps everything. Make the beginner mistake to believe that the documentation writers know what they are doing, and use those samples as a blueprint for how you should build things, and you are going to find yourself in a very dark path indeed.
I wrote about it here
https://dev.to/jmfayard/android-s-billion-dollar-mistake-327b https://dev.to/jmfayard/android-s-billion-dollar-mistake-327...