I am using child view controllers to help implement a radio player. Besides a couple of popups (info, share etc) it is only one main view.
Unless it is called/implemented by the "master view controller" my children UI components will not update. I can see the the variable, via "print" statement being passed using a struct, delegation, injections, didSet etc. So I know the "data" is not the issue. The next logical step would be to ensure it was call on the main que. That also didn't help.
So my question becomes, is it a bad thing to update from the master view controller? (Besides the couple hundred lines of code!) Suggestions on things I may not have tried or missed?
Related
I am currently in a situation where I need to find what methods are executed when a specific button is clicked.
I have traced the method that binds to the button but there are too many places that it links to. Is there any way to list all of them; so that I can check them individually?
Right now, I am tracking the code in model but when it comes to the methods that use depends, that can't be easily traced.
What makes it so difficult is that the Odoo server here currently has hundreds of customized modules.
(I'm using Prism Dryloc) My application consists of two views. The first contains a single list view displaying strings and the second - an entry and a button.
The listview is bound to an observable collection in the first page's View Model. How can I add to the observable collection from a different view?
Great question! You're essentially trying to pass data between views, and there's several ways of passing data between Views in Xamarin.Forms.
The two ways that seem relevant for your case:
Either making the ObservableCollection a public static object (so there's only one global instance of it). Not recommended.
The better way is to use the messaging center so that the second page publishes an event when the button is pressed, that the first page is subscribed to. And it passes that information that gets added to the list.
If these don't work, elaborate your use case and I'll suggest some more
I'm curious to know how to create the sidebar used in twitter and many other Apps
What i'm asking for is not about graphics, but i'd like to know which is the better way to create a structure to permit switching between different sections.
I don't like asking for help without start by an opinion, thus, this is mine:
Generic view structure would be created with a NSSplitView
I Need a generic Model class managing sections and taking a pointer to the current one.
Here i'd add informations about image used for any section etc... (something like a custom UITabBarController for iOS.
The Left view of the split View would be connected to the generic Model and would be able to present its section and get the current one. Pushing a button will ask the generic Model to change the current section and load content in the Right view (some doubts about this use a Model that way :P probably not the better one)
The Right view loads other view controller as requested by left View (i have may doubts about how do that!)
I'm on the right way ? how would you build a structure like that of Twitter ?
(Off topic: I'd really appreciate correction of my terrible English to keep this question suitable for all users)
Here's what you need https://github.com/erndev/EDSidebar
That's pretty much how I would do it although what you call a "generic model" object, I would call a controller (because it fits in the controller part of MVC).
The right view would be a Tab View with the style set to "tabless" so you don't get the selection buttons at the top and the individual views within the tab view would be selected by the controller using -selectTabViewItemWithIdentifier:
That's how I would do it anyway.
I am designing a web application with a left sidebar. Each of my actions has its own widgets which must be loaded into the sidebar, and in some cases multiple actions are stacked using the Action Stack plugin. When all actions have finished running I need to 'normalise' and manipulate the number of widgets, then render them.
At this stage I am thinking that:
Each action should store its list of sidebar widgets with the view, and
A front controller plug-in with a dispatch loop shutdown event should take the list from the view and operate on it
Does this sound reasonable? Is there a better way?
I wondered whether I should be storing the list of sidebar widgets with the response object directly, but I don't think this object allows user variables, does it?
Your thoughts are much appreciated! Yeehhaa!
Ok, so I ended up defining a list of widgets in an array for each controller, then modifying it where required in each action. But now I am in the process of moving more logic into the model, so no doubt will all change.
I have been reading about the evils of the ActionStack and now that I have my head around how to go about things without the action stack, life is much simpler!
I'm developing an app which has a large amount of related form data to be handled. I'm using a MVC structure and all of the related data is represented in my models, along with the handling of data validation from form submissions. I'm looking for some advice on a good way to approach laying out my controllers - basically I will have a huge form which will be broken down into manageable categories (similar to a credit card app) where the user progresses through each stage/category filling out the answers. All of these form categories are related to the main relation/object, but not to each other.
Does it make more sense to have each subform/category as a method in the main controller class (which will make that one controller fairly massive), or would it be better to break each category into a subclass of the main controller? It may be just for neatness that the second approach is better, but I'm struggling to see much of a difference between either creating a new method for each category (which communicates with the model and outputs errors/success) or creating a new controller to handle the same functionality.
Thanks in advance for any guidance!
My preference would be to create triplet Form-Controller-Model for every form displayed to the user. Whenever user clicks on 'Next' button on a form its controller should talk to the back end manager which takes care of dispatching submit request to the next form in chain. Vice verse if 'Back' button is clicked. Last form has a 'Finish' button which will go to the manager and pass the last bits of information.
This will avoid inheritance, make your code more robust and testing of forms possible in isolation.
My preference would be to keep it all in one controller. It keeps all the relevant processes for filling out the application/form in one place, although I'm not sure how "massive" you're talking about. If you do decide to split it out, I would not subclass off of the main controller, but just make a handful of independent controllers, perhaps related by name for ease of use down the road.