This may be an odd question. Would updating all states versus just one at a time consume more battery? I.e. Could it be that MVI is less battery efficient than MVVM since all states are updated every-time one state changes, rather than only the changed state being updated when it changes?

@Shalom Halbert I would say No architecture doesnt have any correlation with Battery consumption. They will all get turned into bitecode. With that being said, its important to try and write efficient code

Hi there. I have a question about clean architecture. Is there some good practice to follow when dealing with use case (i.e. some single operation) result when you want to share it between, say, different view models or interactors?

can one instance be technically part of 2 viewgroups?

as you know in general upperlayer should not know who is using it

-- Guys, back to the reactions / slack example, would you put views which might get used only sometimes (like Edited, and Reactions) in your item view and the just visible/gone them, or viewstub, or dynamically add/removeView ?

but just packages

tldr; how to figure out what to delete from locals, if remotes are paginated

There we go: https://developer.android.com/reference/android/app/Activity.html#onTopResumedActivityChanged(boolean)

Should the app handle this or should I just throw my arms in the air and not commit the whole transaction?

The more I use shared viewmodels like google suggests, the more I think it's a bad practice. (It's when you share activity VM between multiple fragments). You end up having 2 VM's for one fragment view. You pull something from the activity VM, something from the fragment VM, multiple sources of truth, thats already against the idea of 1:1 view-controller relation. So, probably to make it cleaner, you can try to merge 2 VMs via some sort of VMReducer, trying to combine some livedatas, idk.. Eventually, in your fragment VM you'll introduce some init call,

initWithDataFromActivityVM()

that you'd call in onViewCreated, which is again seems stupid, because ideally you'd want a normal constructor injection... Looks like a mess so far. Wouldn't a dagger scope be a perfect fit? Like, define a shared data holder and scope it to the activity and inject it into your fragments?

I think I can live with all the other views being added programatically via kotlin, but how can I make for example the <ImageView> be child of NestedWhatever. Afaik if added as the latter samples, its gonna be on the same level as NestedWhatever, right?

How do you guys deal with thumbnails in apps? Whats the best way of future proofing this? Should the app tell backend what resolution the screen is and backend scale the image accordingly, or rather backend provide N sizes and app picks the best one? Do you also recalculate this based on current resolution?

The use case in my mind would be to ensure the UI receives all it's states upon starting so I can do animations, or am I cray cray?

yea I dont worry about that, Im just naively asking if there is an issue with downloading for example lets say 3 1GB in parallel

and if having it singlethreaded would not actually be better perf wise

Currently looking for examples of Server Driven UI on android. Simply, some kind of screen representation (ex. in json form) is pushed by server and rendered by client. Links and articles are much appreciated, thank you.

Question for those who use RxBindings - I noticed the following warning while moving to add the library to a new app I'm working on:

Warning: The created observable keeps a strong reference to

view

. Unsubscribe

* to free this reference. Since we're not supposed to hold hard references to an activity or fragment or view in a

ViewModel

from the architecture components, should we avoid passing an observable produced via RxBindings into a

ViewModel

?

Does anyone have a logging interceptor for okhttp, that is not totally useless with parallel requests? How the fck am I suppsed to read interleaved lines 😕

Guys, does it make sense to have 2 of the same vector drawable, with only different size? Do I get some perf benefit? Why do they even have size if its vector? Shouldnt I only chose image view size?

Custom view and MVP So, I have a slightly complex custom view for adding and removing items: + and - buttons and "add" button when you have 0 items selected. There are disabled states if you can't get over or below some value. The view is heavily reused, mostly (but not exclusively) inside recycler views, on different elements, multiple screens. So now the question - how to structure the code in the MVP pattern? Does this custom view get it's own presenter? If yes, how does it connect to the main presenter (and how to handle recycling in this case)? Else, do I have to repeat the logic in each presenter for each screen or inject some kind of controller and pass it through the adapter to items (in which case, what's the difference with individual presenters)?

+ This presumes SELECT * projections..How about partial projections? Would you rather have scoped object of only user name and imagr url? Or full User object with name and url filled and rest of fields null?

or should I maybe insert the search messages into db with some flag isFromSearch=true?

Has anyone who's used the navigation library figured out a way to get a reference to a newly added fragment? I'm trying to use the google places API and they provide a fragment of their own. That fragment needs a few values set on it so I'm trying to figure out how to do that.

When in MVI what would you do a thing that has no diff? Like lets say some list of dynamically added buttons in a horizontal scroll view and you want to select one (and show border around it for example) by mvi it should be a click routed to viewmodel or wherever, where it copy mutates the state and emits a new tuple of list + selected index for example but now what, what about the list? only the index basically changed. Do you teardown the whole buttons list and recreate?

I have 32 view types in recycler view. I think its too much. But most of them are variations of the same (like item A with and without header, or item A with big margin left to visualize nesting). Maybe it makes sense to have that be the same view type and visible/gone the header in on bindview? Is there some perf penalty to this? In my head it causes layout, but so does setting text on wrap_content height textview. What would be the heuristic to create a new viewtype if views are like that? (variations of the same?)

Where would be a good place to start preparing our current applications to migrate over to the new Jetpack Compose code? Could we start wrapping views in a construct that works similar to how it works already?

Paginating the changes is probably stupid since you need it all

is there a disadvantage (or is it an antipattern to) have a viewmodel for each fragment? My app architecture is one activity that switches out fragments as screens.