architecture-components-samples VS accompanist

https://github.com/android/architecture-components-samples/ was historically better

uh, maybe https://github.com/android/architecture-components-samples/tree/a87535608564103423415baddb1e586f0337be44/LiveDataSample/app/src/main/java/com/android/example/livedatabuilder

But Google invented a set of guidelines in "Guide to App Architecture" in 2017 which you can see here in action that after the re-org the new devrels didn't really understand so they ended up making their own version of "clean architecture" where the data layer depends on the domain layer and not vice versa, + never learned how top-level layering like this doesn't even scale ever and they should be creating components, not "layers".

5.) check the https://github.com/android/architecture-components-samples/ repo for samples (if it is a Google library, and only for some things)

When I take the advanced navigation project and update it's dependency to navigation 2.4.0 we get the working backstack as shown here.

That's still an issue .

Hey guys, Im trying to recognise more about api calls in a contemporary architecture. I am using retrofit with livedata/coroutines to make my api calls, but I'm struggling with error handling. Most of the solutions I find, even in googles own example, includes writing a wrapper around your api request and handle the error that. It seems overly complicated and frankly stupid to do something like that for, what I consider at least, rudimentary functionality. Even with Dart/Flutter, google has made this easy ‏‏‎ with async/await and Futures. Am I being lazy to think that if even google needs to write extra code to solve a common use case, they should probably add it to the framework? I dont know, maybe I just needed venting.. what do you think? google's project: https://github.com/android/architecture-components-samples/tree/master/GithubBrowserSample

/uj if you're reeeeaaaalyyyy interested, I found them here lol

The truly disheartening part is that whenever you choose something that works, for example ViewPager1, you need to defend that yes, this thing actually works as intended, yes, there's nothing in it that would "break over time" just because Googlers added the @Deprecated on it, and yes, you still don't want to use Compost for this because you still cannot scroll vertically in a horizontal Pager if your view is a WebView.

Compose on the other hand came out half-baked, significant performance issues, missing features, bugs and bugs and bugs and bugs and bugs and bugs and bugs and bugs and bugs.

Just to add to the list, Accompanist is a collection of compose libraries that helps a lot with some features. I can recommend Navigation-Animationand Permissions. https://github.com/google/accompanist

To give a bit of context, libraries not released as Jetpack libraries as experiment projects. Once they're released as Jetpack libraries, we have stricter release schedule in place and more resources to provide better stability for developers. That's why some Accompanist libraries end up as part of Compose foundation set, while others are still being shipped as part of the Accompanist project.

So you're going to get support for Parcelables in argument passing, animation support without having to fear crashes, and if you drink the ScopedServices koolaid you even get to get DI with lifecycle management and scope inheritance.

Here's a fun bug though https://github.com/google/accompanist/issues/1233

There is a bug the preview is not working when System UI controller is used. See issue tracker here.

👋 I have been using Mobius personally and for work for over two years now. It's a lot of fun to use and I would definitely recommend the community to consider using it. I frequently visit their GitHub repo because they still have their documentation in the GitHub wiki, unlike new repos such as Accompanist. So, I thought what better way to give back than do the grunt work of porting their wiki to GitHub Pages + MkDocs ❤️🔥

Accompanist for unofficial stuff that's still useful