I have just read the description of MVC desing pattern and I havesome questions: I am Android developer (junior), and I want to make my code more clear. So, should I use MVC for it? And must every activity has own model? Is there any good tutorial for it? Thank you.
It's already implemented. MVC pattern on Android
you need not to do anything, As Android is prebuilt MVC
MVC is kind of an idea more than a specific way of doing things (like a 1-to-1 relation between activities and models). The idea is to separate the model, view, and controller, so that stuff makes sense.
In Android, more than one activity can refer to a single model (for example, an activity with a list of houses you can search on, an "edit house" activity, and a map that shows them as points in their coordinates). So, to answer your second question: no, they don't need to have their own model.
And yes, you should use MVC, if it makes sense. Just think about your models as a separate entity from the actual application, and your activities as "users" of the models.
On Android, I've found the MVP (Model, View, Presenter) pattern to be a more direct correlation with the overall system architecture. Your activities comprise the Views, which in the MVP setup are responsible for managing their own events and controlling their own appearance. The presenter serves as a facilitator between the model and the view, providing the data when the View requests it. Depending on your needs, the presenters may or may not be a service. As for the View/Model ratio, it really depends on what you're trying to show on your screen at any one point. When android was running on phones only, it made sense to have pretty much a one to one correlation between Activities and your model. Now, the normal case is to have a one to one correlation between your model and your fragments, which your activity then marshalls about by showing the appropriate fragments.
If you want to do MVC, though, again, now that fragments are a tool in the toolbox this is much easier than it once was, especially with well developed event system (such as the one included in RoboGuice) - Think of your fragments as your Views, and your activities as controllers - Ordering your views about, providing them data from the model, and handling transitions to other controllers.
The choice of pattern depends on your needs - if one's application is to be heeavily service driven, MVP is probably a better way to go. If, however, the app is just a thin client over a database, then MVC might be easier. It's all up to you :)
'get started' resource for MVP : http://www.jamespeckham.com/blog/10-11-21/MVP_on_Android.aspx
Related
The MVC pattern component interactions are described this way on Wikipedia:
The model is responsible for managing the data of the application. It
receives user input from the controller. The view means presentation
of the model in a particular format. The controller responds to the
user input and performs interactions on the data model objects. The
controller receives the input, optionally validates it and then passes
the input to the model.
I understand that the View should not be able to interact with the Model. But in most of the diagrams I find on the net, MVC is represented like this:
We can see that Model does interact with the View and is able to modify it, and it doesn't make sense.
Doesn't the Model update the Controller, that updates the View?
What am I missing?
The MVC architecture was created in the 1970s. Obviously there was no Internet at that time. In the original version, the Model directly updates the View through data binding, also known as publish/subscribe, also known as the Observer Pattern.
The Gang of Four Design Patterns book describes this MVC architecture in detail. A couple of quotes from that book are in another answer here.
The MVC architecture was very popular, and when the Internet came along, developers wanted to continue using it; but it didn't fit nicely into client/server applications. Thus was born "WebMVC", the version you most commonly see today. WebMVC is typically implemented as a layered architecture, which the original was not.
Confusion ensues when the two architectures are conflated. Often both are referred to simply as MVC. Even worse, related architectures such as MVP and MVVM can be called MVC.
Personally, I find the relationship between desktop MVC and web MVC somewhat like the relationship between Java and JavaScript. The latter piggybacked on the famous name of the former, to implement something significantly different.
related: Is it MVC when the view doesn't interact with the model?
No you can't access view with model directly, you must access controller first
as its MVC Pattern
Diagrams - worth a thousand words! The precise words and context used in the diagram maybe doesn't tell a story of implementation, say in Microsoft MVC 5/6.
A user's interaction is with the controller. Not the view and not the model. Calling an action on a controller will return something (a view, a file, a redirect, etc.).
In the case of returning a view of information, the controller, having worked out what data the user is requesting can retrieve a model that fits the request, pass this into a view, and return the view result of this model.
In the diagram above it isn't clear that the controller is acting as the agent in moving the model into the view. the model does not decide on the view. Why? Depending on what is in the model returned the controller, a different view might be returned. That is why the controller is aptly named. It sits at the centre of affairs making decisions and moving objects around.
So what you are missing is some context about how the process of MVC occurs when implemented
I have few gwt mvp design related questions:
Can we use event bus to switch views from one presenter to other via controller using custom event?
If above is true, can the custom event (say changeViewEvent) contain name of next view, on the basis of which controller can take a decision, which presenter to show?
Is it a good design to make views reusable(as a widget) in an application, though i don't agree with this, but will be happy if someone has any thing to mention in favor of this.
PS: all my views make use of custom widgets and there is no gwt specific widgets(buttons, checkbox etc...) in views.
You can do anything you want, but you have to consider the consequences. For example, if you switch views without creating a history event, a user may be thrown out of your app when a user hits a back button expecting to see the previous view.
I very much like the Activities and Places design pattern. It takes care of all of the issues (history handling, bookmarks, tokens, etc.) You can also extend it to add animation effects when switching views on mobile devices - mgwt does that.
I have few gwt mvp design related questions :
Can we use event bus to switch views from one prsenter to other via controller using custom event ?
This is a bad practice, unless you have real good reasons to do that. Since you're changing the view without having an impact on the url, you won't know what is a the state of a view at a choosen moment, you cannot get back to a previous view in an easy way, and finally, people will have difficulties reading the code, since you're out of the "standard".
The only reference for you should be the url, you cannot assume data is loaded neither the applicatio is in a given state: each and any view may be the start of the navigation story for your users, so if you get information from any other source than the Place, you're probably doing wrong, especially if your source is an event. the only special case here is you don't want users to enter your app in a certain view state, so you 'impose' that another url is called before, and restrict the access to the view through an event starting from a given application state
If above is true, can the custom event (say changeViewEvent) contain name of next view, on the basis of which controller can
take a decission, which prsenter to show ?
as said before, you're reinventing the wheel. It's far better to adapt to the existing mechanism that is well thought and covers the majority of cases. You can put a json formatter to tokenize your url while developing so it's not a nightmare to put variables in. And when you're done, create a nicer regular url format
Is it a good design to make views reusable(as a widget) in an application, though i don't agree with this, but will be happy if
someone has any thing to mention in favor of this.
depends on what you call a View. if it's the activitie's view then youm might need that in very few cases, it's better to inherit a basic view and fork its children for each activity (even if the view does nothing, time will show it will evolve differently): this is better since the base view contains what is common without the specifics of each child activity.
Finally if you mean a composition of widgets when you say, a view, then you should definitely reuse them, it will make you obliged to improove your widgets and compositions to be in a constant improvement, this will heop you for the rest of the project, and maybe for other projects
I am trying to introduce some good practices into my website coding, so I started to look into MVC, since it is a buzzword in website designing :-) I am confused by the MVC pattern though. I am used to thinking in a Three-tier pattern, where you have 3 layers:
presentation
logic
data
Two things confuse me around MVC:
"Model" component is often presented as the data layer above (database abstraction). But where does the "high-level" logic belong to? Like deciding what you will do with the data and how, checking permissions etc. Sometimes I've seen some of this in the controller, but it is really confusing for me to decide which belongs where.
The MVC pattern is presented as a circle of 3 components which send messages to each other, like M -> V, V -> C, C -> M, and the other way around. I understand perfectly the Three-tier design, where one layer calls the layer below itself, but not the other way around! The functions in your programming language can call other functions (you can call it "sending a message") - but it is an oriented tree graph. But how can the lower layer, or, how can the called function "send a message" or "notify" the calling function?
Maybe I am too much concerned by the MVC pattern and could happily stay with my Three-tier designing? Anyway, I would like to understand MVC pattern to at least see if it is worth using for me.
The model is another way of saying your domain knowledge, your controller should be deciding what models to display, update, create, and your view should just present the data the controller has decided to present. To address your second question the model is normally passed to the view through the controller to the view for the data to be presented.
For more details scroll down the the Model View Controller section of this page
In a Swing application, what is the best way to send data (interact) between two views?
Looking at the Coupling session in the Study Guide to the SCJP 6, it says:
All nontrivial OO applications are a mix of many classes and
interfaces working together. Ideally, all interactions between objects
in an OO system should use the APIs, in other words, the contracts, of
the objects' respective classes.
If I understood this correct, the better way would be create interfaces (contracts) to each view, and if needed use this interfaces methods to retrieve data. Is this a good way? Spending a good time creating a lot of interfaces to say what is exposed by a view is ok?
Another way that I think is to have classes to hold the data (Model) of a view. In this case, is a good approach access directly this model classes?
Thanks in advance.
The notion of a separable model pervades Swing, as outlined in A Swing Architecture Overview. Typically, each model is represented by an interface; a few include an AbstractXxxModel with some basic event plumbing; and many have a DefaultXxxModel with a standard implementation.
It completely depends on what design choice you are making. There are times where the design choice we will suggest is better for View's data sharing but it demolishes the other aspect of your software. So in order to balance you have make design choice in order to make your application run smoothly.
I personally prefer MVC design pattern. It works for me every time! read more about MVC on :
Model View Controller
Good luck!
Note : In MVC two views never interact with each other but rather they use controllers to get data from model and basically each view has controllers with a reference to it's data model.
Hey all, I'm currently working on a Java Swing application and I was looking for some guidence. The application is fairly small, but I'm noticing that as the code base is growing larger, that I have an awful lot of coupling in my object graph. I'm relatively new to Swing, but I've been programming long enough to know where this is headed.
The biggest problem I'm having is setting up my event handling. How should my child windows and objects be communicating events to my higher level objects without having references to them? I've done a fair amount of MVC web coding. Does this pattern lend itself well to Swing? Should I be building my own controller? I guess I'm just fishing for patterns that people have found useful working with Swing.
Thanks in advance for your help.
The best way to reduce coupling in a GUI, I think, is to use an Event Bus.
There are several existing implementations out there, including some supporting Swing specifically.
Just google for swing event bus and you'll find.
If you use Guice in your GUI, you may also want to take a look at guts-events.
Yes. MVC is what you have to use. Here is a very good article about MVC and Swing:
http://java.sun.com/products/jfc/tsc/articles/architecture/
Another Pattern that might be interesting for you is the MVP (Model View Presenter)-Pattern. This is great for coupling views more loosely to the model. A good explanation by Todd Snyder can be found here.
As you already said your intent to use MVC , or you may be already using. Once you have seperated out data (I call it as data model layer). Now you need to apply OBSERVER pattern on these data model classes. All the views (your ui components) using this data model are observing this model objects for any change (Via observer pattern).
I hope this is what you are looking for.
MVC !!! Then you can use also a variant of Observer called Publish/Subscribe in order to implement the event flow inside your app.
I don't agree with the people who suggest to use Event bus, because
because of code like EventBus.subscribe(SymbolListChangeEvent.class, this); your whole code will depend on a single event bus instance which makes it very hard to test,
it is hard to find out where a specific event is used.
Instead I suggest to use interfaces to encapsulate external dependencies of a module. If you like, you can use them with the listener pattern, but generally are free to refactor everything if you like.
If you want to communicate with other GUI components in the hierarchy then you should consider something like singleton that mediates calls between branches. See :
http://blue-walrus.com/2013/06/mediator-pattern-in-swing/