Do you guys put analytics events in a viewmodel or...

# android-architecture

[ursus]

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

[Michael Bernier]

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

[ursus]

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

[Anastasia Finogenova]

Both, depending on the event

[Greg Rami]

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

[Anastasia Finogenova]

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

[Dariusz Rusin]

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.

[Dariusz Rusin]

It's force to think about your aplication in more business than tehnical way. It's hard for developers - but the requirements should come from business. They probably don't want to know how many times user clicked buy button. They want to know how many times offer has been bought.

[bhatnagarm]

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,

[ursus]

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

[bhatnagarm]

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).

[bhatnagarm]

And where in your LifecycleObserver class you can have field infection of your analytics class to track the event.

[ursus]

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

[bhatnagarm]

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

[ursus]

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

[ursus]

also annoying is that FirebaseAnalytics takes Bundle ughhh

[ghedeon]

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.

[Hitender Pannu]

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