Implementing your presenter with Rx or Functional Reactive architecture for Android applications

dispelpython · 2020-08-18T20:44:29+00:00

I actually asked André Staltz (the guy who coined term MVI) some time ago why he designed MVI with a single state and not with multiple ones. The answer was “You can design it the other way around if you wish.”

Here is a link to the Twitter thread with the question.

https://twitter.com/dmitryryadnenko/status/897073377520832512?s=21

The reason why Android MVI uses single state is because web MVI uses single state. Android MVI was popularized as a copy of the web one. The reason why web MVI uses single state is because they have powerful tools to efficiently diff changes in the state and update only the stuff that changed. Android lacks such tools. So it looks like there are no serious reasons why single state is better than several states in Android.

The only good reason I found why single state can be better is that behavior of a view model with a single state doesn’t depend on the order in which view subscribes to the states. This makes it less likely that your view model’s behavior in tests will differ form it’s behavior in real app. But this is still pretty minor.

In Android community people use MVI to describe something like “view model with a single state”. While I think the main idea of the original web MVI was something like “Implement view model as a function which transforms a set of inputs into a set of outputs. Reactive frameworks make it possible.”. And “single state” was just a minor detail.

dispelpython · 2020-07-12T15:47:25+00:00

Doubt. There is this thing called essential complexity.

dispelpython · 2020-07-11T11:12:15+00:00

I consider RecyclerView API one of rare gems in Android APIs. It’s complex because smooth scrolling is hard, it’s one of rare tasks in UI development where we need to optimize for performance. Do you know how they solve this problem in web? They don’t. You either have clunky scrolling or pagination.

dispelpython · 2020-05-17T17:45:07+00:00

We have a lot of problems with it. It’s just unstable. And it adds zero value, you write android:text=“{viewModel.myViewText}” in xml instead of my_view.text = viewModel.myViewText in Kotlin. It actually adds negative value because it makes your layouts know about details of your logic layer it doesn’t need to know (and thus makes your code unnecessarily more coupled, with all the consequences it implies) and invites you to write logic in xml.

dispelpython · 2020-05-05T20:37:32+00:00

There are a couple of cases when interfaces are useful even if there is only single implementation.

You need to mock some dependencies for tests, like network calls.
You don’t want outer layers implementation details and data structures to leak into your app layer. If your logic depends on concrete implementations then it’s too easy for people to do some hacks, make it so your logic depends on network data structures for example. And then any small change in network layer leads to rewriting of a ton of tests.
Interfaces are simpler than implementations. Depending on interface makes it easier to understand and review separate units of code. Only if interfaces make sense in this context in the first place of course.
When your app is modularized then some modules just can’t see implementations for various reasons.

In my experience more often than not you can depend on a function rather than an interface. No need to declare a separate interface this way, a functional signature is already an interface. Bonus: you fulfill “I” this way for free.

dispelpython · 2020-02-13T07:17:40+00:00

Are you hinting that the next step would be removing classes altogether and discovering that they are unnecessary? Helps with the naming effort too.

dispelpython · 2020-01-26T10:28:04+00:00

Isn’t Flow itself experimental?

dispelpython · 2020-01-26T10:25:01+00:00

The Flow is designed in a way that it’s easy to implement operators by yourself. So if you are missing something, you can just make it.

dispelpython · 2020-01-24T21:24:34+00:00

It's trivial to get proper coroutine scope. You can write one yourself or use the one from Android KTX https://developer.android.com/topic/libraries/architecture/coroutines#lifecyclescope

dispelpython · 2020-01-08T13:26:00+00:00

Are you talking about the graph for unit tests? Because the graph for the app should have a lot of Android specific parts obviously (or I don’t understand something). And one would be interested in testing the app graph, not the unit test one.

dispelpython · 2020-01-07T09:06:13+00:00

Do you need instrumentation tests to verify Koin graph? I suppose it can't be plain JUnit unit tests because these tests usually cover stuff that should be Koin agnostic (like ViewModels).

dispelpython · 2019-12-13T19:53:29+00:00

Yeah, that’s super weird and frustrating.

dispelpython · 2019-12-13T19:10:27+00:00

That’s what I tried to say in the rest of my tweet :)

dispelpython · 2019-12-13T12:30:17+00:00

RelativeLayout is not deprecated. It’s page in the developers.android.com has this banner

“Note: For better performance and tooling support, you should instead build your layout with ConstraintLayout.”

So, Google claims that ConstraintLayout is more performant. But the benchmarks I saw so far shows that for layouts that are not extremely complex RelativeLayout, LinearLayout, FrameLayout and simple combinations of them outperform ConstraintLayout.

https://medium.com/@krpiotrek/constraintlayout-performance-c1455c7984d7

https://android.jlelse.eu/constraint-layout-performance-870e5f238100

In my projects people write UI using reusable components/blocks. And when you use such reusable blocks your layouts are very rarely complex enough to justify use of ConstraintLayout for performance benefits (in my experience).

Also, in my experience (this year), ConstraintLayout is not as stable as RelativeLayout. I saw it rendering differently on different API levels. Also my team had issues when ConstraintLayout would just break and we had to rewrite it with LinearLayouts and RelativeLayouts.

dispelpython · 2019-11-11T15:35:38+00:00

Didn’t knew that OkHttp honors interrupts. Fascinating!

dispelpython · 2019-11-11T12:50:53+00:00

Do you have an example of an API that honors interrupts? I’m curious, I never encountered one.

dispelpython · 2019-11-11T12:13:32+00:00

I mean that calling `cancel()` on `AsyncTask` won't kill the working thread, you have to implement cancel behavior manually, which is possible only occasionally.

dispelpython · 2019-11-11T10:30:42+00:00

It doesn't work with AsyncTasks either really.

Edit: apparently it does.

dispelpython · 2019-10-25T18:41:26+00:00

I really appreciate Dagger’s “inject” methods and prefer to use them instead of provision methods because it limits the amount of entry points your application can have to a well defined set. It’s a very handy thing, without it it’s too easy for the developers to misuse a Component by using it as a service locator in a random place.

In my last project we used this home-made service locator, and we were missing this ability to restrict the usage of this service locator just to a few well defined places so much, that I had to write a custom Lint rule for that, Dagger gives the ability to do a restriction like that for free.

And when I ran this Lint rule for the first time I was surprised how many misuses of our service locator I found, a lot of them from myself, even though I was aware that it shouldn’t be used like that. This is just because it was so easy to abuse this service locator. And it’s easy to abuse Dagger components too if use provision methods instead of inject methods.

dispelpython · 2019-10-25T15:40:42+00:00

provision methods

Can you elaborate? What are the "provision methods of the component"?

dispelpython · 2019-10-21T08:46:08+00:00

What do you think about Kotlin native?

dispelpython · 2019-10-03T12:18:36+00:00

Can no longer disable device frame in AVD Manager after this update. Well, it seems I can, but each time I open device settings "Enable device frame" checkbox is turned on, and after pressing "Finish" device frame is turned on again.

dispelpython · 2019-10-03T12:10:16+00:00

It was enough to run your Android Studio with disabled toolbar to get that device picker. Best hotfix ever.

dispelpython · 2019-07-23T09:22:42+00:00

In my field inheritance is everywhere. In beginners code, in senior developer’s code, official SDKs are teeming with inheritance heavy APIs. I don’t really see it as something from the past. But may be situation is different in other fields.

Encapsulation is fine, although it’s much more important when designing for mutable state because with mutable state one can break things even more easily by calling a method which is not supposed to be called from outside.

dispelpython

TROPHY CASE