[Emoji Search app] Sample is not working

[vikaspw]

I have run the Emoji search app , but changing compose view on Emoji Search on presenter logic is not reflecting on android/ios app ui. while server is running perfectly and able to detect changes, rebuild.
there is open issue - #1820 is it linked with this?
is it not stable library ?

[JakeWharton]

Yes, this behavior is tracked by that issue. You can comment-out the build.gradle line which declares the embedded application if you want to do hot reloading. There is no timeline on for the fix–it's in an upstream library so it's out of our control. This doesn't affect the behavior of release builds so it's not a huge priority.

[vikaspw]

@JakeWharton But without can't we use this library for production app, as it seems network cache also not working, it always making calls to server and fetching screen data..
any suggestion here?

[JakeWharton]

I don't believe we have a network cache setup for Emoji, as it's primarily a development sample. In our production app we only use a network cache. I will have to check tomorrow.

[vikaspw]

@JakeWharton Did you make performance comparison between using treehouse library and without treehouse library.
what is the overhead of using library?

[JakeWharton]

We have not, because nothing else really provides the capabilities that we're after.

Is Treehouse slower than just using native UI–absolutely. It always will be. We work really hard on making the performance the best it can be given the capabilities that we want to offer. Being able to deliver layout changes to millions of users in under an hour rather than it taking two weeks is worth a slight hit on performance. These also aren't our most performance-sensitive screens in the app–those are still entirely native.

[vikaspw]

What about network cache...is it not supported by zipline? Do we need to explicit set the cache control config?

…

On Thu, 12 Dec, 2024, 22:29 Jake Wharton, ***@***.***> wrote: We have not, because nothing else really provides the capabilities that we're after. Is Treehouse slower than just using native UI–absolutely. It *always* will be. We work really hard on making the performance the best it can be given the capabilities that we want to offer. Being able to deliver layout changes to millions of users in under an hour rather than it taking two weeks is worth a slight hit on performance. These also aren't our most performance-sensitive screens in the app–those are still entirely native. — Reply to this email directly, view it on GitHub <#2497 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BNJQBC6QTKQU2CXF6PWYYHT2FG6FLAVCNFSM6AAAAABTKW7QT6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMZZGUYTANJSGA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[JakeWharton]

You have to set it up for each platform, but it has a default that should make it work automatically.

Android: https://github.com/cashapp/redwood/blob/trunk/redwood-treehouse-host/src/androidMain/kotlin/app/cash/redwood/treehouse/treehouseAppFactoryAndroid.kt#L36-L37

iOS: https://github.com/cashapp/redwood/blob/trunk/redwood-treehouse-host/src/iosMain/kotlin/app/cash/redwood/treehouse/treehouseAppFactoryIos.kt#L33-L34

[vikaspw]

@JakeWharton We already have design system , can we use compose multiplatform directly without using redwood and getting advantage of update UI on the fly like server driven approach?
does protocol system work independently or we have to use redwood?

[JakeWharton]

You would have to define your design system in Redwood as a schema and create implementations of it for each platform. Redwood is generally designed for use with native UI, not cross-platform UI frameworks, although nothing would preclude you from implementing the design system interfaces once using multiplatform Compose UI. However then you would have to write all your screens using the Redwood composables and not Compose UI composables.

[vikaspw]

@JakeWharton So We have to use Redwood composable for dynamic behaviour, and for new widget/schema addition we have to dependent on play store release cycle?
in short we can't make independent screen on the fly (like replacing emoji schema with some other schema) but can make changes in existing widget..
Is my understanding correct?

[JakeWharton]

That is correct, yes.

[vikaspw]

@JakeWharton as you guys already shipped the cash app with tree house.. can you open source basic widget component of redwood composable like TextView, Button,Toolbar etc..
I hope you have developed these things already and will be helpful for us (not repeating the same thing)

[JakeWharton]

No, because it's specific to our design system and is not customizable. You can look at the basic schemas for our samples or the test app, and #2275 will offer a basic, blueprint-like set to experiment with. Part of the point is that we do not want to be prescriptive about how granular or coarse your design system schema is built. It's entirely up to you.