I'm blogging more than I'm coding lately, so I'll try to keep this brief. But I noticed someone mention MVC while I was googling around for practical information on GWT. After I thought about it a while, building a web app is a great example of the Model-View-Controller paradigm.
The model is data you store or derive on the server. You can use GWT's RPC mechanism to get at this data. The Controller is also on the server. You can send commands, like build my project, to it via GWT RPC too. The server may then farm that out to other specialized servers to actually perform the action. The View is the JavaScript code running in your browser that takes the data and draws it using GWT's widgets and invokes the control using GWT's Handler mechanisms. Having a well defined RPC mechanism, and having a requirement to reduce the traffic over the wire to help with responsiveness, you get pushed to keep your web app MVC clean.
Now, relating this back to my mobile app interests, I can easily see the View portion of the app being replaced by the native widget framework for the particular platform. As I've mentioned in previous posts, I don't think running a web app in a browser in a smartphone is a good idea. I know the browser on my Android phone is really slow. You're better off using Android's native widget set in Java to accommodate the form factor. That's what mobile app building is all about. What I need now is an implementation of GWT's RPC mechanism in Java using Android's communication APIs, and really interesting things jump into mind.
What this leads you to is having three View implementations for my web-based IDE, that I'm now calling W-IDE. One in the web browser using full GWT, one in Android using Android's native widgets but still communicating with the services defined in GWT, and one using the regular Eclipse desktop UI, theoretically using those services as well.
Now, yes, that's three implementations of the same thing, and I know how that rubs people the wrong way. But my theory is that they are, in fact, not the same thing. Depending on which of the three you have, you are likely to need different workflows. Running Eclipse in a 24" monitor, it's OK to have all those views and taskbars and such visible all at once. In a browser running in a 10" netbook, not so much, and you'd really like to make it page based to take advantage of the browser's history mechanism. And in a 4" smartphone, I really struggle with any workflows that make sense, but they certainly would be limited to one view or editor at a time.
At any rate, this is sure turning into an interesting journey of exploration. In the end, we may decide that this is all crap and IDEs are meant to run on desktops only and that using RAP's server-centric architecture is OK to render in the browser (which if you can't tell yet, I'm not sure I agree with). But this is a 5 year journey and we have time for the different technologies involved to mature and we'll see. I think we have a lot of time to figure this out.
And, yeah, I guess I failed at keeping this short.
Why does a Java client which has access to much smarter and powerful protocol and network technologies have to call a GWT-Service via HTTP.
ReplyDeleteWouldn't it be wiser that you provide your services through a SOA-Framework (or at least as an rOSGi-Service) and make your GWT-Server-Service act as a customer to this real service?
What you are talking about here is not MVC but rather SOA.
Well publishing your OSGi-Services as such is a piece of cake whereas publishing a (proprietary)GWT-Service is much harder because it is coupled very tight with the codegeneration feature of the GWT-Compiler.
I don't think MVC and SOA are exclusive. So sure, this is SOA too.
ReplyDeleteYou use http because that's the easiest way to communicate through the myriad of firewalls and NAT routers that exist on the network. But, sure, you could use other protocols, assuming they are as easy to set up as servlets in Equinox.
Amen! When ChromeOS was first announced and it wasn't clear how much it would share with Android, I hoped for exactly such a "secret weapon" to be released in tandem (http://twitter.com/spapadim/status/2542626518). Actually, I still hope for some web-based MVC framework extension of some form... ChromeOS *can't* be just a distro, it's too easy, right? :)
ReplyDeleteOr perhaps the long-rumored GDrive (or Platypus, Lighthouse, GDS, whatever..) + framework for seamless sync. Still waiting for general syncable content provider framework on Android (there's bits in GIT, but unreleased). Perhaps it'll show up in ChromeOS (not sure HTML5 is the ultimate answer, btw). Anyway, getting a bit carried away (and OT) here... :)
ReplyDeleteSorry to be purist (and possibly anal here), but I think you're confusing MVC with 2/3/n tier architecture and really mean the latter. I know it's commonly used both ways because of the overlap and most people don't care. But I figure because of the quality of the rest of your writing, you'd like a reminder :)
ReplyDelete(You surely know all this stuff because of how good the eclipse code is in this regard, but figure others might want in on the difference).
MVC is a design pattern, like you have multiple widgets of grids/trees/etc (views) and multiple classes that hold different kinds of data (models). To populate your view with data from a ANY particular model, you write a specific controller that connects the two (the messy bit)... this way both the code in the model and the view is pretty and don't know about each other. The code in the controller will make use of the api from both the model and the view though.
With 3 tier architecture, you might write a particular view specifically to take advantage of a particular business function in the business layer. Not a very MVC thing to do, but that's cause it doesn't apply. This tends to be more about distribution and ownership.
Yes, they are related in that they are both about separation of concerns, but not the same kind of concerns.
Happy to be corrected if I'm way off :-)
Daniel
http://dmg46664.wordpress.com/
No, I'm probably using the term incorrectly. Anyway, my point is that enabling multiple UI technologies and paradigms using the same Core helps separate architectural concerns. It's just a good habit to get into.
ReplyDelete