9 ms·
Android, evolvability and Comcast
- mayoff 10y agoIf 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
- gingerbread-man 10y agoI'm usually in favor of replacing "flashy" titles, but this is a good one. The analogy fits.
- thomastjeffery 10y agoI miss that title. I have no clue what the article is about from reading the new title.
- Infinitesimus 10y agoThe 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. Gradle can be confusing to a first time user but Android studio does provide a GUI for managing dependencies.
- XNOVRJ 10y agoAndroid studio is based on Intellij by Jetbrains, the creator of Kotlin. I would count on it.
- ufmace 10y agoKotlin is pretty cool generally, but I'm not so sure it would help the problems of Android development that much, since most of your time will be spent dealing with the plain-Java Android classes and how Android expects you to do things. You'd have to rearchitect the whole Android system in it to really make a difference, and if you're doing that already, it probably doesn't matter that much what language you're doing it in.
- vikeri 10y agoThe 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)
- krzyk 10y agoBut there is a single problem with React Native: Javascript (and all languages that come from it). It's frequently one of the most hated ones as it is loved. Dynamic language is not necessary the best thing invented, if it were there wouldn't be any other kind of languages.
- paulddraper 10y agoDoesn't it follow that static language is not necessarily the best thing invented, if it were there wouldn't be any other kind of languages?
- krzyk 10y agoYes, but parent response suggested that dynamic langs are the answer to android development problems. Adding more to the discussion: Android env is like a framework (as opposed to library), it is always harder to work in frameworks than using libraries - e.g. lots of stuff you will have trouble mocking out in unit tests.
- tumblen 10y agoLots of great experiences with Typescript being reported and I am loving Flowtype lately so the era of only dynamic JS is fading out. A lot of the JS hate goes out the window with ES6 and type systems.
- vikeri 10y agoI was just addressing the issues outlined in the post. I would hardly define ClojureScript as a language that came from JavaScript. Naturally there are cases when a typed language is better than a dynamic one.
- 10y ago
- diyseguy 10y agoAmen! I find Android programming excessively verbose and convoluted. I thought Google was supposed to be staffed by geniuses. The whole thing feels designed by a committee - like something Microsoft would put out. Why didn't they use Python? (Yes I've tried Kivy - meh)
- yjftsjthsd-h 10y agoProbably historical reasons; when Android was created, was Python good enough? Particularly on underpowered processors with tight power requirements?
- diyseguy 10y agoAt the time Google started promoting Android OS, Google was well known to use primarily Python internally. So I was very shocked and discouraged by their choice of Java. I assume it was to reach the widest developer audience at the time. Maybe a case can be made for using Java otherwise, but Java is my least favorite language due to it's excessive verbosity and other pointlessly fussy restrictions.
- yjftsjthsd-h 10y agoAndroid was not started by Google; I presume when they bought Android Java was already entrenched
- CyberDildonics 10y ago> Why didn't they use Python Are you seriously suggesting using 50x the processing power as a native program on a mobile phone?
- lostmsu 10y agoDid he even ever develop a single complex UI app (or any app actually) in Python?
- 10y ago
- dingo_bat 10y agoI never could put my finger on it till now, but this is why I found Android dev frustrating.
- Ultramax 10y agoAs someone who has had to deal with Assembly in the 80s for development projects, Java sounds and works great! I guess it depends on your experience, attitude and point of view.
- CyberDildonics 10y agoBetter than assembly in the 80s is not a high bar.
- guelo 10y agoI'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.
- awinter-py 10y ago(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 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.
- vt240 10y agoNo experience on andriod, but I really enjoyed your analogies. Fun to read.
- awinter-py 10y agoThanks! Your acoustics business looks awesome.
- pebers 10y agoIt does matter what the language / ecosystem is; learning curves are not equal across all of them. Having learnt Go a while back, I was surprised at how short a period it took to feel at least reasonably comfortable & productive with it. I've seen the same with colleagues as well. That might not be so easily possible for a GUI mobile app though; maybe there's more necessary complexity there. But aiming for simplicity is a good goal to have regardless.
- ryukafalz 10y agoSpeaking of those terms and conditions, I was really surprised to see this in there: >You may not use this SDK to develop applications for other platforms (including non-compatible implementations of Android) or to develop another SDK. You are of course free to develop applications for other platforms, including non-compatible implementations of Android, provided that this SDK is not used for that purpose. Older versions of Android Studio were under the Apache License 2.0, but they seem to have changed that sometime in 2015.
- hutzlibu 10y agoI have many complaints with java, but this: "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.
- awinter-py 10y agoI'm sensitive to the argument that public/private rules improve maintainability of libraries by shrinking the exported API. Maybe, but that's a maintainability argument, not a usability/reusability argument. It's hard to predict which part of your program developers are going to need. Also, 'private by default' prevents the gradual modularization of code that happens in languages lacking visibility rules.
- ashark 10y agoMy advice to a new Android developer: 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-with-flow-and-mortar-5beafcd83761 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.
- ZanyProgrammer 10y agoBased on your post I can't ever imagine wanting to develop Android apps.
- dboreham 10y agoOr any software ;) But it's "situation normal" for most software development activities, no?
- ZanyProgrammer 10y agoIs it? And if so, I can see the reluctance amongst some to call us a proper engineering field.
- devgutt 10y agoBut you can always check the code easily and figure out how something actually works. Not the best solution, but it saved me more than once when the documentation or stack overflow doesn't suffice.
- badprose 10y agoA lot of the complaints seem like nice-to-haves. 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.
- warcher 10y agoMan, I knew this was a troll when I clicked the link. I'll briefly vent my spleen and get on with a substantive comment. I get real tired of web soft boys coming into native and complaining about how complicated it is on the metal. This stuff is hard cause you're not just churning html. It's harder work than writing a web page. Sorry. Specifically, mobile is resource constrained in a way that server-side work just isn't. Your render thread is a hot thread, and you better not jam it up. That one singular concept is the underlying cause of so, so much of the obfuscation and confusion associated with mobile development. But that's the gig. No, switching to javascript won't fix it. Switching to javascript will actually make it much worse, as the kinds of industrial grade tools available to make concurrency manageable (though prone to removing fingers from script kiddies or the unwary), to manage memory, to deal with a database directly, to deal with bluetooth devices, on and on are wholly unavailable, or worse still, are abstraction libraries that require you to fluently deal with both your javascript interface and some really deep native interop libraries, lest you be entrapped in cut-and-paste script kiddiehood. I could go on at length about the myriad pitfalls and difficulties associated with mobile development, but the simple fact is that doing something cool is hard work.
- awinter-py 10y agoThen don't switch to JS, switch to C++ as the primary dev language. The performance-sensitive parts of the OS are already in C++ and the NDK exists, so this isn't that big a jump in terms of support from the android maintenance team. C++ is not slower than java on constrained hardware, also is more respectful of memory. Is it harder to use? I don't think so but I may be in the minority here.
- warcher 10y agoC/Java interop is pretty painful still, and the tooling for native debugging in android studio is notoriously unreliable. (I hear it's better now, but I haven't had to get into those libs recently, so I can't say definitively. Last go round I had to roll Eclipse to debug ndk libs. Yeah. Eclipse.)
- warcher 10y ago
- bitmapbrother 10y agoI'm so looking forward to his follow up post when he starts trying to develop an iOS app with Xcode and Objective-C.
- pducks32 10y agoI think you mean with XCode and Swift which I love but you just feel like XCode doesn't like it's new friend.
- pebers 10y agoParts of this definitely resonate with my experience; there's a reasonable amount of high-level documentation about fixing specific Android build issues, but nearly nothing describing how the system actually works. Lots of StackOverflow answers exist saying "add xyz to your build.gradle file" but there's a dearth of anything describing what the real build process for an Android app is. (For various reasons I didn't have to deal with a lot of the actual app coding, so the XML layout systems were less troubling to me than the author). > When I get the call from G’s android team to build a better buildsystem I can only hope that this is "when" and not "if" ;-) I can't believe the current system can't be improved upon though...
- relics443 10y agoI stopped taking the author seriously when I saw that he was using ListView. Maybe that's a factor of poor documentation, but there's no reason to use ListView (and the are many reasons not too). I'll admit there are issues with Android, but reducing them to the same tired arguments against Java is just lazy (and lack of config files?). [Developing for Android for close to 8 years]