I have a design question which comes up often for me I have 2 apps which share a viewmodel which emits a list of 3 types which is a sealed class Now business requirement came where app B wants to add 4th type What to do? Do you make the hierqrchy not sealed? Do you remap into new hierarchy? Do you copy paste the original list generation logic to avoid mapping?

If they are two different apps with two different business requirements then I wouldn't force them to use a shared ViewModel.

Lets say you have Spotify where dashboard is a list of songs, authors and now they make new app Spotify+ where its songs, authors and podcasts

Can

Song

,

Author

and

Podcast

be mixed together? I.e. are they displayed in the UI within one list in a mixed fashion?

yea well.. but why, now app A knows about some unrelated complexity, need to throw errors in

when

etc

Yes

well if you bake the type into upstream then sure you can do all that but should you? arent we just biased because its a "nice" type hierarchy? songs podcasts etc they go together in reality

That's the example you have given

what if its some random corporate bs, PromoItem

Yes, you would need separate type hierarchies for this

but then I cannot share anything really when its a different type... bummer

No

not sure what you mean

But you can share the call to get

Song

and

Author

types

im aware the consquences, im just not sure which way to go

If in reality the types don't go together, why should they belong to the same hierarchy?

Reality = description of your business case

I dont wanna copy paste a lot of code, and I also dont want to muddy the hierarchy

Do they call the same API endpoint?

ok Ill come up with smoething more real

You can take a look at Domain Driven Design. If your business cases differ, you should not force the data into one shared code hierarchy.

here

sealed class Item
data class DateItem(val timestamp: Long) : Item()
data class ActivatePushItem(val processing: Boolean) : Item()
object NonDefaultSubscriberItem : Item()
data class MessageItem(val message: BusinessMessage) : Item()

list looks like

ActivatePushItem
DateItem
MessageItem
MessageItem
MessageItem
DateItem
MessageItem
MessageItem

api usage

ViewModel.items: Flow<List<Item>>

fun ViewModel.messageClick(message: BusinessMessage) {
    navigator.goToDetail(message.id)
}

--------

appB wants to add
data class PromotionItem(...)

list looks like

ActivatePushItem
PromotionItem
PromotionItem
DateItem
MessageItem
MessageItem
MessageItem
DateItem
MessageItem
MessageItem

You are mixing the presentation and domain layers

yea Item is view hierarchy

Exactly

I do have it but I wanted to share the logic of generating items as its not trivial

Understand

this is how the list of Item is generated

fun ItemMapper(
    subscriber: LoadedSubscriber?,
    messages: List<BusinessMessage>,
    notificationMethod: BusinessNotificationMethod?,
    pushActivating: Boolean
): List<Item> {
    if (subscriber == null) return emptyList()
    val showSettings = subscriber.default && notificationMethod == BusinessNotificationMethod.PUSH

    val items = mutableListOf<Item>()
    if (!subscriber.default) {
        items += NonDefaultSubscriberItem

    } else {
        if (notificationMethod == BusinessNotificationMethod.SMS) {
            items += ActivatePushItem(pushActivating)
        }
        var previousDate: LocalDate? = null
        for (message in messages) {
            val date = message.timestamp.toLocalDateTime().toLocalDate()
            if (previousDate == null || !date.isEqual(previousDate)) {
                items += DateItem(date.atStartOfDay(TIMEZONE_SLOVAKIA).toInstant().toEpochMilli())
            }
            items += MessageItem(message)
            previousDate = date
        }
    }
    return items
}

I would create 3 different sealed hierarchies: AppA -> without

PromoItem

AppB -> with

PromoItem

shared library for data access and conversion -> with

PromoItemDto

.

what a ItemDto?

Dto = data transfer object, it's just a name for a class used e.g. to read data from data base

I dont agree with everything but in general sure

So you need separate sealed class hierarchy in your data layer

well, not really, there is no hierarchy, its just one table of Messages, and then another table of Promos

Ah ok

so you want to join Messages + Promo into some MessageOrPromo type and then map that to UiItem ?

If it helps you with simplifying the logic then yes

I dont really see why I need the intermediate MessageOrPromo here but okay, my issue mostly was how to share the ItemMapper logic, if it generates AppAUiItem and then AppBUiItem in respective apps

