MVC Pattern
Hi,
i am creating an application for a mobile device. A lot of menus exist and the RecordStore is used for persistence. Also a network connection is established respectively a network interaction with a server exists.
I want to use the MVC pattern and would structure the classes as follows:
All views are part of a ViewManager class
The controler handles the network connection establishement and also the network interaction. Doing this would require the specific method call up - as sendInput(String....) - from the specific view. But there should be no reference from the view to the controler and therefore i would go over the model for the sendInput(String....) method.
The Model provides methods as safeInput(String....) which are called from the view...but the MVC pattern tells not to call model methods from the view. Should i use therefore a different controller for each view and another controler for the network-interaction?
Thanks for suggestions!
[1005 byte] By [
Cinimooda] at [2007-10-1 21:33:28]
> i am creating an application for a mobile device.
What kind? Cell phone? PDA? Blackberry?
What does the application do?
> A lot of menus exist
Written for what kind of user interface? HTML? WAP? This seems irrelevant here.
> and the RecordStore is used for persistence.
Is RecordStore a class that you wrote? Is it a DAO for a Record class? What is being persisted?
> Also a network connection is established
> respectively a network interaction with a server
> exists.
I don't know what you mean here.
Is this a request/response protocol like HTML? Do you mean you've written a listener that runs on the server on a specific port?
>
> I want to use the MVC pattern and would structure the
> classes as follows:
>
> All views are part of a ViewManager class
Is this a Java class that runs on the client? Is it a Swing client?
> The controler handles the network connection
> establishement and also the network interaction.
Usually it's the client that initiates the connection with the server. Both client and server participate in the network interaction. What protocol do you plan to use?
> Doing this would require the specific method call up
> - as sendInput(String....) - from the specific view.
> But there should be no reference from the view to
> o the controler and therefore i would go over the
> model for the sendInput(String....) method.
> The Model provides methods as safeInput(String....)
> which are called from the view...but the MVC pattern
> tells not to call model methods from the view.
I'm not sure where you're going here. (i'm not sure you know, either.)
> Should
> i use therefore a different controller for each view
> and another controler for the network-interaction?
The fact that you have a mobile client is immaterial. As a matter of fact, I believe it's possible for your mobile device as long as it sent HTTP requests to a Web app and the controller for that app knew what to send back as View appropriate for that mobile client.
Here's the way it's usually done with Web-based apps:
The View in this case consists of JSPs that make HTTP POST requests to a single servlet that acts as the gateway and router for the application. You can consider that servlet and the Controllers it uses to satisfy individual requests as the Controller layer.
The Controller class usually follows something like the GoF Command pattern.
The front controller servlet has a mapping that tells it which Controller class to call for each request. This is loaded when the app is started and cached.
The Controller class uses Model and Persistence classes to satisfy the request. Persistence interfaces follow the DAO pattern, performing CRUD operations for each Model object that needs persisting.
The Controller sends back whatever objects are needed for the response display. The controller servlet determines the response UI to send back and returns it to the client.
You could get all this working for a Web app. I believe it's possible for the controller servlet to determine the device that made the request. You could make it so your app could respond the same way to both browser and mobile requests, with only the UI being different.
Look at Spring and Struts to see how it's currently being done for Web apps and emulate them. Better yet, just learn Spring and figure out how to wire mobile devices into it.
%
I agree with Duffy that there are a lot of unknowns in your post. I just wrote a decent J2ME application using MIDP 2.0. These were the results of what I experienced:
> Your view should use MIDP or CLDC classes for rendering. This will limit you to Form, TextBox or Screen. If you want to get spiffy, you can implement a CustomItem. There are menus available. However, a mobile device is usually a poor choice for 'lots' of menus. Rethink your navigation strategy if possible.
> Utilize a server as much as possible. Ideally, your client device will only send the minimum amount of HTTP data to a Servlet, where the heavy lifitng will occur. Attempt to minimize the number of objects you create on the device, as memory is at a premium.
> Persistence on a mobile device usually requires Vendor-specific Java classes. Some are better than others Blackberry's API is actually very good. So, there will be a tradeoff between portability and functionality for most devices.
> Nearly all devices have their own way of packaging J2ME JAD files into their own proprietary format. You will need to investigate how to do this for each device you want to deploy on. This will be especially true if you want OTA deployment.
> Design any interfaces between the client and the server as you would for a distributed system (which this is). You want to minimize network traffic. So patterns such as DTO are a good thing to learn.
> Your view must reference a controller if you implement MVC. The controller responds to user requests and dispatches to the proper view. Unless your application has a single screen, you will want a controller. And since you will have 'lots' of menus, I would be surprised if there was not some type of controller on the client.
- Saish
