On Friday, June 24, 2011 3:45:09 PM UTC+2, ustad wrote: > > Thanks so much for the update Mauro. I'm still struggling to wrap my > head around MVP and activities & places. I'm going to start very small > and use your code as my baseline. Just some clarification Mauro, the idea > of the MVP pattern is used to decouple the view from the presenter with the > intent to make the view as 'dumb' as possible to facilitate a seamless swap > out to its mock counterpart during testing, and the activities and places is > the underlying framework Google has provided to help essentially manage user > history but at the same time activities can be thought of as the presenter > and used synonymously ? Do I have it totally wrong?
You're right. (note that the fact that activities are presenters is an implementation choice: nothing and nobody forces you to do so; you can choose that your activity will make use of a presenter as a distinct class, or that your activity is the view, or even that you don't use MVP at all for your activity –it can make sense for very small things with few to no interaction at all–) > I guess as a beginner, I'm seeing so many different implementations where > views implement interfaces in presenters and presenters implementing > interfaces in views that I can't get a concrete grasp of how I should > approach a simple design? The idea of the presenter defining the contract > for the view and the view providing that implementation makes sense to > me.... sorry I probably have not made any sense.... It doesn't matter where your interfaces live (nested in the presenter, nested in the view, in their own files: it doesn't matter; you decide what you prefer). The fact is that if you want to decouple your presenter from your view, to be able to mock the latter when unit-testing the former, they should be talking to each other through interfaces (depending on your mocking tool, it might not be strictly necessary, but I believe it helps understanding the big picture anyway). If your view needs to talk back to your presenter, then it's a good idea to define an interface to formalize the contract for the presenter, in the same way you defined an interface to describe the contract for the view. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/CmH18Sa8GbYJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
