Suppose I have a view
How can I get a control of this view by Id from a different controller.
I have tried to set up an ID for the view and tried to access the view by
sap.ui.getCore().byId("mainViewID") in another controller but it didnt work.
It took only the dynamic view id what you can find from the html elements.
Getting a control from another view is discouraged and is generally indicative of bad design.
In case what you need to do is access data in another view or to change a property of a control based on user input, the better method is to bind those properties to a model and then access that model from the second view.
You can do this by attaching the model to the core, thereby making it accessible throughout the application. For example:
var oModel = new sap.ui.model.json.JSONModel();
this.getCore.setModel(oModel,"modelName");
Alternatively, you can create this model in the manifest file.
Related
I have 2 separate views, each with their own controller.
First view is the first "Part" of a survey, second view is the rest.
I have a model view setup for each, but is is possible to pass the details of the First page's model to use in the second?
I know you can include parameters in routing but they're large text fields in this case.
The other option I have is to save the details in the back-end and only pass over a reference number of the created model as a parameter.
Any other thoughts?
One way is to put your First page's model in the method init of Component.js.
If you want to access the model, in your second View Controller , you can call getOwnerComponent of to access the Component and the First page's model.
Hope it helps.
In the top of my detailcontroller I have a button to show a list of selected items from various options on the detail controller.
I want to initialize and keep the model, the popover and the list objects in the mastercontroller. How can I get a reference to my mastercontroller to reuse these objects?
Sharing data between views is easiest using a model tied to the component. If you make sure that everything that's selected in the master model is contained in that model, you will be able to use the data from the model in the detail view again.
Pulling data directly from another controller would go against the MVC paradigm and is not recommended (although not impossible, using e.g. the sap.ui.getCore().byId() method). I would not go there unless you have a clear view of the consequences.
I've got a Silverlight client and I'm using MVVM. I've put in my first View and View Model. The View binds to the View Model. I now want to localise the text of all the controls. For example my View has a button which contains the text "Search". I know I need to bind the Text content property of the button to something to provide the correct text. The question is what? Do I provide a property in the View Model called SearchButtonText and bind it to that(where the SearchButtonText property returns a resource string)? Or is this taking it too far in terms of what the View Model does and instead bind to a resource string in the View namespace, even though the root level binding for the View is the View Model?
Any help much appreciated!
Cheers
Bind to a resource string in the view.
Any advice on where to store the main list data for an iPhone application like the following?
NavigationController based
Level 1 (main screen) is a List of Items. Hence it uses a table view (table of items)
Level 2_EDIT: Is a view you can get to from the main screen by clicking EDIT. Here you can add text to be added to the main view list
Level 2_DETAIL: Is a view you can get to from the main screen by clicking on a cell.
Now assuming the implementation is (rough overview):
* MainView - appDelegate (holds UIWindow & UINavigationController)
* RootViewController - table view of the main items list (? variables here ?)
* EditViewController - input text to add to main list
* DetailViewController - shows detail of record
Question - Where to hold the NSArray that keeps the main list of items? Should it be in the RootViewController where the Table View exists that displays it? Or should it be higher up in the ApplicationDelegate? I note that when you go from RootViewController to EditViewController, then in this edit view you would have to ADD items to the array, so would it be easier for the code in the EditViewController to access the main array from the AppDelegate (as opposed to the RootViewController)?
(Note - still haven't made an app that has a specific model object, re MVC, yet, so not sure if this should come into the picture.)
Your data becomes the table view's data source, and although it doesn't have to, the view controller that contains the table view often does the data source's role. The view controller can also be a delegate for the EditViewController, so the EditViewController sends a message to it so it can update the array.
Apple's CoreDataBooks sample project show similar architecture. You may want to take a look.
Having the array in the application delegate is often not a great idea. Although it can give you a little bit of convenience, now your classes totally depend on your application delegate unnecessarily.
Your table view shows your data. This corresponds to View in the MVC design pattern. I assume RootViewController is the view controller of the table view, which acts as a Controller in the pattern. Your data, the location of which is not decided yet, corresponds to Model. The role of RootViewController becomes connecting the Model and View.
The ideal, or the reason of the MVC pattern is to isolate the model and the view, so the model can work with other views with appropriate controllers, and the view can also work with other models with appropriate controllers. For example, your RootViewController will provide the table view with data. It will specify the data in the language of table view, e.g. the number of sections and rows, the contents of cells, etc. If you want to present the data in a different way, for example a graph, your controller will access the same data (model) and provide the graph view with a different representation of the same data. The model need not change, neither do the views. You write only the controller, for each combination of a model and a view.
Ideally, therefore, you will have a different class for the model. In this class, you will store the array, and provide a general interface for controllers can interact with the data.
However, it's often not that necessary, either because it's unlikely that you will use the model class often again, or because the model itself is way too simple so it can be easily implemented anywhere. For example, if your data for the table is a simple array, an NSArray object is often sufficient for the model's role. Therefor, here comes an idea that to combine the controller and the model into a single object.
This is why it makes sense that your table view controller often acts as the data source of the table view.
However, storing the data in the application delegate is a completely different idea. Now the application delegate becomes your model, but which does not make sense, because the application delegate is only used for the specific application. Why would you have a separate model object that totally depends on a single application? Also, if your table view directly interacts with the application delegate, it means that now your view cannot work for other applications either because it now depends on the specific application's application delegate.
Often the reason why people are tempted to have data in the application delegate is, that the application delegate is easily accessible by any objects in the application by using [UIApplication sharedApplication].delegate. The M-V-C relationship is not always very simple. For example, your EditViewController also need to access the same model. To do this, you have to write some code to make the model accessible by both the table view and the edit view. If you have the data in the application delegate, you don't need to do anything, because you can magically access the array by accessing the application delegate.
But that's all. A few minute's saving in your coding time, for the price of ruining your software architecture. I'm not a fundamentalist, and I do sometimes use application delegate to store some data when I'm absolutely sure that it's not worth to provide well-formed interfaces, but it's rare.
So how should you connect your edit view to the data merged into the table view controller? There could be multiple ways. What I suggested before is let the edit view controller has a weak reference to the table view controller (delegate) and send a defined message, for example - (void)editViewController:(EditViewController *editViewController) didFinishEditing:(id) someData. In this way, you can use this edit view controller with some other view controllers as long as they use the same protocol. But others may implement different interfaces for it.
You need to store in the appDelegate,as you can acees the data in anyviewcontroller then.But if you use rootviewController,then you can only send data to next ViewController then,not to the 2nd or 3rd ViewController directly.
Hope it will help you.
Good Luck
I'm currently working on an app that uses a UINavigationController inside UITabBars. The tab bars correspond to both UITableViews as well as a Map View. However, the root view controller of the app is not the parent, or direct parent, of the UITableView custom controllers and map view controller. I also have a p-list that creates NSDictionary objects; it is the datasource that I am using to populate entries in the tables and the map.
So, without a root view controller, how should I create the NSDictionary objects from the data source? It seems to me that the easiest way is to simply recreate the object in each view controller for a view that needs the data. Because I don't have that many views and the p-list isn't that long, memory shouldn't be an issue. However, I do know that this is all very inefficient.
Is there any alternative implementation so that I don't have to recreate the NSDictionary in each view controller?
This tutorial featuring the singleton guide neatly explains everything:
http://www.cocoanetics.com/2009/05/the-death-of-global-variables/
My only worry now is if multiple view controllers each call the singleton, wouldn't they all be generating multiple instances of the NSDictionary, and couldn't that conceivably still take up a lot of memory?
You need a data model object that stores the data for application.
A data model is a customized, standalone object accessible from anywhere in the application. The data model object knows nothing about any views or view controllers. It just stores data and the logical relationships between that data.
When different parts of the app need to write or read data, they right and read to the data model. In your case, view1 would save its data to the data model when it unloads and then view2 would read that data from the data model when it loads (or vice versa.)
In a properly designed app, no two view controllers should have access to the internal data of another controller. (The only reason a view controllers needs to know of the existence of another controller is if it has to trigger the loading of that other controller.)
The quick and dirty way to create a data model is to add attributes to the app delegate and then call the app delegate from the view controllers using:
MyAppDelegateClass *appDelegate=[[UIApplication sharedApplicaton] delegate];
myLocalProperty=appDelegate.someDataModelProperty;
This will work for small project but as your data grows complex, you should create a dedicated class for your data model.
Placing the data in an init method or a viewDidLoad won't work because in a tabbar the users can switch back and forth without unloading the view or reinitializing the view controller.
The best place to retrieve changing data is in the viewWillAppear controller method. That way the data will be updated every time the user switches to that tab.
In practical terms, a data model is usually either placed in some kind of a singleton (either your own, or the app delegate which is a kind of singleton).
You should read up on Model-View-Controller (MVC) architecture. Specifically, you'll probably want to introduce a data model where you would create and populate the dictionary during initialization and then access it from all of your view controllers.