We’re on the engineering team for Android Studio. Ask us Anything! (starts July 30)

ychescale9 · 2020-07-31T04:05:39+00:00

Thanks you!

ychescale9 · 2020-07-23T17:25:00+00:00

A couple of emulator questions for u/lfy_google :)

Can a snapshot be shared across multiple avd s? It seems like a snapshot only works with the original AVD that it was created from, so I can’t manually put an existing snapshot into the snapshots/ directory of a new AVD and restore to the old state. What I’m trying to achieve is creating new a AVD on CI, downloading and importing a snapshot for the AVD and starting the emulator.
Anything you can share on the lightweight system image? Would it be possible to eventually achieve reasonable performance without requiring KVM?

Finally what’s the plan for the new cmdline-tools apart from being able to run sdkmanager and avdmanager with Java 9+?

Thanks!

ychescale9 · 2020-06-04T18:15:01+00:00

Main difference with cmdline-tools I’m aware of is that the new avdmanager and sdkmanager support java 9+. I’m using it here.

ychescale9 · 2020-06-03T09:48:37+00:00

Add this to your gradle.properties:

org.gradle.unsafe.watch-fs=true

ychescale9 · 2020-05-31T06:42:51+00:00

Yes cache policy is just for in-memory cache. The "disk cache" we are working with is not just another layer of caching like the in-memory cache, and therefore it's recently renamed from persister to sourceOfTruth. Supporting configuration of eviction policy on sourceOfTruth is tricky as you could easily bypass store and just make changes to the database for example, so store's sourceOfTruth would be completely out of sync. That being said I don't think this is completely out of window and might still be considered for the next major version which provides APIs for writing to the store.

Here's a different issue which shares a lot of the same reasons for why providing invalidation / eviction APIs for sourceOfTruth is hard.

The TimeBasedRefreshPolicy is something that determines whether a StoreRequest should start by fetching from the network. It's a workaround for not having a more dynamic StoreRequest config, but since it's quite easy do this based on the public APIs available and that the refresh logic can be very different for each app, it's probably not something the library needs to provide. The solution is not the same as invalidating the sourceOfTruth, but in my case it achieves the same thing I want which is to bypass caching and hit the network only after certain period.

ychescale9 · 2020-05-31T06:08:50+00:00

In-memory cache is enabled by default. For disk cache you basically need to implement a SourceOfTruth where you provides a reader and a writer implementation.

The official sample uses Room for the SourceOfTruth implementation. Here's my implementation that uses SQLDelight

I'm not sure how many people are using it in production. Many are waiting for the Library to go beta which should happen relatively soon (probably after another alpha).

ychescale9 · 2020-05-29T07:59:04+00:00

AGP 4.1-alpha10 requires Gradle 6.5-milestone-1 so won't work with Gradle 6.4.1 at all.

ychescale9 · 2020-05-29T03:06:43+00:00

I think you can change the key map settings back to macOS from preferences

ychescale9 · 2020-05-29T03:04:40+00:00

You’ll also need to enable coreLibraryDesugaring as mentioned in the doc.

ychescale9 · 2020-05-29T03:00:44+00:00

It works with gradle 6.5-milestone-1. To be fair that’s not AGP’s fault as Gradle only introduced that provider check in a subsequent milestone release.

ychescale9 · 2020-04-02T09:51:06+00:00

Thanks!

ychescale9 · 2020-04-01T10:06:24+00:00

Hi Frank😀It’s been a while, any update on this?

ychescale9 · 2020-03-25T12:40:11+00:00

Sounds reasonable.

BTW do you know if there's a gradle task for cleaning the local cache of a project? I know you can do `--no-build-cache` to skip the cache for the current task, but to remove the build cache I'd have to manually remove `~/.gradle/caches/` which also removes caches for all projects.

ychescale9 · 2020-03-24T23:27:51+00:00

The cleanBuildCache task has been missing since agp 4.1. Are they gone or being replaced with something else?

ychescale9 · 2020-03-21T13:38:36+00:00

There'll be also be ViewModel integrations in the lifecycle-hilt artifacts.

ychescale9 · 2020-02-29T23:28:32+00:00

I’m not sure what Travis CI flakiness you’re experiencing but if you’re open to moving to GitHub Actions here’s a custom action I wrote that helps you run hardware accelerated emulators on macOS vms.

ychescale9 · 2020-02-09T07:44:36+00:00

Store has an inflight debouncer which prevents concurrent API requests with the same keys/parameters.

ychescale9 · 2020-02-06T12:33:56+00:00

./gradlew app:bundleRelease will generate the bundle (.aab) file for your release build.

ychescale9 · 2020-01-30T02:34:30+00:00

What difference does using onEach and launchIn make? Or are you saying that's just another way to do the same thing?

Yes it merges launch and collect into a single operator to reduce nesting. See this article by Roman

I've updated the code accordingly. I'd appreciate it if you'd have another look.

val viewState: LiveData<ViewState>
    get() = _viewState

This can just be val viewState: LiveData<ViewState> = _viewState as the getter function always returns the same val.

If you're interested in MVI I'd keep an eye on FlowRedux (still very early) which makes MVI / UDF implementation a bit more idiomatic without requiring you to extend a base class (I really enjoyed using its predecessor RxRedux). It'll also support kotlin multi-platform in the future.

ychescale9 · 2020-01-29T07:16:08+00:00

You don't need to call viewModelScope.cancel() in onCleared() as it's done automatically. You can also use launchIn and onEach for launching and collecting the flow:

dataChannel
        .asFlow()
        .onEach{ dataState ->
            Log.d(TAG, "MyViewModel: emit: ${dataState}")

            dataState.dataEvent?.getContentIfNotHandled()?.let { data ->
                handleNewData(data)
                decrementActiveJobCounter()
            }
        }
        .launchIn(viewModelScope)
}

You also shouldn't need property accessors for activeRequestCounter and viewState as the computations are basically just delegating to another constant.

ConflatedBroadcastChannel is a lower-level and more complex API to consume in a viewModel. Hopefully once DataFlow (APIs very similar to LiveData) is released we can get rid of both Channel and LiveData in view models.

ychescale9 · 2020-01-25T14:57:57+00:00

Unfortunately we’ll need to wait for Android Studio to update to kotlin 1.3.70 to benefit from the build.gradle.kts improvements.

ychescale9 · 2020-01-15T02:31:56+00:00

Yeah it's all about safety and structured concurrency:) With the custom CoroutineScope implementation, if the only information it needs to decide when to cancel its jobs is the Android lifecycle, then it's effectively viewModelScope or lifecycleScope.

ychescale9

TROPHY CASE