1

I have a large application that has:

  • some fragments that need to show real-time data received via Bluetooth (using a Foreground Service to keep the connection alive with a Health Device).
  • some fragments that show stored data - may need to access a Repo (and thus, using a MVVM Architectural Component pattern is fine, moreover, even recommended).

My question is simple:

Is it right (from architectural point of view/app design) not to use the flow: View-ViewModel-Repo-DB/Cloud access, for the whole application? - applying the Android's pattern just for those Fragments/Activities that do show stored data.

I am asking this, as long as showing real-time data (not stored in a persistant storage, but broadcasted by the Service) does not fold on MVVM pattern: (Repo of what? I haven't 2-3-4-5 sources of data to manage them; ViewModel of what?) I can just have several LiveData objects - in a Singleton class - updated by the Service / or the Service can send "real-time" broadcasts (so the Activities are just binding to the Service or observing some LiveData objects from the Singleton class), it doesn't matter).

The idea behind this problem is that the Foreground Service is a source of data but not persistent data. If applying the Android's MVVM design for the whole app, an additional question arises:

  • where is "placed" the Foreground Service in this diagram? It is an app component, so it should be on the same level with Activity/Fragment. On the other hand, it is a source of data. (and thus, it should be placed under Repository).

Also, I have some SharedPref used by UI and the Service, for example:

  1. ALERT_HEART_RATE - the Service alerts the user when the value received is >= ALERT_HEART_RATE; - the Activity shows this value/offer the posibility to change this value.

Thanks.

Andrei
  • 11
  • 2
  • I may not have exact answer to your question since your question feels trivial to me, even though I can convey one thing for sure is that even for your foreground service pattern you can still follow MVVM pattern where your service now updates repo rather than UI directly & your UI now request real-time data via viewmodel-repo. Checkout my this ans: https://stackoverflow.com/a/53552240/10271334 – Jeel Vankhede Nov 12 '20 at 06:49

1 Answers1

0

It does not matter the least whether the data-source is persistent or not ... the only difference with dynamic data is, that two-way data-binding makes no sense, because the data-source is read-only.

Martin Zeitler
  • 1
  • 19
  • 155
  • 216
  • Thanks for the answer. The problem is more complex: The service also has access to some SharedPref variables that are also shown in the UI. So, the logic behind the whole app is mainly inside the Foreground Service. For example, I need to store the ALERT_HEART_RATE that is used both by the Service and the UI (the Service uses it in order to alert the user (when the value received is greater than ALERT_HEART_RATE, the Activity shows the value - which needs to be in sync with the value used by the Service). I will update my question, maybe it will. – Andrei Nov 06 '20 at 23:03
  • Use `DataStore` instead of `SharedPreferences` for new apps ...and in principle, this is not much different then a R/O web-service. And while the foreground service does not touch views, it can have it's own logic. `ViewModel` is rather for controlling the view. – Martin Zeitler Nov 06 '20 at 23:07
  • Yep, you are right. The Service has it's own logic - my "problem" is the best way to "link" the Service with the UI, as long as there are many factors implied (like DataStore/SharedPref). So you recommend sticking with the MVVM pattern (having a Repo which has access to the Foreground Service) ? – Andrei Nov 06 '20 at 23:13
  • The service could broadcast measurement values to the app ...and there is no right or wrong, while that service not tries to access the views, due to the separation of duties. Something alike: `Service` > `Broadcast` > `LiveData` > `ViewModel` > `View`. – Martin Zeitler Nov 06 '20 at 23:15
  • What you said, means using a receiver in the ViewModel (in order to update the LiveData), and leave the Repository outside (no Repo). And here arises the question: two parts of the same app have 2 ,,architectural patterns”: 1. That specified by you, in the ,,real-time” fragments/activities, and 2. MVVM Android's pattern in those fragments that access DB data. Is this fine? (not applying the same pattern across the app) – Andrei Nov 08 '20 at 17:35