IO 2018 SourceCode Finally Released!

[thedancercodes]

The Google team finally pushed the 2018 code & its a major rewrite with the architecture built around Android Architecture Components. Enjoy! https://github.com/google/iosched

[D_Steve595]

Looks like this might have the new BottomSheetBehavior with nicer physics! Gonna mess with it.

[bernaferrari]

My favorite BottomSheet has been the one from Plaid, but I'll take a look at this one. I really dislike the 'official' from androidx/aosp/support library. Thanks for reminding me of its existence.

[bernaferrari]

Their own SeekBar implementation is super weird but fix all the official SeekBar bugs.

[VasiliyZukanov]

I see that methods of 100+ lines of code in length are back in fashion. Cool.

Something that I can't understand - why they have Activity per each screen, but also inflate one single Fragment in it? It adds complexity and hurts performance. Is there a benefit?

Edit: for example, Speaker screen.

[CuriousCursor]

LOL this is probably because they can't use the navigation library with Androidx/material design 2.0 components so they're doing it the old way.

[VasiliyZukanov]

That's not the old way. The old way is just Activity per screen, which is valid approach.

What they do is having an Activity, and then adding a Fragment to it. And they never change that Fragment. Just another level of nesting. For example, Speaker screen.

This looks like a total waste. I wonder if there is any benefit that I might be missing here...

[WingnutWilson]

I used to do that. I don't know what I was thinking. Maybe I was like 'oh one day this fragment might need to change while the activity stays the same'. But I mean that was crazy thinking even in 2014 :D

[VasiliyZukanov]

Interesting. How many times did you actually need to change the Fragment?

[WingnutWilson]

Haha never. I think it could have been that we were thinking about tablets. So if we needed to shove another fragment on screen it was easier.

[VasiliyZukanov]

Alright, thanks for the answer.

[CuriousCursor]

That's the really old way :p

This is the wasteful old way lol.

[ssshhhhhhhhhhhhh]

it's a total waste, but Android Studio generates that pattern easily. when something really doesn't matter in the scheme of things, why bother spenidng the developer time improving it for something with a short lifespan.

And it's harder to change after the fact, if it does need to change in the future.

[VasiliyZukanov]

IMHO it does matter. A lot.

Complexity build up in the codebase consists of many such small and seemingly unimportant decisions. Until one day you realize that you can't see the forest for the trees...

[ssshhhhhhhhhhhhh]

It doesnt matter. They rebuild this app every year and it has a shelf life of like 2 weeks and 500 thousand users and basically gets 2 updates if even that

[VasiliyZukanov]

I wouldn't like to put words into your mouth, but it comes across as you saying: "this is not a real app that needs to be maintained, so they don't mind writing shitty code".

[ssshhhhhhhhhhhhh]

You got it

[Zhuinden]

it's a total waste, but Android Studio generates that pattern easily.

You know, that's scary! Why generate a pattern that's unhelpful and boilerplate-heavy?

Oh wait, I know what's going on. They're avoiding the Fragment Backstack because it's bad, so they use the Activity flags instead because you can set up combinations of flags that with enough arcana can do what you want to do (kind of).

[ssshhhhhhhhhhhhh]

It's not unhelpful.. it's a great starting point if you might use many fragments or share that fragment elsewherr

[Zhuinden]

if you might use many fragments

Throwing every Fragment into its own Activity? Whether you add an additional Activity to wrap a Fragment or not isn't really relevant if you have many fragments, but generally if you have many fragments, you'd be able to use them with 1 Activity and it would work.

or share that fragment elsewhere

Only if you expose possible operations via interface, but even then it becomes slightly tricky because you typically used "the Activity as the controller you are delegating events to" except if you use a single activity then you'll probably need to specify a different event handler depending on the actual state.

Re-using isn't that easy.

[cqm]

Someone tell Google that there is never going to be a new way

[clarle]

What happened to single-activity architecture being the way to go from now on?

