Best practice for View-Routing in iPhone SDK - iphone

I've run into a little problem while developing a Core Data driven Quiz and be a bit confused about a best practice to solve my problem.
I have approximately five templates for the different questions, which will be loaded in case which question is displayed. So I check which template has question 1 and push the new question-template view into my navigation controller. Because its always the same code I want to write a function (I came from php) which gets the next question-id as argument and decide which template will be loaded and push the next view into the navigation-controller.
What is the best practice to solve this problem? Can I write a function with access to the navigation-controller, and my Core Data classes. And if yes where I have to create this function?

Okay I think I found an way but gets here another Error. I create a class called QuestionRouter and define an class method. I'll import this class into each viewController where it needed. The class method gets the correct template from Core Data without an problem. But now I wan't to load the correct view. For that I need to access the navigationController defined in my AppDelegate.
So how I can access the navigationController in my AppDelegate for another class?
Hope for an answer.
Mister-D

Related

Retrieving data from database to a different view controller

http://www.techotopia.com/index.php/An_Example_SQLite_based_iOS_4_iPhone_Application_%28Xcode_4%29
I have found this sqlite tutorial on google and it worked great for my requirement.
In this tutorial both adding and retrieving data are done on the same viewcontroller. but i want that 'save' method in the tutorial in one viewcontroller and 'find' method in the other.
And also someone tell me whether this tutorial is an effective way to save data or not.because this is the easiest tutorial I found so far.
You might also create a new class ,or use inheritance (upper class) call it for example "SqliteClass"
that have both the 'Save' and 'Find' method
then you can use any method in SqliteClass from any other class ,,
in case you don't want to use inheritance make sure that the methods in SqliteClass are "class" methods the one begins with "+" not"-"
I used both ways and they work just fine ..
Hope that helps :)
Yes, you can to that. you can have n number of view and can save data from any view controller.
check this tutorial.
http://www.icodeblog.com/2008/08/19/iphone-programming-tutorial-creating-a-todo-list-using-sqlite-part-1/

Why we use app delegate in our application

I am new in iphone development and i needed a array which i use to access in different class so my senior told me that you should declare in App delegate and access it another class in which it require, so i wrote line for that
MyAppAppDelegate * appObject =
(MyAppAppDelegate*)[[UIApplication sharedApplication]delegate];
I done my task successfully but i couldn't get it 100%. Someone tell that why we use this and in what exactly situation in which we've to use this?
AppDelegate is loaded first when you run your application as it contains window. So, the variable and objects you want to access throughout your project is declared in AppDelegate. You just have to create an instance and you can access all the objects in AppDelegate.
ApplicationDelegate can be useful as a singleton class but you have to use it with discretion - and there are varying opinions on this - but if you have a few global type properties or methods you want to recall from various other classes, and I emphasize few, then ApplicationDelegate may be a nice place to add these.
And yes, it is bad design - but you can get away with it if you are prudent and as #Sedate Alien mentions, take a look at dependency injection.
The purpose of ApplicationDelegate, by the way, is mainly to handle events like loading your application, when you return to home screen, when you come back from home screen, etc.

iPhone MVC Question on table views and structuring custom class models

I have been reading a lot about MVC these days and I think I have my head around it but I would appreciate some advice and informed opinions on how to best approach my problem.
I have 3 questions really all related to the MVC design pattern.
In many of the examples I have encountered people have used the contoller (say of a Table view) to populate an array with objects of a custom class (say Student.h/m).
But shouldn't the Student class have methods that are called that would return an array of data for the variable in the controller? Isn't that how the MVC works? That the model holds the definition of the data and takes responsibility for reading and writing it?
In many table view examples, in the various books I have read, they all say, "for convenience we are going to make the controller our delegate and data source for the table". I have yet to see an example where table view does not use the controller as a data source. How would you hook up a table view to a different data source?
I have 2 model classes "mission" and "airfield". Each one of these needs data from a XML file in the cloud. Do I write the parser in the mission/airfield implementation files? Do I create a separate Parser object? Should these models retun data to the controller as an array?
Whilst I understand a lot of the theory a lot of the examples I find on the web seem to break a lot of the concepts I thought I understood.
Any explanations would be most welcome. The quality of responses on this site are amazing.
Thanks in advance
You seem to already have a pretty good understanding of how MVC works, so I'll just add a few comments.
The controller is responsible for feeding data to the view.
There could be a million different states and scenarios that would affect what data to use and how, and it's not the model's job to figure that out. The model holds the data, and the controller handles the logic.
If you need a different delegate or data source for your table view, you can instantiate them in the table view controller, and then tell the table view about them using the delegate and dataSource properties. They need to implement the required methods of the UITableViewDelegate and UITableViewDataSource protocols.
Sometimes models and controllers overlap in functionality, and this is a perfect example of such a case.
One solution could be to let the mission and airfield classes inherit from a custom class that knows how to download the required XML and set up a parser, so they just need to provide the URL and override the parser callbacks for their specific tags. Everything else related to downloading the XML could be handled in the super class.
Another way could be to create a separate class that takes a URL and returns some XML, and then the mission and airfield classes call that method and parse the XML independently.
The wrong way is to let both the mission and airfield classes know how to download and parse, because you'd have to maintain the code in both places.
It's OK to have a data loading controller, that hands over the data to the view controller, so the controller code can be very specific (and maintainable).

