3 ms·
Just some thoughts about SO: * The android section is terrible. The questions are a mixture of people not knowing how to write java code at all mixed with ques
by cel1ne 10y ago
Just some thoughts about SO:
* The android section is terrible. The questions are a mixture of people not knowing how to write java code at all mixed with questions of people getting hindered by the terrible SDK. (I develop software in Java for 10+ years and Android still gets me sometimes.)
This situation would be better if it wasn't so easy to shoot yourself in the foot with the android-SDK, but nothing we can do about that now.
* Sometimes I have in-depth question about libraries which, if I follow the support-instructions, often go like this:
1. Ask in the chat (ugh, why chat?): I almost never do that, because I need archivable asynchronous communication not chat.
2. Ask on the mailing-list if there is one. This goes well in some projects.
3. Open a github-issue. In overwhelmed projects like react-native, you get immediately forwarded to SO.
4. Ask on SO where nobody answers because nobody knows the technical details.
So… The maintainers of projects like react-native often get spammed with general coding questions of newcomers, which leaves no time for in-depth questions.
Another problem is that, especially in Android, many answers are not actual solutions but crude workarounds that work in specific cases and might even break more stuff in the future. But: "Hey it compiles!".
frustrated
- Drdrdrq 10y agoHey, really, you find Android SDK terrible? Genuinly curious, which parts? I have written my share of Java (though I wouldn't consider myself a hardcore Java programmer) and I found Android... logical, well documented and in general a delight to work with (well, apart from Eclipse and sloooooow emulators).
- cel1ne 10y agoIt's gotten better, but check my comments from some time ago: https://news.ycombinator.com/item?id=8329034 https://news.ycombinator.com/item?id=8329034 https://news.ycombinator.com/item?id=9476547 https://news.ycombinator.com/item?id=9476547 Generally: bad inheritance, bad separation of concern, unidiomatic java (I think much of it was automatically converted from C++), overcomplicated classes and just so many wtf-moments I had. Example: You want to store state. 1. In standard activities you have this really nice method "onSaveInstanceState" where you can save state to a "Bundle". And "onCreate" where you are handed a bundle to restore. You write the logic for doing that and should be done. 2. Then you learn that "onSaveInstanceState" isn't actually called when stopping an app, only when rotating the screen, so you have to save your state elsewhere. In onStop for example, sounds nice. 3. onStop doesn't take a "Bundle". Hm… ok let's see save it to disk. 4. Oh, Bundle isn't meant to be serialised because the internal format is allowed to change, so you have to write serialisation again after all. Ok, "Bundle" is out. Let's use json and be done with it. 5. But for some reason it sometimes doesn't work. Turns out "onStop" only sounds like it's being called when your app stops. It's actually not guaranteed to be called, so you have to use "onPause". This is just one example of many where things could be more aptly named, better documented and so on.
- Drdrdrq 10y agoThanks for the explanation. I guess I never even looked at the names of these callbacks because I just followed the app lifecycle diagram - yeah, I agree, the names could be much better.
- cel1ne 10y agoWell nothing in the diagram here says anything about onStop being not guaranteed: https://developer.android.com/training/basics/activity-lifecycle/stopping.html https://developer.android.com/training/basics/activity-lifec...