and i guess the table’s data class constructor is what breaks

do you actually try to insert 256 values or are they all like computed stuff

Yes, the constructor is the problem. Unfortunately, I want to insert 300 double values which are not computed.

thats a lot

why are there so many

this is only a small log file 😄 only a subset of all available sensors. We get old data as csv, and new data from a stream. Both should be stored in a db. For csv batch import we use sql copy https://www.postgresql.org/docs/current/sql-copy.html. Problem is streaming import, as we need to create the dao class/or a use a method with all values. Or is there any workaround using multiple arrays? 😄

Yea I would just serialized all the data as like a single list or something

What do you mean? I cannot change the db schema, its provided and used by other systems

Ohhhhh

Hmmmmmm

I’m curious - what does the

MoleculePresenter

interface actually look like? The example given in your blog post doesn’t seem possible without generics:

class CounterPresenter @Inject constructor(
  private val randomService: RandomService,
) : MoleculePresenter {
  @Composable
  override fun Present(events: Flow<CounterEvent>) : CounterModel {
    // ...
  }
}

Yes it has generics. It's just an adapter to our generic presenter interface. It's actually an abstract class

A few questions about molecule: 1. You are using Compose for presentation logic, but aren’t using Compose for UI? Why is that? a. I ask that because it seems like molecule doesn’t have much use when you are already working with a Compose UI, right? 2. You mention in your blog post,

It's not ready for a 1.0 because there are some tradeoffs in how we're using Compose and in the shape of our APIs that we're not 100% sure are the right ones to make.

What are some of these tradeoffs that you are talking about?

We have 200 screens. Most are views. Some are Compose UI. Our architecture makes it not matter.

If you put your presenter logic in the render layer with Compose UI then yes you don't need Molecule. If you have clean separation then you'll be forced to not use Compose unless you use Molecule.

So then your UI layer isn’t responsible for instantiating your Presenter, and instead your UI layer is passed a

Flow<Model>

? Is there an example somewhere I could get an example of what you guys are doing?

The UI doesn't even get a Flow. It has a setModel function and that's it.

And no both the presenter and UI are instantiated separately and neither knows about the other

Is this using `Workflow`s?

No. We do not use Workflow on Cash.

to add some more context: our navigation layer handles binding of views with their presenters. by not letting views instantiate their presenter, it gives us more flexibility on how the view is rendered. it could be rendered using fake data inside snapshot tests or be given a "v2" presenter that's hidden behind a feature flag.

Or a V2 view in front of the same presenter with a feature flag. And it means we can migrate from Rx to Flow without touching the view. From views to Compose UI without touching the presenter. Etc.

So that means you have Views, Presenters, and then you must have a 3rd concept in your nav layer that defines the relationship between the UI and the Presenter?

Yes, the navigational position (think: URL) defines the mapping

In Anvil, to create a scoped component, I need both an Anvil scope (in

@MergeSubcomponent

)AND a scope annotation for Dagger... there's no way to use the annotation for both I suppose?

Quite a long time since I've used SQLDelight last, so I don't know, nor could I find an up-to-date info on the matter: I found an issue and the mentioned blog post (I'd assume this is it..?) with some of the themes. So: I have a framework-agnostic library-provided (dummy) type

data class A { name: String, value: Int }

that is used by the internals of the library for calculations and what not. In addition, I have Android client (and backend service in the future) that on top of the `A`'s fields would need to have some info, like database ID, timestamps etc. Writing the queries, I'm given the generated projections for the queries, but what if I wanted for the returned types to extend the library type's field and functionalities? Can the projections extend other types? Or write a custom

mapper

to return another type having both types via composition/delegation? Or am I just over-thinking this issue, and would the projections just be enough (most of the time they would, if they were just stupid data containers for the UI, but for some calculations they wouldn't cut it)? If I wanted to avoid redundant code-duplication, extending would be fitting

you'd want to keep your layers and their models separate

Just trying to see if my interpretation of Molecules example scenario is correct. So the doc says

val userFlow = db.userObservable()
val balanceFlow = db.balanceObservable()

@Composable
fun Profile() {
  val user by userFlow.subscribeAsState(null)
  val balance by balanceFlow.subscribeAsState(0L)

  if (user == null) {
    Text("Loading…")
  } else {
    Text("${user.name} - $balance")
  }
}

Unfortunately, we are mixing business logic with display logic which makes testing harder than if it were separated. The display layer is also interacting directly with the storage layer which creates undesirable coupling. Additionally, if we want to power a different display with the same logic (potentially on another platform) we cannot.

Extracting the business logic to a presenter-like object fixes these three things.

so the three things wrong with this are 1. "mixing business logic with display logic" | Is that referring to

Text("${user.name} - $balance")

? 2. "The display layer is also interacting directly with the storage layer which creates undesirable coupling" | That's reffering to

val userFlow = db.userObservable()

right? 3. "if we want to power a different display with the same logic (potentially on another platform) we cannot." | I don't get that. If we were using compose for desktop, the above would work?

It's not strictly the string rendering, more the if statement. DB is the storage layer, yes. Desktop is not the only platform. But you also cannot drive different screens in the same app without duplicating the logic which render to different components.

Can my issue get some attention here? https://github.com/cashapp/sqldelight/issues/2742