I am new to MvvmCross and Xamarin. I have been looking into this for some time now and I am trying to find what is the best way to send some data from ViewModel B to ViewModel A. Meaning that ViewModel A is responsible for showing ViewModel B. It's fairly straight forward on how to send data to a ViewModel when launching it, however there is no clearly defined tutorial that I have come across that is showcasing how to send the data back to the starting ViewModel on finishing.
I have come across Event Aggregators like MvvmCross.Messenger that seems to be an ideal candidate. However for an Android project I am not sure if that is a good choice due to Android Activity life cycle methods.
Any help on this would be very well appreciated. Thank you.
The Messenger is the right way to do it, it has been covered in another stack overflow question. There is even a sample code you can toy with.
The gist is that both ViewModel receive a (possibly singleton) Messenger, and when ViewModelB wants to let ViewModelA it needs to reload its data, ViewModelB sends a message through the messenger.
Internally Messenger uses a WeakReference to ensure garbage collection can still go on (check this post for more information)
It sounds like what you want to do is to show a VM for a particular result to be returned to the "parent" VM. This is baked into Android with StartActivityForResult, but needs some hacking to implement with MvvmCross.
Greg Shackles wrote a tutorial on how this can be accomplished. Further discussion here. It's a better fit for the Android activity flow than using the messenger, if I understand your usecase correctly.
Related
Despite I google-d for some time I couldn't find any of the Model-View-XYZ framework implementations for server-side Blazor, that is Razor Components (XYZ stand for any of the following: Controller, Presenter, ViewModel).
If anyone knows of such an implementation, no matter in what stage of development it is, please let me know. Thanks a lot in advance.
EDIT: The question is if someone has encountered, or takes part in development of such a framework.
The question is absolutely simple - has someone encountered some info on the Internet about such a framework targeting Razor Components (aka server-side Blazor), since I haven't so far.
I'm not 100% sure what your question is so I'm taking a stab at what I think you're asking.
It's important to understand that Blazor is not opinionated about how you choose to structure your code. The team have been very clear that they will not force any patterns on developers. This means that you are free to structure your code how you feel is best.
If you're interested in MVVM for example, Jeremy Likness has a great blog post covering using this pattern in Blazor apps. But if you are looking for official docs covering this then you're out of luck.
Hope this helps, if not please clarify what it is you're looking for.
Blazor itself is an MVVM framework. The HTML in your Razor Component is your View. The #functions section is your ViewModel and you can use POCO classes for your Models.
I released HanumanInstitute.MvvmDialogs as a platform-agnostic solution to display dialogs. It's currently implemented for WPF and Avalonia.
Blazor support could easily be added by copying from the Avalonia branch. If someone wants to take on that task.
After reading about it I implemented this MVVM design for Blazor Webassembly + WebApi app. A ViewModel is injected as transient into the View and the View calls the ViewModel's Initialize() which causes updates to ViewModel's properties which fires property-update events which are handled by the View to update the presentation state. The ViewModel also handles user actions that come from the View. ResourceApi is injected as singleton into the ViewModel which subscribes to resource-updated events. Model caching can be implemented at the ResourceApi layer. An action that updates a resource raises a resource-updated event which causes the ViewModel to reload the data and in turn raise its own property-changed event which is picked up by the View to update the presentation using binding.
I am involved in the development of a WPF Prism application which uses the event aggregator to send global type messages which are then picked up by the shell. For example, a viewmodel might want a toast message displayed but doesn't really care how it is displayed. In this instance the shell would be setup to process those events and act on them application wide.
The question I have is how do you do it if a particular view wants to display the toast messages differently. I like the global approach because it is very simple, but how to customize it for special cases?
I think this really depends upon how your application is setup and what standards/patterns you are using. In MVVM I see two approaches.
View-First
If your View-Model is injected into your view, then send the messages to your view, and let the View decide what to do with it. If it wants to display them itself, it can do that. If it wants to send them to your shell, it can do that through the event aggregator or injecting a Toast service interface. That keeps your View in control of the visual.
View-Model-First
If your View is injected into your View-Model, then your View Model should be asking for a different View, which should be bound to its own View Model. If it wants to send messages to another View-Model, it can do that through the event aggregator or injecting a Toast View-Model/service interface. That keeps your View-Model in control of the navigation between Views.
I prefer the View-First approach because it keeps your View in control of the visualization of your model. But I'm very interested in how other MVVM developers tackle this. This seems very closely aligned with the question of how to present dialogs in the MVVM View-First approach.
Using Eventaggregator for this purpose is not the right way I think, because the events are broadcasted to the entire application.
One possible way to handle the scenario is your viewmodels can get an IMessenger interface injected in the constructor. There is an application implementation of IMessenger(which is injected by default) and you can have customised implementations of IMessenger according to your needs. Your viewmodel just calls an interface function(say DisplayMessage()), but according to the Messenger injected to it, the behaviour is different.
I am currently really new to Xcode and the whole Iphone App development but reasonable proficient in Javascript/HTML/SQL.
I am looking at creating a new App which queries its data from a Kumulos database (Kumulos API's).
Before i head down the path, i just want to know if it was possible to query the database(i know how to do this), but more importantly load the returned data into a webview control.
Similar sort of idea as facebook app. I know they use a webview control.
Ive searched, but currently haven't found an answer on how do do this.
Can you suggest a better method?
Excuse my lack of coding examples.
The best way to do this is create objecive-C methods that are called by the javascript in your web view as per this guide:
Calling Objective-C from UIWebView
This way you could call an objective-C function that returns the data loaded from Kumulos, you can then do what you like in the javascript with the loaded data.
I'm new to Backbone.js. I have gone through the documentation. My question is
where does the controller concept come into picture? In other words, what is a controller in Backbone.js?
I heard that the router is the controller. If so, why it is considered as a controller? Can we develop simple basic apps without the Router also? In that case what will be the controller?
To clear things a little bit here. A Router is not a Controller, It's a way to define a client-side route map (similar to Rails's routes.rb). This helps routing client-side pages to certain actions/handlers. And that's different from a controller's job which is to provide a bit of orchestration between Models and Views. And there is actually more than one way to do this using Backbone. Quoting from Backbone's documentation:
References between Models and Views can be handled several ways. Some
people like to have direct pointers, where views correspond 1:1 with
models (model.view and view.model). Others prefer to have intermediate
"controller" objects that orchestrate the creation and organization of
views into a hierarchy. Others still prefer the evented approach, and
always fire events instead of calling methods directly. All of these
styles work well.
This brings three different approaches to accomplish this. The first one is pretty straightforward which is to have the model object included as a property to the view.
The second one proposes including a third component that performs this role of orchestration. I believe this can be helpful in quite large and complex applications. For this I encourage you to look at Chaplin, a sample application architecture using Backbone.js. The guys have done a great job in separating things out and also introduced the concept of a Controller into the architecture.
The last approach is suggesting using events to mark for actions and mediator to handle these actions. For this I encourage you to look into the mediator and Publish/Subscribe JavaScript patterns.
Check out Addy Osmani`s article on MV* on the client:
http://addyosmani.com/blog/understanding-mvc-and-mvp-for-javascript-and-backbone-developers/
From the article:
In Backbone, one shares the responsibility of a controller with both the Backbone.View and Backbone.Router.
and
In this respect, contrary to what might be mentioned in the official documentation or in blog posts, Backbone is neither a truly MVC/MVP nor MVVM framework.
It's more similar to how for example iOS Cocoa Touch framework works, you shouldn't think about it like a backend MVC, backbone team itself even never mentions MVC on their website to avoid confusion people often have when coming from backend MVCs. The View in backbone is what's called in iOS a ViewController/AppController and usually your main AppController will be a View which sets the main wrapper for your application which usually you would also use as a global pub/sub system and controller for your main app logics.
Router is exactly what it say - it converts routes into set of params and passes them to the app controller to figure out what to do with them, what subview to load etc. (or if application is less sophisticated it can load/change the views straight from the router level) - It used to be called controller but it was renamed in (0.5 I believe?) to clear this confusion.
At least this is our approach - if you checked multiple tutorials in the wild you've probably seen that when it comes to Backbone there are as many approaches to this as many developers there are. And that's what is beautiful about Backbone! :)
Usually I make my own controllers, and let the router do it's thing (catching routes, and pointing towards a controller action). These controllers are home made, just javascript objects with methods on them. They take the request from the router, collect the right data (collections, models...) and take the necessary view, combine them and pass the data into the view.
from there on it's backbone again.
however recently I came arcoss a 3rd party backbone plugin called backboneMVC. Have read it's documention, but have yet to try it out myself.
It aims to take over your router and make routes based on your controllers and actions you define with it.
Take a look at that library however I cannot promise anything because I have yet to build something with it myself.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
I realise this might be a little vague but I honestly don't know where else to ask. I have some history with PHP and I am trying to teach myself ASP.NET MVC3.
While I can find a LOT of source material on syntax and tutorials on various parts. I've started it off and I've got quite a bit going but I'm finding it a bit difficult to figure out exactly how to design the whole thing with regards to where to put things and I'm not entirely certain who I can ask or where I can find these things out?
The project I'm working on, in an attempt to teach myself is a form of online rpg game site. I've got user registration and log in, I wrote a custom membership provider to fit that to my existing database structure. But the trouble I'm having knowing where to do database lookups and how to store data etc. For example, let's say you log in, you have a certain amount of gold. On the right side of the status bar on the _layout page it will always display this value. Where do you look this up? How do you remember it? In the controller? Which controller? Etc etc.
Can anyone maybe recommend either a good set of advanced tutorials or some kind of forum where this can be discussed?
Thanks!
I learned everything i know from:
Getting Started with ASP.NET MVC 3
ScottGu's Blog -> awesome blog entries on mvc 3
Must see the Music Store Tutorial App
Check out a great book by Steve Sanderson - Ive used the previous two editions to get me upto speed with MVC.
Pro ASP.NET MVC 3
If your looking to use Entity Framework then I can also recommend;
Programming Entity Framework
The MSDN and ASP.NET sites have a LOT to offer on MVC3. I would also suggest buying the two MVC3 books by Phil Haack and Steve Sanderson.
http://www.asp.net/mvc/tutorials/getting-started-with-aspnet-mvc3
http://www.asp.net/mvc/tutorials/overview/creating-a-mvc-3-application-with-razor-and-unobtrusive-javascript
http://www.asp.net/mvc/tutorials/getting-started-with-ef-using-mvc/creating-an-entity-framework-data-model-for-an-asp-net-mvc-application
http://msdn.microsoft.com/en-us/library/gg416514%28v=vs.98%29.aspx
http://weblogs.asp.net/jgalloway/archive/2011/03/17/asp-net-mvc-3-roundup-of-tutorials-videos-labs-and-other-assorted-training-materials.aspx
Those are all good links and tutorials. In addition, you are going to want to have a separate database for your data vs. your Authentication and Authorization. This will allow decoupling and better security. You should be storing data in a database, and then the model will hold access to that database through a DAL (Data Access Layer) usually with the controller holding an instantiated repository of the DAL. In this sense the controller can build objects from the model (and thereby from the database) and then send them to the view through strongly typed objects for you to use in a User Interface.
Nerd Dinner is a pretty good sample of the whole picture, you can download the sample code and play with it.
http://nerddinner.codeplex.com/
The problem I find is a lot of examples don't use best practices for MVC in favour of simplicity and ease of reading in tutorials. So I'll outline some of the things I've found out the hard way and that work for me.
Personally from what I've found is your controller should be responsible for handling information via ViewModels to act as Data Transfer Objects (DTOs) between your business logic and your views, and that's all they should have in them. I choose to never have business logic in the controller and instead opt for a series of service classes designed to deal with their own group of responsibilities (IoC takes care of most concerns the Services may have).
This is done to keep the business logic DRY and to make it easier should you decide to try making a mobile version of your site later, or maybe expose a public WebService/API to your data.
The views should each use ViewModels specifically meant for each view, and these views should ONLY consist of primitive types or other view models. Never use a data entity from your ORM directly, though I'll be honest I have been known to break my own rule on this when it comes to views that only display information, but I usually pay for it later. Validation rules imposed on your data model are not necessarily applicable to a form and data loaded on your entity may not be relevant to your view either. ORM's that support Lazy Loading complex data entities can cause havoc with some VERY useful 3rd party libraries you can use in MVC like MiniProfiler and Glimpse, not to mention other issues when it comes to rendering these objects in forms for posting back later. So try to stick to flat ViewModels if possible.
I typically name my ViewModels according to their use. so my Register page may use a model called AccountsRegisterViewModel. However when I postback I usually use a different model called AccountsRegisterFormModel. This is because many times there is information I need to pass to render in the view but I really don't care about it (nor will it be present in most cases) on the action that accepts my postback. Also, MVC requires you to disambiguate your actions that use the same name via different parameters so using different view models helps there. For example CreateAccount() to show the account creation page and CreateAccount() that accepts your submission from the form. Though you can explicitly change where each form posts, the main focus with MVC is convention over configuration so I try not to change where forms post back to.
For your specific example of showing relevant information (Gold balance) you're likely going to want to create a Child Action with it's own view that would be responsible for doing it's own data access, or if you want to try your hand at ajax, have the balance be something handled in a smiple partial view that makes a call to a public action that returns JSON.
Those are the practices I've found have worked for me so far.