No, you don't need

MessageOrPromo

thats what I thought your ItemDto was

Why can't you convert `Message`s and `Promo`s separately and then join them in the App

its okay nevermind, the question now is would you/how to share the ItemMapper logic if you would NOT share the UiItem hierarchy. Yolo copy paste? Factories?

Yes, that's a good question, I'm just analyzing your code

what about remaping the shared list ? i.e. looking for the 1st item and then adding promoitems and then rest?

I would separate mapping of Items based on the data which you get from DB (in your example code

DateItem

,

MessageItem

and

PromoItem

) into separate converters

how? I mean if copy of UiItem type lives in each app, what would those converters return?

These apps would have different

UiItemA

and

UiItemB

hierarchies

I know what you mean but how would the signature of Message to MessageItem converter look like if its shared code

No

so youd go Message -> MessageItem -> AppAMessageItem ?

You need the sealed hierarchy only in the UI, right? To pass the `Item`s to a RecyclerView or a

Column

isnt that a bit of overkill?

No

well yea but its 2 basically ununsed instances

They are used, for conversion

well yea, to make compiler happy, not much else

No

its java defensive copying again, i.e. why swift is fast when it doesnt do this (optimizes copying away)

in clean architecture you can have different types at different layers (data, domain, presentation) even if they are almost the same

one of things that swift does is it sees every callsite and rather mutates the collections rather than creating new ones, where possibly

Then anyway the work should be offloaded to the backend

well, its about needless instantiation, I do agree with Clean in general, but one shoud not create UseCases which are 1 or 2 lines, etc like many people seem to think

But that's your case exactly!

true

You said it yourself "I don't want to copy paste"

I know, im schyzo on this all the time

I have maybe 20 use cases in my 40K lines production app

yea Im all for composition, but it somehow doesnt fit in my head with data .. for exmaple what if the difference was enum? i.e. Message(type: Type)

Difference between what?

and now app B wanst to extend the enum .. no I need AppBMessage(type: AppBType) and all polymorphism is gone

You create two enums

okay but then you need the parent type extended as well

I must say I don't fully understand what you mean here

different example alrogether, forget the ui items thing lets say shared code is this data class Message(val type: MessageType) where MessageType = Text | Image now app B wants to add video to the enum

Again, two hierarchies in UI layer

you create AppBMessageType enum of Text | Image | Video, this enum is unrelated to the original

Yes

which means you need AppBMessage as well

Yes, and?

now, woulld you make AppBMessage and Message related or no?

No

then how would you pass the AppBMessage into some other interface which takes Message?

You need an intermediary type

Message lives in shared code, not app A

And you convert manually

what intermediary type?

Ah ok, you should have said it. But then it's exactly the same example as your previous one

lets say the api is

AnalyticsTracker.track(mesasge: Message)

You don't need a sealed hierarchy at every level

you created AppBMessage via mapping from Message .. so do you have a converter which goes backwards as well? so you can plug it into the AnalyticsTracker?

But in the domain layer you just have some other

MessageConverted

type, which is just independent type

so your decision rule is “how much would I hate copy pasting this”?

Usually in real life AppA and AppB will diverge more and more with time

yea, I have to massage the backwards mapping in to my head so im fine with it 😄 thank you for your help!

You're welcome!

yea and the guessing gives me paralysis by analysis

Yes, it's better to try 10 different architectures (even bad ones) instead of analyzing everything

btw this is all sort of straightforward, but what if the Message was serialized to database? I flatten columns, i.e. the sql table has columns of all fields in the hierarchy, and then its mapped into ImageMessage, TextMessage etc at runtime all is fine .. but obviously you cannot just extend the table in App B, what do you do then? some extra table for the AppB specific columns?

If you make good use of types, compiler will basically check most of your program logic for free

thats what I do now but the bigger the type is the less I want to do it

Hmm ok, then I don't know. I have experience mostly with data on REST servers

basically you could view it as Message and MessageDetails, stitching it together into MessageWithDetails

Like I said, I have no idea about DB sharing and optimization

but the issue is you want to do the stiching at database level, so you wont get glitch emits with reactive code, etc

What to do?

I probably wouldn't let the two apps share a VM.

cheaper until you have to patch multiple places and fotget, but yea, the guestion is where is the threshold