CODEWITHSUNDEEP
cross-platformmvvmcross
Vagif Abilov
Vagif Abilov

Reputation: 9991

MvvmCross services, plugins and application objects

I consider using MvvmCross to port my app to multiple platforms. I checked a few projects that use MvvmCross, and the framework looks very promising and easy to adopt. I would like to clarify a few concepts to make sure I will do the porting right.

  1. As far as I understood, the cross-platform business logic should be implemented in services that become available via RegisterServiceInstance calls.

  2. Platform-specific functionality is exposed via plugins. I should strive using MvvmCross plugins but if I don't find the one that offers functionality I need I can write my own. How should I plan granularity of custom plugins? Should I avoid having any business logic there and only put platform-specific stuff? If using standard Mvvm plugin requires big code changes in my app, should I still do this to avoid making my own plugins or i can be liberal in plugin design decision?

  3. Finally I haven't fully figured out the purpose of so called application objects, in particularly why they use this long postfix ("ApplicationObject"). What is qualified as an applciation object and why is it recommended to decorate it's name?

Thanks in advance.

Upvotes: 3

Views: 904

Answers (1)

Stuart
Stuart

Reputation: 66882

Generally.... Mvvmcross is actually aiming to be quite a light framework - it is hoping to be closer to mvvmlight than to prism... It's aim is to let you use mvvm for views and view models - then how you write your business logic (midels and services) is really up to you.

With that said, for the samples I've written, I do generally use IoC and plugins - so that's "my practice" - whether that's "best practice" is definitely debatable :)

  1. As far as I understood, the cross-platform business logic should be implemented in services that become available via RegisterServiceInstance calls.

Yes, RegisterServiceInstance, RegisterServiceType and GetService together provide a simple IoC framework.

In my apps, I generally choose to implement business logic in a 'service' layer which the app registers with IoC during startup and which the vm's consume when they need to.

If you wanted instead to code your business logic direct within the vm's or if you wanted to use direct coding of the services (instead of IoC) then you are perfectly able to do so.

  1. platform-specific functionality is exposed via plugins. I should strive using MvvmCross plugins but if I don't find the one that offers functionality I need I can write my own. How should I plan granularity of custom plugins? Should I avoid having any business logic there and only put platform-specific stuff? If using standard Mvvm plugin requires big code changes in my app, should I still do this to avoid making my own plugins or i can be liberal in plugin design decision?

Yes, be liberal!

Plugins are just a formal way of doing IoC using PCLs.

In the mvx tree, the plugins are very small and targeted because they are designed for reuse across many projects.

In the mvx tree, plugins don't contain business logic because mvx is general - it doesn't know about your business.

If you want to write a single plugin for your app, that registers 50 interface implementations, many of which are business objects, then "yes, please do" - architect your code around your business needs.

Finally, please note that plugins are optional - if you have some platform specific code you can always find another way of injecting it into your vm's - e.g. your views can inject implementations, or you can write non-PCL code that uses file or assembly linking to select the right implementation for each app platform.

  1. Finally I haven't fully figured out the purpose of so called application objects, in particularly why they use this long postfix ("ApplicationObject"). What is qualified as an applciation object and why is it recommended to decorate it's name

I agree the name is not perfect - but I still can't think of a better one.

MvxNotifyPropertyChanged objects know about the Ui thread and provide an inpc implementation

MvxApplicationObject objects inherit from MvxNotifyPropertyChanged but also have access to navigate methods.

MvxViewModel objects inherit from MvxApplicationObject and are designed to be used with views.

The only place I commonly use MvxApplicationObject right now is for the start object - the "thing" that kicks off the very first viewmodel in the app. I commonly call this the StartApplicationObject because that describes what it is. If you want to call it something else, then please do - I promise this won't cause any harm to any kittens.

side note: in the very first mvx project, the start object originally inherited from MvxViewModel ... But that got caught and criticised at code review... "that's not really a viewmodel - it's more of a - thingy - you know - it does stuff in the ui application - it's a ..." - and that's when MvxApplicationObject was born...

If you later find you have other objects that need to request navigation, but which aren't view models, then this base class is also for you. Otherwise, don't feel you have to use it...

In summary...

From your question, it sounds like you've read through the samples and have a good understanding for how i generally build the core part of my apps.

The only thing I'd stress is that I stay flexible - I don't believe there's one best practice, most new projects present new unique challenges, and I generally learn and try new things on each and every project.

Hope that helps

Stuart

Upvotes: 6

Related Questions