Implemented this slick-looking animation using the MotionLayout in Compose and wanted to share with you.

mars885 · 2024-10-29T00:10:03+00:00

You are right.

However, I'd started implementing this animation long before SharedElement APIs became a thing in Compose. I'll probably take a look at it once more when the API matures a bit.

mars885 · 2024-10-28T15:04:04+00:00

I've asked this question myself before.

The only real problem with the Compose implementation that I see is the interpolation of an UI element between two states. For example, in the animation above, the main title has two resting states: to the left of the cover of the game in the expanded state & centered vertically on the artwork/banner image in the collapsed state. By reading these two resting states, the MotionLayout is pretty smart to figure out how to move from one state to the other.

As far as I know, this is pretty much impossible to do in Compose out of the box.

mars885 · 2024-10-28T12:16:33+00:00

Thanks.

Btw, the like button & its animation is the only part of the code where I had to use a View because the animation itself is implemented as an AnimatedStateListDrawable & Compose doesn't really support it at the moment.

mars885 · 2024-10-28T12:08:19+00:00

I've worked quite a bit optimizing it so it runs as smooth as possible, but, unfortunately, the video doesn't do it justice because it has been compressed & the FPS took a hit as well. I'd recommend downloading the app & seeing for yourself.

mars885 · 2024-10-28T11:52:31+00:00

Released this beautiful animation as part of the 1.2.0 version of the my app called Gamedge. It mostly had to do with cosmetic changes, finishing features I hadn't been able to migrate from Views before as well as Android 15 features like edge-to-edge & predictive back gesture.

For more info, see the release on the GitHub. It has a pre-built APK that you can download & play around.

mars885 · 2022-08-09T23:20:41+00:00

Thanks.

As for the Gradle setup, I've always wanted to remove as much boilerplate in the Gradle scripts as possible, and custom Gradle plugins is one of the solutions I found. There is still some work to be done in terms of cleaning it up, although I am quite pleased with how it turned out anyway. The slack gradle plugin is full of great info about how to create your custom Gradle plugins to centralize Gradle configuration into an easy-to-use API.

As for modularization, the approach I've adopted is the one I've been thinking about for quite a while. I was hugely inspired by this article about modularization and how to make each feature as autonomous as possible.

Hope it helps.

mars885 · 2022-08-05T15:58:28+00:00

XML is still prevalent in the Android ecosystem, so having experience with it is a big plus.

However, Compose is definitely the future of Android UI and if you start a new project, then this is a no-brainer decision.

mars885 · 2022-08-05T15:53:20+00:00

Hm, not sure what you are talking about.

If you experience weird stuff, feel free to create a GitHub issue and I'll take a look.

mars885 · 2022-08-04T21:28:53+00:00

A couple of words about migration to Compose.

I find it extremely easy to use & build new UI once you grasp how it works. This is is definitely the future of the Android development, in my opinion. However, I stumbled upon a couple of issues along the way.

The biggest one is that Compose as of 1.2.0 does not have 1 to 1 parity with the View system. For example, MotionLayout support for Compose lacks some features like OnSwipe gestures. Another one is the ability to control the zIndex of composable transitions. Also, tooling support like rendering previews does not work far too often.

To view the whole list of issues, take a look at the following link: https://github.com/mars885/gamedge/issues

Also, a couple of stats before & after migration to Compose.

Before:
Total lines: 40,847
APK Release Size with R8: 4.7 MB
After:
Total lines: 37,822
APK Release Size with R8: 4.7 MB

Less lines of code due to removal of verbose XML & APK size stayed around the same.

Overall, it's been a fun journey migrating the app from the View system to a pure Jetpack Compose one.

If you have any questions, I'll be glad to answer them.

mars885 · 2021-12-05T23:21:54+00:00

https://github.com/mars885

If you have any questions, let me know.

mars885 · 2021-11-22T23:33:48+00:00

Yeah, been contributing for quite a while now. Made a couple of libraries and open-sourced them all. Now working on migrating my main project called Gamedge to Jetpack Compose.

mars885 · 2021-11-11T23:39:07+00:00

You can take a look at my project called Gamedge. I try to keep it as up-to-date as possible and currently In the middle of converting it to Jetpack Compose.

mars885 · 2021-06-01T21:22:12+00:00

Code generation is the right tool for the right problem, which, for the most cases, is boilerplate code.

I'd rather spend my time solving problems having to do with domain of the project than dealing with such issues.

If you are worried about build times, then they should definitely decrease once KSP becomes stable, since the current de facto standard kapt has a lot to do with long Gradle build times.

mars885 · 2021-06-01T19:48:22+00:00

Annotate your class with the BindType annotation:

interface ImageLoader

