I have a tab-bar and navigation controller application (like Youtube app or Contacts app).
Where is the correct place to have the code for loading some data from the web? These data are necessary for all the tabs of the Tab Controller and the app can't display anything before all data are downloaded and parsed from the app (except a loading indicator view of course).
Up to now I put it in the AppDelegate but it somehow doesn't feel right..
What's the correct way to do it?
Thanks!
For a simple application, doing this in the application delegate is okay. I would probably do it in my main view controller, however. I would also probably put some defaults on those tabs so that the user sees something there, even if there is no internet connection (although this may vary between apps, and may not be appropriate in your case).
The most important thing to remember is that wherever you start loading this data (whether it's in the app delegate or your controller's viewDidLoad method), you should kick-off whatever downloads you need and establish whatever notification system is appropriate and return as quickly as possible. I.e., don't block in either of these delegate methods.
In general, though, since it sounds like this data is related to the display you are creating, it's probably appropriate to contain it's loading inside the view controller itself.
Related
On the MVC paradigm, a view can only communicate with a controller, and via a blind communication (target-action or delegate/dataSource). I understand that, but is it a violation of MVC if a view communicates with another view, using a delegate?
Almost always. The delegate of the view should never be another view. It should be a controller. The controller is the appropriate place to drive changes in the other view.
A view should almost never say something that another view would care about. A view should say to its delegate things like "I was touched." Why would another view care? It's up to the controller to say "ah, a touch here means that I should move the active focus. I should tell the current active view to let go of focus" (as an example). I view is not responsible for determining what events mean in the broader application, only what events happened, and so are very unlikely to generate messages of interest to other views.
My opinion on this is to use the observer design pattern and simply use notifications (NSNotification)
I am a novice myself. But I would think that it's not. A jsp page when called could just redirect you to anothr jsp page. I have seen that happen sometime. So I guess it is in a way, a view calling another view.
I have a simple iPad application with 5 views. On the first view, the user is asked to make some selections and set some options. From this information, the other 4 views are programatically changed after an NSNotification message is sent to them. (i.e controls are added, updated).
My problem is that when the application is first loaded, the user sees View1, but View2, View3, View4 and View5 have never been opened yet, so any changes I make programatically to those views are not done and when the user navigates to them (via the tab bar) for the first time, no changes are shown.
[EDIT: I should point out that the code for making the changes to each view is contained within the ViewController itself, and is executed when the view observes the incoming NSNotification. When the view is not loaded, it understandably never received the incoming NSNotification.]
Only after the user looks at any of those screens at least once and then goes back to View1 and makes changes, are the other Views updated properly.
I thought I could get around this issue by actively loading Views 2,3,4 and 5 into memory on application start, so that they are ready to begin receiving notifications right away.
Is there an easy way to do this in iOS 5?
Why do the view changes straight away?
I would store an indicator of the changes needed when the users answers the questions on the first view and then apply the changes on -viewDidLoad of each view that needs to be changed.
Instead of trying to load the views into memory, I'd suggest you initialize these views with the options that the user set on the first view. What I usually do in such situations, when I have a global parameters that are used in many places, I create a utility class to keep the data, make it a singleton, then access the shared instance in the viewDidLoad in the views that use the data during initialization.
I would like to create an utility application that has a navigation based flipside, or "info", view. What would the most efficient way to accomplish this be? I think that i 'simply' need to make a root view controller for the flipside view...but i really only understand that conceptually...not so much how to go about it or, at least, i am not confident that i know how to go about it.
I apologize for the slightly "make my app" nature of this question i have books and books and books...but it shakes out so much differently when i want to make my own project.
You can use a view controller for the flipside view, or you could create / load a view in your app delegate. In the latter case, you can set up the delegate to respond to the info button press, and then set up a transition to the new view which will have a button (which the app delegate also responds to) that transitions back to the previous view.
There is a basic tutorial I found for this here:
http://www.iphonedevsdk.com/forum/iphone-sdk-development/12222-how-do-i-create-uiview-flip-animation.html#post104474
It should be able to at least get you started.
Specifically, I have something like a game, with a menu screen made out of standard components. I want a button to switch to another view controller that the user will interact with for a while, then return to the menu screen. It seems like having the menu controller present the 'game' mode as a modal view controller is the most straightforward solution, but is this the best way to essentially replace the entire view? Is the whole menu (which may later become a deep nav or split controller) kept in memory as long as the modal controller is in front, and is this something I should bother to worry about?
There are really two parts to this question:
Which method of transitioning from one view to the next in an iPad application provides the best experience to the user?
Which method of transitioning from one view to the next is easiest to implement and best handles memory management?
I'm not going to try to address the first part of this question other than to point you to Apple's 'iPad Human Interface Guidelines' which says (among other things):
Reduce Full-Screen Transitions
Closely associate visual transitions with the content that’s changing. Instead of swapping in a whole new screen when some embedded information changes, try to update only the areas of the user interface that need it. As a general rule, prefer transitioning individual views and objects, not the screen. In most cases, flipping the entire screen is not recommended.
When you perform fewer full-screen transitions, your application has greater visual stability, which helps people keep track of where they are in their task. You can use UI elements such as split view and popover to lessen the need for full-screen transitions.
http://developer.apple.com/library/ios/prerelease/#documentation/General/Conceptual/iPadHIG/DesignGuidelines/DesignGuidelines.html
However, in your case I'd have thought a full-screen transition is entirely appropriate (but then I'm not a user experience expert).
In answer to the second part, yes displaying a new view controller modally seems like a good approach to take.
By default both the objects used by the menu view and those used by the modal view will be kept in memory - but the great thing about using UIViewController sub-classes is that they've got some default memory management built-in. If your application receives a memory warning whilst the modal view is being presented in full-screen mode, the menu view controller's views will be removed and it's 'viewDidUnload' method will be called. So in your implementation of this method you should release any objects you don't need and then recreate them as needed in the menu view controller's viewDidLoad method (which will be called again before the menu view is shown).
This is explained in more detail in the UIViewController class reference:
When a low-memory warning occurs, the UIViewController class purges its views if it knows it can reload or recreate them again later. If this happens, it also calls the viewDidUnload method to give your code a chance to relinquish ownership of any objects that are associated with your view hierarchy, including objects loaded with the nib file, objects created in your viewDidLoad method, and objects created lazily at runtime and added to the view hierarchy. Typically, if your view controller contains outlets (properties or raw variables that contain the IBOutlet keyword), you should use the viewDidUnload method to relinquish ownership of those outlets or any other view-related data that you no longer need.
http://developer.apple.com/library/ios/#documentation/uikit/reference/UIViewController_Class/Reference/Reference.html
I am new to iOS developement, and i am trying to understand the whole cycle of iOS application developement, and i feel there's a missing part i just don't get it..
if the MainWindow.xib that is generated automatically by Xcode has a view that loads another xib/nib view inside it, then why we use it ?
Your application needs a window so the system can display it to you on the device screen. In the window are various views which represent different areas of your application that users can interact with. Views can either be entire user interfaces, or individual UI controls.
The main window interacts with your application delegate to handle events that your application receives through the views.