Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Show Posts

| * |

  Show Posts
Pages: [1]
1  Announcements and General Discussion / Public Demos, Tools and Applications / VideoSwipe: the revolution will be live-streamed, on PureMVC :) on: July 19, 2013, 10:06:33
I've just put a web-app live, please take a look I value your comments!

http://videoswipe.net/go/

Ben.
2  Announcements and General Discussion / General Discussion / PureMVC with netStream / netConnection / Camera / Microphone objects on: February 25, 2012, 07:26:16
Hi

I read an old thread in these forums which said that basically netStream objects could be thought of as dataProviders to a video object, and therefore neednt be part of the Model but could be bundled into the view component.

I'd like to continue this discussion if possible...

I can see the reasoning behind the above. A netStream doesn't really contribute to the domain model, its just a platform-specific (and therefore non-portable) method of transporting data to the view tier. If this is the case and I understand it correctly, then what does this mean for the various other players in a video application?

Does this mean the netConnection is also part of the view? After all, its also platform-specific and tells us nothing about the domain model. In which case where should the actual netConnection object be created and where should it be stored?
To the netStream we also likely need to attach Camera and Microphone objects. These are clearly view components, but should they be created inside the stream viewer component? And for setting various options (eg camera bandwidth, microphone codec) should the view component expose those objects and let a command set the properties?
Maybe its better to create a WebcamVO object to hold these relevant parameters, and pass that VO into the webcam view component, in which case does this VO belong in the model since its just a convenient way to group together a bucket of numbers.

I guess if I can summarise those random thoughts into a coherent whole:
when using these built-in AS3 classes such as netConnection are these immediately good candidates to stay out of the model since they are necessarily platform-dependent? And more generally are there good rules of thumb to determine where object creation and storage should be carried out?

Thanks,

Ben.



3  Announcements and General Discussion / Getting Started / what is the BEST way to instantiate mediators? on: June 30, 2011, 06:33:00
Hi

first of all thanks to the PureMVC community for providing such a solid framework, I'm really enjoying getting my head round the new concepts.

My question is probably fairly typical, of the form "what's the best place to put code?" but I've taken a good look through the forums and demos and I'm still not clear so I thought I'd just ask for help.

I'll use our real project which is a Video Phone app, although I'm sure the steps are very generic.

So we have a NetConnectionClient object (Proxy) which receives calls from a remote server. One of these is a "doVideoCall" request which means that this client should begin a video call.

on a "doVideoCall" request we want to:
1. create a webcam model to hold all the info for streaming the client webcam, some of which is new and some of which we already have (eg name of this client, width/height of the video)
2. create a webcam view to display the webcam to the screen

here model = Proxy + ProxyVO and view = Mediator + viewComponent

this could be translated into the following simplified code:

var webcam:WebcamProxy = new WebcamProxy( infoObject );
var webcamMediator:WebcamMediator = new WebcamMediator( viewComponent );
var webcamView:WebcamView = new WebcamView( webcam );

just three lines of code, and yet a whole world of possibilities...

I've thought through some of the possibilities so I'll present them as a brief list, with my objection to each one. Maybe someone could point out the best method and why.

Method 1: Use a Command
command acts on a notification from the NetConnectionClient, executes the above code.

Objection: the command doesn't have any knowledge of the stage, so it doesn't have a viewComponent that it can pass to the mediator.

Method 2: Use a StageMediator
stageMediator receives notification from the NetConnectionClient, executes the above code

Objection: the stageMediator is doing all the heavy lifting, will end up with most of code in the stageMediator

Method 3: Separate out creation of Proxy from creation of Mediator
a command creates the WebcamProxy and then fires a notification which the stageMediator catches to instantiate the WebcamMediator

Objection: we have added a notification and a command AND we are still using the stageMediator to create the webcamMediator. ie every request now requires two notifications and a command and must be routed via the stageMediator.

Method 4: Instantiate WebcamMediator on startup
now we can go back to the original command idea since it will not need to instantiate the webcamMediator

Objection: we adopt the practice of registering *all* mediators at startup. Seems like it goes against the principle of only instantiating things at the moment they are needed.

Method 5: Use a StageProxy
now the command can access the stage via the proxy so it is able to instantiate mediators.

Objection: seems a bit weird to create a proxy just so we can get round the problem of mediators requiring a viewComponent when they are instantiated.


I guess if I could distill the above thought process into a single question it would be:

if we want to create a proxy and its corresponding view (plus mediator) and we want all this to happen only at the moment we need it - then what is the best approach for making this happen?

and if I could simplify this question even further it would be:

what is the BEST way to instantiate mediators?

Hence the title of this thread... :)

Any help or further thoughts will be much appreciated!
Pages: [1]