Do you guys put analytics events in a viewmodel or in ui?

depends on what you are tracking, both seems fine to me

well, clicks, sometimes events, and screen opened as well

Both, depending on the event

ViewModel. This is business logic. Let's say your event name change, or the method you use change, or there's a button click that you don't want to track anymore, why should the UI class change? Your UI is still the same. UI should just inform the viewModel that some views were interacted with

So if you want to log the activity launch and rename the activity later business logic never changed according to your logic @Greg Rami I kinda agree to a point but there can be cases where it makes more sense to log it in the view class itself imo

It's depend on kind of analytics event. If your analytics is based on UI events for example: "User opened search result screen" it should be placed closer to the UI layer (presenter for example). This same UI event "User opened search result screen" could be also translated to business behavior(domain event): "Offer has been prepared". That domain event should be logged by domain layer (view model is not a business logic, it's just strange practice in Android world). Domain events are not bounded to UI. So your UI could be changed and offer could be presented on other screen or even other platform, but the domain behavior are still this same.

Well Lifecycle Observers can also be the contenders in case if you want to track the entire journey of the screen. More like event driven approach like you started tracking location in onStart and then stopped in within onStop,

@bhatnagarm so youd pass the lifecycle observer into the viewmodel and call analytics from its callbacks inside a viewmodel?

Passing to ViewModel shouldn't be a need, that remains intact a different class which extends LifecycleObserver and is then set by LifecycleOwner (Activity/Fragment) as setLifecycleObserver(this).

I mean sure, thats just a convenience thing to not have code in fragment callbacks, its analytics calls at view layer anyways, right?

Yeah but if analytics call depends upon the lifecycle then can be extracted out to LifecycleObserver

k k, buts its still a mix of ui and viewmodel calling the analytics, im not super happy about that, or?

I think I saw somewhere a statement that it's better to treat analytics as orthogonal to your architecture/business logic, etc. And if you don't want to sacrifice flexibility, it's easier to keep it closer to UI. I've seen requirements to track for how long a specific item from the RecyclerView was visible to user. Going to great lengths to ping-pong this information to viewModel feels ridiculous to me.

UI events should be tracked from the activities, views etc. and other events like some debug events, warnings can be tracked where they happen like in repo, usecase or viewModel. Again I handle both types of events in a complete different way. UI events are kind of contract based provided my internal analytics engine for different screens. And for other events i have different implementations Logging information to different service for release and debug builds