Protips: A fresh look at advanced topics for Android experts (Google I/O '18)

[@igrecha]

Each time I listen to Reto's or some other googlers' talks I'm impressed, how far they are from the real world of Android development. Many of the things that Android SDK gives us, are unusable sources of boilerplate code, giving same problems each time you use them, and keeping all the bugs not fixed till they become officially deprecated. We do keep in mind that official code guidelines != best practices.

[@AleksandarStefanovic]

Can you give an example?

[@TechYourChance]

Was this talk intended as some kind of parody that flew over my head? No protips here, no advanced topics and, surely, nothing for experienced Android developers (let alone "experts"). It's sad to see that after all these years googlers still don't know what it takes to develop a real Android app and where the real challenges lie. However, this is a nice summary of failing Android APIs over the years.

[@Zhuinden]

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.

[@typingcat]

Hmm, I agree as well; shallow and pedantic.

[@meow75714]

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

[@Zhuinden]

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

[@meow75714]

@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.

[@stantoniification]

Nice summary of how things have changed, and what is current recommended best practice. Thanks Google :)

[@renascienza.bazarclub]

To be fair, in about 10 years of Android development, I just wrote a single one Content provider (because I needed share data with external apps, and... This worked, but also wasn't great) In all my other projects rely on anything else that 3rd parties APIs could give me. Ever hated loaders, hated even more the CPs. Today Room is so better, but I'm don't like SQLite anyway. So a better way to use it don't exactly raise a green flag. SQL was created as an interchangeable data language to access different RDBMs at same way, and across platforms and networks. Why I need to use it to access the same instance of the same database type everytime? Makes no sense. Only because there is a culture of devs that like SQL? "Oh, but SQL give me performance to access terabytes of data" You store terabytes of data on a single mobile device? Technology need to be oriented by the problems to solve, not the whims or skillset of the one who solves them. We don't need to use SQL inside mobile apps.

[@Zhuinden]

26:44 nothing is straightforward about (0, null), (_, _, null, _, null, null) --- it is really nice that AAC kills all this mess.. although this is exactly what the talk says, so that is good

[@OkuhleNgada]

I love this guy's sense of humor... he even knows about having the receipts!

[@yoavtamir7707]

The jokes were nice but too much time spent on them...

[@typingcat]

That's the joke...

[@anonimo0486]

How many years until we're told again: "Sorry guys AAC was another lie". I love mobile development, but I think Google has absolutely no respect for us. Instead of focusing on 2 or more alternative technologies (Android, Flutter,PWAs,etc) at the same time, they should concentrate on improving the whole Android platform, making it reliable. Not something that is sold as the best technology ever now, only to be discarded the following year.

[@AleksandarStefanovic]

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.

[@itcrespo]

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

[@70ME3E]

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

[@jamesmiths72]

Thanks for the video. I found it helpfull to see things in context

[@renascienza.bazarclub]

I can predict that next year, LiveData will be completely deprecated in favor of flows, a better approach.

[@azizbekrasulmetov9293]

Hahaha

[@LiranBarsisa]

11:19 This is not quite true. You can't replace all system events with job schedulers.

[@b.k4142]

My question if i focus mastering jetpack framwork for few month is good things? i m learning android for 1 year? thanks

[@janjuvan7845]

Watched 10 mins to get to something barely recognizable as content.

[@igorg.8624]

He said it: "we are encouraging you to use Kotlin as your primary development language for Android!"

[@adforknowledge6582]

Yah 9 mins passed and no actual technology related talk..!!! :D :) But I loved the way he is presenting..!! :) I loved the humor way better than all the boring talks and boring way of presentation in google I/O

[@martinseal1987]

This was really eye opening

[@NeedforSpeedGamesforpc]

The kotlin is certainly not easier to switch for me as a java developer. Most of the things made no sense and wastes more time: var country: String? = null String country = null now which one is easier to write?

[@GakisStylianos]

The one that does not allow null at all

[@llothar68]

@@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.

[@GakisStylianos]

@@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.

[@kemel-7000]

var country = null

[@codinginflow]

Lol I didn't know this guy is so funny

[@witoldsienski1709]

Nice fresh look for Android but these news are not for experts :P

[@lucaaliberti4597]

Ok, watch last 5 minutes only.

[@OxzimO]

Funny talk as always from Reto Meier

[@yogeshkurane123]

How the heck does developers find kotlin easy? There is whole set of new methodology say architecture component to study.. upon that is entirely new codebase kotlin. Years down the lane they will say "it (architecture components) was a complete lie" too

[@Zhuinden]

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.

[@typingcat]

Easier than Java.

[@yogeshkurane123]

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

[@yogeshkurane123]

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?

[@typingcat]

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.

[@trocchiettoski]

who is better and know more things? Him or JW?

[@i_rajput_sachin]

awesome

[@thumbwit]

Rockstar

[@typingcat]

Damn birds.

[@chrislagos44]

And the reason for this...and this is how we did it back in kitkat...we need solutions not history or reasons..get to the point man

[@abhishekabk5]

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.

[@ayoubanbara1685]

خليو لينا جافا بالرجولة مادارت ليكم والو مسكينة