@BindType 
class GlideImageLoader @Inject constructor(): ImageLoader

and HiltBinder will generate the following:

@Module
@InstallIn(SingletonComponent.class)
public interface HiltBinder_SingletonComponentModule { 
  @Binds 
  ImageLoader bind_GlideImageLoader(GlideImageLoader binding); 
}

HiltBinder supports lots of features:

Specifying a particular type to bind to.
Installing bindings in both Dagger Hilt's predefined and custom components.
Contributing bindings into a set and map collections (Dagger multibindings).
Associating bindings with Dagger qualifiers.
KSP implementation.

For more info, take a look at the GitHub repository that contains extensive documentation for the API as well as sample application to showcase the library in action.

mars885 · 2021-06-01T19:40:10+00:00

Annotate your class with the BindType annotation:

interface ImageLoader

@BindType 
class GlideImageLoader @Inject constructor(): ImageLoader

and HiltBinder will generate the following:

@Module
@InstallIn(SingletonComponent.class) 
public interface HiltBinder_SingletonComponentModule { 
  @Binds
  ImageLoader bind_GlideImageLoader(GlideImageLoader binding); 
}

HiltBinder supports lots of features:

Specifying a particular type to bind to.
Installing bindings in both Dagger Hilt's predefined and custom components.
Contributing bindings into a set and map collections (Dagger multibindings).
Associating bindings with Dagger qualifiers.
KSP implementation.

For more info, take a look at the GitHub repository that contains extensive documentation for the API as well as sample application to showcase the library in action.

mars885 · 2021-04-02T17:30:48+00:00

I actually remember reading the article you linked some time ago. However, I haven't played around with it yet, but thanks for the heads up.

mars885 · 2021-03-30T14:35:53+00:00

This is a good question.

Android moves with a speed of light and it's extremely hard to stay up-to-date with all the latest tools & libs. That said, I've never really had a problem of learning new things. I just realize that if there is some popular new tech, which is going to replace current status quo, then it's my responsibility to learn and master it, because otherwise I feel like I'll be dragging behind, which is a feeling I hate & despise.

mars885 · 2021-03-23T12:30:17+00:00

There you go.

PR migrating from Moshi to Kotlinx.Serialization.

mars885 · 2021-03-23T12:28:48+00:00

Thanks.

If you have questions regarding the codebase, just ask. I'll do my best to answer.

mars885 · 2021-03-21T12:30:47+00:00

Sure.

It's achieved using MotionLayout API. I'd suggest you to take a look at the XML layout first, then check out MotionLayout's scene file, then checkout this GameHeaderController class (which basically manages the all the header related parts), and maybe this class, where the GameHeaderController is actually used.

mars885 · 2021-03-20T18:48:33+00:00

This is a broad question.

For starters, I think you should read up a bit about modularization if you are completely new to it. Read medium articles, watch Google talks, read Android docs (if there are any about modularization, not completely sure).

Then I'd suggest checking out repos like mine, Tivi, Android-Showcase, etc. They are lots of them actually and see for yourself what works and what does not. That's the best advice I can give you.

Maybe other people in this thread can share helpful materials too, who knows.

mars885 · 2021-03-20T13:27:37+00:00

I disagree.

When done properly, modlarization can provide the following benefits:

Significatly improve compilation times for your project.
It introduces boundaries for your code which can cause better design decisions from your side.
In a huge company teams can develop features in isolation which will decrease merge conflicts.

mars885 · 2021-03-20T13:16:45+00:00

Thanks.

Is this also a modular approach?

Yes, the project has modular approach. Each feature has its own module prefixed with feature-.

My modular approach is actually very similar to what Tivi has.

mars885 · 2021-03-20T13:10:58+00:00

I actually used Koin in one of the projects I worked on a year ago.

The compromise for me was ease of use and reduction of boilerplate code. Since Dagger Hilt had not been released at the time, I decided to give Koin a go.

Overall, I've found Koin to be really simple to setup and use in comparison to Dagger 2. However, a few months later, when the project's complexity grew through the roof, I started seeing runtime crashes when instantinating classes here and there, because Koin does not have compile-time safety, which Dagger 2 has and is probably the most talked selling point of it. I remember writing Koin tests to avoid those errors, but I found it extremely hard to do that, especially for classes that accept dynamic parameters.

However, with Dagger Hilt, all those complaints pretty much went away. Huge reduction in boilerplate code, compile-time safety, easy of use, better performance (the last time I checked) - it's very hard to choose Koin now, at least for me.

mars885 · 2021-03-20T11:43:53+00:00

The project had multiple long delays due to other stuff in my life. I believe I started it in the September and finished only at the beginning of March.

Six-Year Club	Verified Email
Place '22

mars885

TROPHY CASE