lyft / domic Goto Github PK

It should do same stuff differently so we could profile it (systrace, etc) and compare implementations, right now I just modify sample app and profile that.

Right now I'm thinking about at least 4 options:

• Render changes directly on main thread
• Render changes that were computed off main thread and then posted to main thread
• Render changes that were computed on main thread with Domic
• Render changes that were computed off main thread with Domic

Please see this conversation: #33 (comment)

That'll reduce overhead of switchMap.

This is a tracking issue for discussions of the problem.

Problem

Android Framework is mutable (duh). Mostly it's fine, however some View/Widget properties can be updated by Framework/user, for example TextView/EditText.text or CompoundButton.checked.

Problem Example with CheckBox:

1. Developer sets checked to false via Domic
2. User of device clicks on it and effectively sets checked to true
3. Developer sets checked to false via Domic again

If Domic doesn't track state changed by user of the device (read as Android Framework), it will just dismiss the update because it compares it with internal in-memory state.

Solution

Current solution is to observe state of such properties and update internal in-memory state thus keeping Domic in sync with Android Framework.

Was discussed with lead of Android UI Framework Adam Powell

Since we pipe all changes through our model, we can expose API that can let user capture and apply captured state.

That can be helpful for state save/restore, reproducing UI from bug reports, etc.

Pointed out by @Tagakov

I wanted to avoid allocation of a func: (T) -> Unit, but failed to notice that I trade it off with inlining anonymous class instantiation to each call site which is not great

Function should not be inlined.

There is a common problem with async rendering: due to async data arrival and async switching to ui thread you're effectively skipping first frame.

In many cases it's not really a problem because it's very hard to notice one frame without data, especially if default layout state already displays something.

However in some cases like very different default state of the layout compared to the state with data (ie whole content is invisible by default, etc) it can be noticeable.

This GitHub issue tracks possible solutions and general discussion of this problem.

cc @alexjlockwood @kxfang

Also related to RxAndroid ReactiveX/RxAndroid#228

Android P introduces new api to pre-compute text layout metrics, so rendering can be done faster.

Since Domic is intended to be used off-main thread this seems like a good api to integrate with.

Docs: https://developer.android.com/reference/android/text/PrecomputedText
ADB Podcast episode where they discuss this api: https://androidbackstage.blogspot.com/2018/05/episode-90-spanspanspanspan.html

That should reduce synchronization and memory allocations.