Jake Wharton
Jake Wharton
It's because we deploy the Gradle plugin and its dependencies to a repository-local maven repository for use by the test fixtures. I'm not sure we can meaningfully separate deployment to...
The Wire repo has the same setup. It uses the Gradle test runner's `withPluginClasspath` option to avoid this local deploy. I strongly prefer the local deploy option because it more...
This could be the fix: https://docs.gradle.org/current/userguide/publishing_customization.html#sec:publishing_maven:conditional_publishing
If we pass it through the non-config instance of activity then in memory would be sufficient for at least config changes, but not process death from things like memory pressure.
I'm really hesitant about a file-based (or any persistent) store because the structure is guaranteed to not be persisted across app updates. So seems like we need to write the...
https://kotlinlang.org/docs/native-memory-manager.html#enable-garbage-collection-manually
For JS we could do https://stackoverflow.com/a/3034245/132047. We are currently using Chromium for tests, but desire to switch to Node.js, in which case it's still V8 so basically the same thing...
Still want to do: - [ ] RedwoodView / TreehouseView - [ ] WidgetSystem
- [ ] child views after code reload
This will also exercise the host-side JVM treehouse artifact we've always had but weren't aware existed.