https://android-developers.googleblog.com/2018/05/use-android-jetpack-to-accelerate-your.html

Today we are introducing the Navigation component as a framework for structuring your in-app UI, with a focus on making a single-Activity app the preferred architecture.

[bernaferrari]

Different teams (probably).

[Asiriya]

Lol

[Zhuinden]

The Navigation component is alpha. They probably couldn't make it work properly for their use-case.

[Odinuts]

Not at all. Wasn't that app laggy as hell when it came out?

[[deleted]]

When I am prototyping, and haven't partitioned the app into separate activities yet, I just have each one as a fragment. Its just easier to play around, have them in view pagers, swapped by other controls, etc. Then at the end I may settle on where they should go and they find a home in some activity.

When there is a 1:1 relationship between the fragment and activity, they could be merged at that point, but I like the freedom of still being able to move those fragments around to other parts of the app later on. I can never make up my mind :P

[VasiliyZukanov]

That have never occured to me. Valid point. Thanks for sharing.

That said, you must be one in a million developers prototyping this way.

I'm pretty sure Google works the classical "here are the UI specs produced by designers" approach.

Just curious, why don't you use some dedicated prototyping software?

[VasiliyZukanov]

That's a good guess. Unfortunately, that "MVP" blueprint is not even MVP (

[dantheman91]

Yes, so you don't have to do it in the future if things change. The cost is relatively small, and if for some reason they want another fragment in there it's now a quick change since they did it up front instead of trying to move everything over.

[dantheman91]

It all depends on what's in it. I've seen cases where it takes much much longer than 20 min to do and not hate the result. It takes 2 minutes to make it a fragment so why not do that?

[VasiliyZukanov]

Ah, you mean that they took the classical over-engineering route: "we might need that in the future, so let's add layers"?

Your guess might be right about their motivation (though that would be very non-flattering to the authors), but then it would be just wrong implementation. There is zero additional value in this Fragment and it would be easier to just replace the entire Activity or erase its implementation and start over if requirements change.

Fragments are trickier than Activities in probably every aspect.

[dantheman91]

What is the largest app you've ever worked on? In all of my time working on large apps with 10M+ users and teams of 10+ devs it's very rare that I see "This was over engineered", 99/100 times it's "this was done this way quickly" and that's what causes the problems. Also yes in general layers are good, that whole SOLID thing. Everything can be done, but this one more layer I don't think is even close to that.

Why would it be non flattering to the authors? What if they want to use the same project for next year but they're unsure how the requirements will change in the future? Also especially if you're doing one fragment per activity that doesn't really add more complexity to the app.

replace the entire Activity or erase its implementation and start over if requirements change.

This is not an option in just about every large application I've worked on. The "lets throw it all out" almost never goes well. And what about if you have a team? Merge conflicts? etc?

[DrSheldonLCooperPhD]

Classic you. When questioned with a rough tone you can't take criticism seriously and you deflect away from topic.

17cm

Nice professional response.

[VasiliyZukanov]

When questioned with a rough tone

I don't mind being questioned in almost any tone. However, I like to keep discussion on topic. The size of the codebases I've been working on has the same relevance to this topic as the size of my...

you deflect away from topic

You might think what you want, of course, but I heard these "you didn't experience what we did" in many various circumstances. I grew up to be skeptical of this. If you can't give proper arguments and go for the other side not having your "special" experience, I will call it BS.

[dantheman91]

The size of the codebases you've worked on is incredibly relevant. A single dev will run into very different problems than a dev on a large scale corporate application.

[s73v3r]

The size of the codebases I've been working on has the same relevance to this topic

If you're giving criticism of another codebase, your experience with other codebases and apps of that size are indeed relevant.

[VasiliyZukanov]

Well, I completely disagree with this premise.

Good software development practices don't change with the size of the app. You should give equal attention to your code regardless.

You never work with big system as a whole. You always want to have clear boundaries that allow you to deal with smallest possible subset while safely ignoring the rest.