create a viewcontroller for each view screen?

Do you create a Viewcontroller per view screen? or should you share a viewcontrollers? (ie in the example below Should there be 3 controllers or just 1 controller?)
Example
Screens are related
Screen1 (input information),
Screen2 (Review and confirm Information),
Screen3 (thank you / status response).
You should code according to the MVC paradigm. Parcel out your code and separate it based on overrarching function. Here is a high level overview of MVC
(Data) Model: contains all of your app data, objects that are passed around and used to populate the views
View: everything that is some sort of visual output
Controller: Classes that make the models and views work together.
What this is saying, in iPhone development parlance, is don't just jam a bunch of code into your UIViewController subclass. If you want to change the way part of the system works, having one huge class with a ton of code in it is a lot harder to edit and fix, than several smaller classes with a specialized use.
To answer your question, you should most definitely use one controller for each view function, but going beyond that, you should create specialized classes that take the inputs and manipulate that data, create specialized classes that then use the data to send it back to the user in an output.
Don't put all of your code into one class. It might work, but if you ever need to tweak it, or, just like when the iPad came out, it has to be adapted to use on another platform, it will be easier to manage if you only have to change something small to make it work
In your case you definitely don't need separate controllers. In fact you don't even need separate views. You can create a single view to take information, process it in the same controller and show the result in a UIAlertView.

Where to store "global" data in Eclipse RCP Application?

I'm a beginner with Eclipse RCP and I'm trying to build an application for myself to give it a go. I'm confused about how one actually goes about handling model objects. None of the examples I can find deal with the problem I'm having, so I suspect I'm going about it the wrong way.
Say I need to initialise the application with a class that holds authenticated user info. I used my WorkbenchWindowAdvisor (wrong place?) to perform some initialisation (e.g. authentication) to decide what view to show. Once that's done, a view is shown. Now, that view also needs access to the user info I had earlier retrieved/produced.
The question is, how is that view supposed to get that data? The view is wired up in the plugin.xml. I don't see any way I can give the data to the view. So I assume the view has to retrieve it somehow. But what's the proper place for it to retrieve it from? I thought of putting static variables in the IApplication implementation, but that felt wrong. Any advice or pointers much appreciated. Thanks.
The problem you are facing here is in my opinion not RCP related. Its more an architectural problem. Your view is wired with business logicand!
The solution can be done by two (common) design-patterns:
Model-View-Controler (MVC)
Model-View-Presenter (MVP)
You can find plenty information about this in the web. I am going to point a possible solution for your particular problem using MVP.
You will need to create several projects. One is of course an RCP plugin, lets call it rcp.view. Now you create another one, which doesnt make UI contributions (only org.eclipse.core.runtime to start with) and call it rcp.presenter. To simplify things, this plugin will also be the model for now.
Next steps:
Add the rcp.presenter to the
dependencies of rcp.view (its
important that the presenter has no
reference to the view)
Export all packages that you are
going to create in the rcp.presenter
so they are visible
In rcp.presenter create an interface
IPerspective that has some methods
like (showLogiDialog(), showAdministratorViews(User user), showStandardViews(User user))
Create a class PerspectivePresenter that takes IPerspective in the constructor and saves it in an attribute
In rcp.view go to your Perspective, implement your interface IPerspective, and in the constructor create a new reference presenter = new PerspectivePresenter(this)
call presenter.load() and implenent
this in the presenter maybe like this
code:
public void load()
{
User user = view.showLoginDialog(); // returns a user with the provided name/pw
user.login(); // login to system/database
if(user.isAdministrator())
view.showAdministratorViews(user);
else
view.showStandardViews(user);
}
As you can see, the view just creates a reference to the presenter, which is responsible for all the business logic, and the presenter tells the view what to display. So in your Perspective you implement those interface functions and in each one you can set up your Perspective in a different way.
For each View it goes in the same way, you will need a presenter for the view which performs operations and tells the view (using the interface) what to display and passing down the final data. The view doesnt care about the logic. This is also very usefull when using JFace-Databindings (then only bound data is passed to the view).
For example, the WorkbenchWindowAdisor will just create everything that is needed in the application. Other views, perspectives, then can enable/disable menus and so on depending on the data they got (like when isAdministrator you might want to enable an special adminMenu).
I know this is quite a heavy approach, but the Eclipse RCP is designed for big (as the name says rich) applications. So you should spend some time in the right architecture. My first RCP app was like you described...I never knew where to store things and how to handle all the references. At my work I learned about MVP (and I am still learning). It takes a while to understand the concept but its worth it.
You might want to look at my second post at this question to get another idea on how you could structure your plugins.