Can you give an example?

That's the joke...

I guess mostly the question of data loading and periodic task requests, and the numerous bad APIs (loaders, usage of content providers within your own app, sync adapters) that are now replaced with AAC (livedata + room + work manager). And a mention of FusedLocationService and ExoPlayer. AAC is a nice tool for what it was built, although "system-level things (or sometimes even stuff in support lib) not working as you'd expect" tends to take up more time.

Hmm, I agree as well; shallow and pedantic.

The entire architecture based on Activity/Fragments is flawed and they keep patching it instead of getting rid of it all. Fragments were essentially introduced when they realized that oh our Activities are so heavy weight and they are not really good to make more complex GUIs, so let's patch the design and bring in Fragments and oh by the way we still have those View classes, great ...... each one have their own lifecycle...and now let's patch in asynchronity in it as well...... Other platforms, like iOS and Linux have solved the same problems of GUIs in much more elegant ways. These Android Googlers are still stucked with old school Java style thinking. I feel like I am working on some 80s platform when developing for Android

i tawt a taw a putty tat so you're saying the solution is Flutter? :D

@Zhuinden, noooooooooo This Flutter and this Java is for noooobs man! Android is now a mature platform and what's more, it's already a Copy of Linux. Why are you killing the soul of Linux by not going full 100% development with C/C++. The modern C++11/13/17 has all kinds of features to write clean elegant code, asynchronous ops, lambda functions, memory-management, and what not. Above all, high performance native-code is generated by compilers. First they got sucked into the Blackhole of Java, and now they think that Kotlin is the answer. It still compiles to bloody Java byte-code and the native code support is relatively new. It just sounds very rhetorical when they say switch to Kotlin, look it's nice, it can do operator-overloading??? Great If they switch to C++ and just kill all the non-sense of other languages and let Android work like a true Linux/Unix. You can easily do the sandboxing of Apps with your dockers or kubernettes instead of the JVM. In short get out of the byte-code hell, and turn to existing C++ frameworks to build all kinds of things.

The problem is that, as was said in this presentation, Android is constantly evolving, and at a fast pace. Nobody knows what will the future trends and paradigms of Android programming be. Most of the things which are now deprecated, were the best solution that was present at the time, it's just that the time has changed, and new times require new solutions. Personally, I agree with that, since it would be even worse to have the same outdated APIs forever. Just look at the manual SQLite database management vs Room AC. The APIs for SQLite management that were present since probably API 1, were the best thing you could do for persistent storage at the time. However, ten years later, Room library was created, which makes persistent storage much more easier to implement, so manual management is mostly deprecated now. However, nobody in 2007 was thinking that "SQLite API is a lie", because the solution was really the best thing you could do at the time, and nobody could predict Room. Things change, things become obsolete, you should never stop adapting and learning new things.

try IOS, they change everything and force you to use the new things. Google has more respect than we think.

lol what a drama king they're doing the best they can. They just don't hide the fact that they needed to improve a lot. And ofc one needs to improve a lot when you need to create a whole damn new platform, don't u think. dont @ me

The one that does not allow null at all

@@GakisStylianos It allows null it just forces you to check it all the time or declare it. I really don't get this non null complexity. It's not the significant and common error i run into.

@@llothar68 I know. What I meant is that you should optimally just go for a non-null value in the first place. And saying that "I don't commonly run into this error" does not change the fact that null is a problem that people encounter on a daily basis and is a source of a significant percentage of errors apps have, very often.

var country = null

Hahaha

Eh, Kotlin is like Java with some different keywords (val instead of final [type], fun, void is now Unit), but once you watch some videos by Jake Wharton it starts making sense. See academy.realm.io/posts/kau-jake-wharton-testing-robots/ but of course in Kotlin there are some niceties for removing some duplication like apply, let, run, etc. AAC makes sense, only thing that could be trouble is that scoping a ViewModel to a subscope of Activity but to multiple Fragments is hard.

Easier than Java.

Zhuinden Ohk will see.. However got very little time to apt with KT when a project is due 2 months. I mean it is not impossible however if something does not work I have no way to find out without a good grip on the language used.. like Java

Jeong-hun Sin Yeah i have seen a snippet where the getter setter class can be created in just 1 line.. However KT demands to throw a maximum concept we have been practicing for years now.. quick question: how long have you been developing apps using Java?

I do not understand what "throw a maximum concept", but to me it feels kind of a hybrid of C# (which I have used for more than 10 years) and Swift (which I had self-studied a little bit before using Kotlin), so it was not that difficult to start. I did not study much to start Kotlin. Just watched a simple video and then I learnt as I used it. The IDE teaches me by suggesting a better code for what I have typed. Also, if I do not know how to do things in Kotlin, I just wrote Java code and used the IDE's auto-conversion feature. I used Java for Android for about a year or so.

Don't just learn how to do things, learn the inspiration as well. How this will help you is: - You won't need someone else to tell you "hey this isn't how we should be doing this thing, this is how..." - Instead, you will know what comprises were made in the doing of things before and the conditions which will make those bugs surface up. This way, you will be doing things the right way even before the next API comes.