Folks who map domain model down to ui model

I had the same set up in multiple projects and came to the conclusion it is something that should be avoided. Otherwise you have multiple mappers "to the domain model" and "from the domain model" and possibly create a bunch of redundant objects along the way. So my preference is just not parse all fields from the response if you don't need them and just keep the ones that are used in the app regardless of it is in the logic layer or ui layer.

well, I think the amout of mapping should match the complexity of the app, I do see advantage if some fields are added to the ui model, better than passign around tuples

I'm of the opinion to translate domain model classes into separate UI model classes. Don't just add or remove a few fields, no inheritance relationship between the two Your domain model models your business or remote data logic closely. Your UI model models your UI very closely. Don't tie them together firmly with inheritance or aggregation. Tie them loosely together using functions (map). A change in either model should be easy to do, without affecting the other.

Totally agree on no inheritance point, so what about a concern of extensive object creation? @streetsofboston

The extensive object creation is less of a concern with the ART runtime and its (new) GC. If you would have a tight loop with thousands and thousands of object creations per second, then yes, it still would be a concern and you may need to use a less elegant objects structure (e.g use inheritance, etc). But for most stuff that you just put onto the UI, that concern is not that great (anymore). If you are worried about too many object creations and performance, measure first and see if it is really a concern.

I wish we were developing only for the flagship phones ....but I still see many users using not that performing machines especially in the developing markets

Then it may indeed be a concern for you and may need less elegant implementations. Try to measure first on a underpowered phone, though, to see that excessive object creation is an actual concern.

I have seen multiple talks on it from DevSummit and IO too if I am not mistaken, but somehow it feels not many are interested in this 🤔 in a way oh it works then I don't need to know more 😆

Improvements in the GC are not just performance wise, it also improved in its design (eg no more ‘stop the world’ garbage collections, generational garbage collection, etc).

I believe there stop the wold only when it is completely out of memory, but not each time, you actually gave an idea that I need to rewatch that session I am thinking about 😆

I think OP question was how to reverse-map on clicks, rather than 50 objects instantiated every few seconds

Sorry, you are correct; I meant, not every GC is a ‘stop-the-world’-gc anymore, especially ones for first-generation objects. But for serious memory issues, it may still happen

also @Anastasia Finogenova I think you worry about nothing, I develop ok Nexus 5, its chat app, every new message, new messages list ist emitted, then mapped onto domain objects, and you cannot notice any perf issue, only thing you would notice is if the lists were long, for which you should use pagination, and then binding, i.e. use diffutil

Nexus 5 is not a performing device you are right but even if these possible issues may not be manifesting now they may in prod, as when you are developing you are the only app running usually and you usually rebuild the app which basically kills it and relaunches which is triggering gc for it. for the mapping part if you have hard time mapping back in case your objects don't have any unique identifiers as params (like id coming from a db or a barcode number cases etc) I would consider keeping the fields that you can't assign from within the app, like for example if user id is cached and known to your app than you don't have to keep it for the UI model, you can just grab it in the back mapping and so on, so you can either persist it if it is common across the objects or consider keeping the fields that you can't recreate with the reverse mapping

@streetsofboston seems like discussion has derailed from original question (nobody was talking about inheritance). What do you think about actual question in the topic? Should he keep extra fields in UI Model, that are not involved in rendering and just being passed back, or having an additional Map between UI and Domain model is preferable?

yeah… it got a little off-track 🙂 I would say the domain model gives the UI model (or creates a UI model) with all the needed information including a future callback (e.g. a future button-click). The UI can just hold on to that, even if it means holding on to data that is not rendered on the screen (e.g. inside a RecyclerView Adapter’s contents). This can be as little as a primary-key or other identifier.