11–20 of 71 posts
I never could put my finger on it till now, but this is why I found Android dev frustrating.
I guess it depends on your experience, attitude and point of view.
If this post gains traction, its title will probably be changed to “Android, evolvability & comcast” since that's the title of the linked article. So here, for posterity, is the original post title, which made me chuckle: If you like calling comcast you'll love android studio
The solution is called React Native. - Single file app: Check - Super fast rebuild: Check - Dynamic language (high reusability and one-liners): Check (Use ClojureScript to take this even further)
That said, even as a clojurescript fan, I wouldn't call this a solution, more like a practical workaround for a deeply flawed dev experience.
The Java problems the author complained about can be addressed by switching to Kotlin. I hope Google gives Kotlin 1st class support in android studio and even pushes it as the default language as it is more pleasant to use in my experience. Not sure single file creation of an Android app (with a user inferface) is possible/advisable though since the separation of view concerns and logic concerns can come in handy. Gr…
I'm not saying Android development or Java are that great but this guy spent two weeks on it. That's not enough time to get a feel for the environment. It doesn't matter what the language is, if you drop a developer into a completely unfamiliar one they will feel awkward annoyed and lost for at least a couple months.
That said, if you drop me in a dumpster I can tell immediately that it's a hot day. The forum content around the android problems that I had show that the same problems have been cropping up for years with no improvement.
I don't doubt there are real reasons for the rigidity of android interfaces. Could be that the underlying system is written in C and doesn't interface easily with java. Could be limited staff and high legacy support requirements.
The solution is called React Native. - Single file app: Check - Super fast rebuild: Check - Dynamic language (high reusability and one-liners): Check (Use ClojureScript to take this even further)
There is something seriously wrong with our industry. How can this even be suggested as a solution?
I'm not saying Android development or Java are that great but this guy spent two weeks on it. That's not enough time to get a feel for the environment. It doesn't matter what the language is, if you drop a developer into a completely unfamiliar one they will feel awkward annoyed and lost for at least a couple months.
(author here). You're right that it takes more than a month to get a handle on tricks tools & quirks in a new language / buildsystem. That said, if you drop me in a dumpster I can tell immediately that it's a hot day. The forum content around the android problems that I had show that the same problems have been cropping up for years with no improvement. I don't doubt there are real reasons for the rigidity of android…
"Java is pretty bad at producing portable one-liners. In my opinion that’s because of the public/private feature (completely unnecessary), "
was the point, when I stopped taking him seriously.
1) The way things are done in the docs is often wrong on fundamental levels. Using libraries from the android team for e.g. network comm is often wrong, even if it's "new and friendlier" (nope).
2) The docs are often outdated. Also their examples are always for exactly not the case you need. 100% of the time.
3) Stackoverflow posts are often outdated.
4) You will eventually hit a years-old bug that's been marked "obsolete" in Android's bug tracker. It isn't. There will be a billion workarounds for various Android flavors in the comments. There will be a patch for Android itself with pleas for them to apply and release it. They will not have. The Android team hates you.
5) Don't expect libraries for Google services to be better on their own damn operating system than they are for Javascript.
6) Just use all of Square's Android libraries and development practices. Retrofit, flow, and so on. [0]. In the best of all worlds Google would shutter the Android SDK/libraries team, acquihire Square, and hand it over to them.
[0] https://medium.com/square-corner-blog/simpler-android-apps-w... (sorry, medium post :-( )
[EDIT] 7) the interfaces for many of the more complex UI elements seem to have been made by the interns. Don't be surprised when you have to resort to reflection to style them.
As in, it would be nice to have a better build system, but if you work in Android Studio, you don't need to know what gradle is. (Like visual studio devs not knowing much about msbuild.
It would be nice to have a less verbose language than Java, but the IDE is starting to do a lot of this syntactic sugar work anyway.