Just a quick fyi, we have posted the source code for my MXNA sample application.
You can view the app, read some info, and download the source code from here.
Hi Mike i have a question. Are you using the mvc patern in this sample app?
>mvcYes. pretty much. In the case the MXNAAppController class / symbol is the controller, which handles all of the communication with the server.MXNAFeedView is the view (the only view in this app) which handles the display of the data.And the data (model) is encapsulated in the MXNA Web Service class.The controller communications with the views via method calls, and the view communicates with the controller via events.hope that helps…mike firstname.lastname@example.org
Thanks for the reply. I am building a e-commerce app and am trying to implement the mvc pattern. But am a bit confused on the controler/view parts. I tought that the view was just simple the components you put on the stage and the controler handeled the rest like setting dataproviders and handeling events ect. But in your app the view (MXNAFeedView) handles and sets dataproviders and sets components states like enable ect. Currently on my app I have a controler class linked to each movieclip(page) I don’t have view classes since I tought the view was the components and I have my model classes and pretty much the controler class does the evts handeling and setting the dataproviders / filtering data and the functions. Should I have a seperate class for view ? and what should handle what? thanks for any info that can clear up my mind.
Omar,The controller communicates with the view, it does not communicte directly with components / items within the view class.(it does communicate with the window component, but just because I am using it as a background).So, the view is a class that contains the components.mike email@example.com
Ok correct me if am wrong so the controller registers to the view for events like click of a button and then the controller calls the model for the data when the events fire off. The view also registers to the model so when the data is reviced the view then fills the UI with the data reviced. Is this correct?Also why do you access the pBar directly from the controller and not the view? Thanks
>Ok correct me if am wrong so the controller registers to the view for events like click of a button and then the controller calls the model for the data when the events fire off.yes, although dependins on the event, it may not do anyhting with the data.>The view also registers to the model so when the data is reviced the view then fills the UI with the data reviced.In this case, it is a little different. The controller handles the model, and then passes data to the view.>Also why do you access the pBar directly from the controller and not the view?Because this is something specific to the entire app and not just the view. i.e. if there were multiple screens, it wouldnt make sense to include multiple pBars.hope that helps….mike
Ok so the controller revices the data from the model and passes it back to the view I get it. Thanks alot, this can be confusing sometimes since diffrent ppl apply it diffrently I saw a example from gskinner in ultrashock and he seams to access the UI directly from the controller and doesn’t have view classes. That got me confused.Thanks alot again.
One last quick question I swear! hehe.Whats is best to do? to have the controller dispatch events so that the view can register to them or to just make method calls to the view from the controller? If I would dispatch events from the controller I would have to reference the timeline when I wanted to register the view to the controller.Is that good practice? or is it better to just make method calls to the view? Thanks
Just pass in the controller to the view as a parameter.
Copyright © 2013 Adobe Systems Incorporated. All rights reserved.