1

Could you give more explanations on MvvmCross multithreading?

ViewModel calls to Views are safe, so there must be no any conflicts.

However, IMvxMessanger has SubscribeOnThreadPoolThread and also SubscribeOnMainThread (except just Subscribe), which are not really clear for me when to use them.

Also, what's about multithreading inside of ViewModel (for instance, if two web-requests are activated simultaneously and on their results each of them tries to access my dataservice (for instance, writing data to database))?

(Or there are some other such special situations you know from your experiense).

Thank you!

Community
  • 1
  • 1
Agat
  • 4,577
  • 2
  • 34
  • 62

1 Answers1

1

For the single technical question about the differences between the subscribe methods on the messenger, these are explained in the XML comments on the interface (but are also largely self-explanatory anyway)

  • subscribe on main thread - messages will be received on main thread
  • subscribe on thread pool thread - messages will be received on a thread pool thread
  • subscribe - messages will be received, no assumptions should be made about which thread

Xml comments at - https://github.com/slodge/MvvmCross/blob/v3/Plugins/Cirrious/Messenger/Cirrious.MvvmCross.Plugins.Messenger/IMvxMessenger.cs#L15

For the rest of the question: as an app developer, you are free to use threading and async in your code - and the normal c# and .net multithreading objects are there for you to use (or a portable subset of them) - synchronising access to a resource is just a normal development decision and technique.

Stuart
  • 66,722
  • 7
  • 114
  • 165
  • Thanks for the answer. And I did understand general meaning for the "Subscribe"-family methods of the message, but I still don't fully get what is the purpose of the last one: "subscribe - messages will be received, no assumptions should be made about which thread". What are the situations when I must not care of which thread are the messages received in? Why is the third this method for (as two others already exist)? – Agat Jun 27 '13 at 09:24
  • 1
    Mvx does not force any 'must' or 'must not' on you - you are free to choose how/where/if to synchronize multi-threaded code. – Stuart Jun 27 '13 at 09:48
  • 1
    Well, that was not actually "must" in "must" meaning. Of course, that meant "should". I am a human, so none must forse myself to do something I don't really want, but what I do really want is to understand when I **should** use the third method mentioned instead of two other ones. – Agat Jun 27 '13 at 12:40
  • @Agat - You would use the third method when, according to the design of you application, it does not matter which thread the received message is processed on. Normally that would not be anything that touches UI. An example might be to add an item to a thread safe collection - it would not matter which thread adds the item, so no reason to process the message on the main thread or on a separate pool thread. – Felix Jul 23 '14 at 03:06