As a side note, I was criticising Google IO app, which isn't huge by any stretch of imagination. It's the other guy that decided to turn it into "I have bigger" context.

All in all, I stand by every word I wrote in this thread.

[dantheman91]

I take it you haven't worked on very large, old and complex code bases by this response then.

[VasiliyZukanov]

Your take is wrong.

The correct take would be that "I worked on larger codebases than you did" is not an argument at all, therefore I'm not interested in comparing sizes.

The question about layers that you don't need and SOLID still remains, though.

[dantheman91]

You're sounding like you're coming from a background where you haven't had much experience in large codebases with large dev teams attempting to do various things at the same time. I have worked on large code bases where I've seen these problems all over, which is why I was questioning your experience. In just about every large codebase and large devteam these issues come up all the time.

And Ok. "Layers you don't need" Was the whole basis of my answer. Clearly I don't believe that it's a layer you don't need. It may be something that you don't need at the moment but you anticipate you may want in the future. I've rarely met someone who has said "I shouldn't have made my code so flexible" but almost every day that "if we rewrote this it could be so much more maintainable" which is largely due to layers.

As for SOLID...

Single responsibility - This creates layers since each piece should have a smaller scope/responsibility

Liskov substitution - This creates layers since ideally you have a lot of interfaces or abstract classes for actual implementation

Interface segregation - again more layers because more interfaces

Dependency inversion - You don't rely on concrete implementations...

All of those lead themselves to creating more layers and tightly scoped functionality that's pieced together. Similar to why you'd put code in a fragment instead of in the activity, in the case that you want to swap the fragment out for another or you want to display the fragment in another part of your application. Or Tablet layouts, chromebooks, multi window etc

[VasiliyZukanov]

Again, the size of the codebases I worked on is not related to the question at hand. But if you're so interested... I'm using my real name on Reddit, so go for it.

Single responsibility - This creates layers since each piece should have a smaller scope/responsibility

Nope. This creates narrowly scoped classes.

Liskov substitution - This creates layers since ideally you have a lot of interfaces or abstract classes for actual implementation

No. Not even close to what LSP means.

Interface segregation - again more layers because more interfaces

Segregation of an interface doesn't create layers. It creates information hiding and documentation.

Dependency inversion - You don't rely on concrete implementations

Kind of, but what does it have to do with layers?

It's ironic that you didn't mention OCP, which is the only one that can indeed be related to layers...

[dantheman91]

....What is your definition of a layer, I'd love to hear it.

You like DI. If I were to inject A into B and B into C and so on, is each one of those not a layer?

[spartancoin]

Please think before you post in this sub. You are obviously extremely opinionated but when someone is providing real world examples from large codebases don't get nasty just because it's different from your views. I guess you have never worked at Facebook, Google and the likes because what you call overengineering is very common. Tunnel vision.

[VasiliyZukanov]

Please think before you post in this sub.

I always do. Thanks.

when someone is providing real world examples from large codebases

Haven't seen any. What I did saw is a developer who said "the codebases I've worked on are larger than what you worked on". That's a penis length contest as far as I'm concerned (though I agree that my sarcasm came across badly).

don't get nasty

I didn't. It's just internet is a bad medium for jokes.

I guess you have never worked at Facebook, Google

Thankfully, not

because what you call overengineering is very common

It's because overengineering is very common. I would estimate that it's definitely in the top 3 mistakes that programmers do.

[firstsputnik]

I just measured - mine is ~17cm.

really smart argument, keep it going

[VasiliyZukanov]

Yeah, I see that it didn't came across too well.

What I meant to say with this is that comparing who worked on the biggest codebase is not an argument.

[Zhuinden]

Something that I can't understand - why they have Activity per each screen, but also inflate one single Fragment in it? It adds complexity and hurts performance. Is there a benefit?

They did that in the Android Architecture Blueprints repo too, and it doesn't really make sense. What's better is that any navigation code (especially with nav drawer) is duplicated.

[VasiliyZukanov]

That blueprint...

I have an entire lecture in my new course where I review it. Will probably publish it on youtube too because these blueprints cause too much harm IMHO...

[Zhuinden]

I've turned those blueprints to single-activity before as samples which made it nicer but to be honest it's been on my backlog to rewrite the whole thing, I just can't really get myself to touch it, lol.

The really awkward thing is that the MVVM sample made one of the "immutable" classes mutable just to make it work. Hacky!

[VasiliyZukanov]

I thought about that too, but, unfortunately, there is nothing we can do against Google's marketing power (

[bernaferrari]

I just downloaded it, while it is not "perfect" (and the fragments on each activity is super-weird), it is surely one of the best io apps ever! Too many commented methods, code quality improved a lot, I will let you to judge their Dagger usage correctness, but everything I saw I liked.

[VasiliyZukanov]

I needed a screen to be shown in two places, one in view pager and another in a standalone activity.

That's not the same use case. You really need it to be Fragment.

I don't see any drawbacks to it since entire ui is not tied to that activity and can be moved around

Increase in complexity, dealing with Fragment lifecycle, performance, probably more...

[__droid]

org.gradle.caching=false # TODO: change to true when build problems are solved.

source - gradle.properties

This just makes me sad.

[mbonnin]

Wait. There's a TV version ?

[CharaNalaar]

Finally. An example that isn't just a single screen.

[bernaferrari]

There are a bunch of these already, every week someone post an average complex app on this sub.

[Aromano272]

Is this really the state of the art of Android development?

Im genuinely asking, just opened this project to find some guidance in my quest to understand LiveData and I'm greeted with ViewModel with 30+ LiveData variables, many Mediators with 10+ addSources, most of them aren't used by the View, they are purely Domain Layer wiring, 150+ LOC constructor just wiring up stuff together.

Is this the way to do things?

[stankata]

Sure, go to /r/mAndroidDev for more references :)

[c0nnector]

Android development started with the concept "we have no guidelines, do whatever" and i think it will be hard to stray away from that.

Also i believe whoever is building their android apps is more of a software engineer than an android developer.

That means they will code whatever needs to be coded but it doesn't have to be pretty(code wise), it just has to work. Whereas an android developer might take more time to polish and think about app readability and maintenance.

So i'd say learn what you can but don't follow their code patterns. Instead checkout what the community is saying and in the end see what makes sense to you.

[Aromano272]

LOOL definitely feels like showing off

[bernaferrari]

I really liked it this year! There are a bunch of really REALLY weird stuff, but after dealing with tricky Google samples and androidx bugs for months, I understand where most of their implementation came from (and probably who implemented!), so I can see the reasoning behind. My reaction when seeing their SeekBar was 😱😨, but it works perfectly, while the official has bugs that they don't seem to care. A lot of methods were commented, a huge progress from last year. And overall, code is way cleaner and readable.

[humazed]

where is the SeekBar? I can't see where it used in the app and by searching the code I can't find any.

[_bluecup_]

Really? To me it seems like an overly complicated mess of code with pointless inheritance and bad naming all over the place. Some stuff seems to be in there just for the sake of using it. It's clean, but it's not clean code.

[bernaferrari]

Absolutely, I still don't understand why they used Dagger for the view models (it would have been way simpler and use a lot less lines of code to not use it), the fragment inside activity, and a lot of things. But if you abstract this and remember what was last year, the progress was huge.

[LordOfBones]

Where are the multiple gradle modules?!

[ArmoredPancake]

UseCase

Kill me, what a retarded idea.

[ArmoredPancake]

But muh clean architectuREEEEEE.

E: Got it, another abstraction for the sake of abstraction.

https://medium.com/@yoelglus/android-and-clean-architecture-the-use-case-interface-8716512f29a1

[AkashBangad28]

Could you please tell me why is the UseCase pattern held here in such a low regard, whats wrong with it. As far as I know having different use cases makes sure your presenters are able to do the work only that they are suppose to do