Can an app delegate act the as the glue between all my UIViewControllers for the whole app?
I'm creating a mail client that has a navigation structure very much like sparrow (and fb etc). The first screen would be a login screen.. which would then lead to a UITableViewController that has the famous left menu button, which if clicked reveales other VC's underneath.
To make a long story short, right now it's my app delegate that's running the show.. it's the one that decides if to show the login screen if on first visit, or the default mailbox along with its subviews. If I get information from one subview, it hands off that info to the app delegate, which in turn passes it on to other view controllers.
Is this right from an MVC point of view? I know an app delegate is the first point of contact, it's what kicks off the application, but I haven't seen it used this extensively. I just want to make sure if I'm following iOS MVC best practices here.
It's not recommended, but it's perfectly legal to do that. I generally use a master view controller class and do most of the heavy lifting in that. Keep in mind that XCode will dump most of the auto generated code in the app delegate if you are using Core Data, so it can get a little difficult to navigate if you are using Core Data. It's really just a personal preference though. If it were me, I would still have the app delegate do the login screen vs. main screen logic, but put most of the app logic in a main screen controller.
Related
I'm an Android developer, I started learning iOS development lately and I've been wondering about how to manage the UIViewControllers.
In Android, when you don't need an activity anymore, it is better to remove it from the application stack, for example a login screen is only needed when the user logs in, after that there is no need for that screen so it is better to destroy it and remove it from the stack, but what about iOS? Do you have to manage view controllers the same way as activities? or does the system automatically handle the views in the background?
It would be great if you can link some reference to read more about the way View-controllers are handled in the background, I'm trying to learn the best practices
Short answer: No, let ARC handle it
ARC handles the release from memory automatically when you pop a view from a navigation stack, so if you go "back" (pop) you normally don't need to worry about it.
But, sometimes you have a big navigation stacks with many different views with a lot of data/images/etc that will eat memory. In those cases you could separate your app into different flows and instead replace the root view controller of the main window with the new flow every time you want to change. The old flow should be released from memory automatically, unless its connected to another object (like a singleton).
Everyone has seen the classic didFinishLaunchingMethod run amok.
Well now that we have additional things to consult when starting up like CloudKit, that are, to make things worse, asynchronous, the app delegate seems like the wrong place to do even the most basic stuff like asking if they have accounts and establishing syncing, or grabbing a snapshot.
I hate the idea that those things would go into the first controller that the app would launch, flashes me back to 4GL tinkertoys from days of yore.
Yet, we have to honor the flows of the storyboards. I have found nothing searching around on this. And sadly the most extensive Apple example, Lister, is not a great source for best practices.
It's suitable for the app delegate to trigger the start of this work, but not to handle the results. Often you want some way to display progress / errors / request user info. So, having some form of 'splash' view controller which handles the transition from your launch image into this process and controls the flow into the main app is handy. Generally the logic for this kind of thing is reusable in other situations so that part should be in some other controller class. The storyboard can make the splash VC the initial controller and the app delegate can create and pass it the data controller class which deals with the logic and updates the VC (it's delegate) with the results. Often the splash VC will then pass the data controller on to the subsequent VC it displays, though that isn't required of course.
Here is context for my question, this is an optional read:
I have to develop an app for a
school project. At the end of the year some people I don't know will
listen to me presenting my app, and review my presentation and my app
(note that they will probably not be app developers, they are usually
IT professors) (note also that I'm allowed to ask for help to anybody,
and I can use internet since I do this mostly on my "free time")
So since October I'm developing my app, that takes a lot of time
because this is my first app. And here comes the issue:
My app is a giant Scroll view with 5 NavigationsControllers, each containing a ViewController. These ViewControllers sometimes have buttons that leads to an other ViewController. The problem is when I use these buttons, and another view controller is displayed, when I swipe right or left the ScrollView scrolls and another ViewController from the scrollView is displayed. I don't want this to happen because most of the time the ViewController displayed after the tap on a button is not meant to stay, it's generally a form to send data to the server.
As I think this is difficult to understand, you can download the project on Github
Is there a way for me to disable scroll on chosen ViewControllers? or should I change everything to avoid using a ScrollView?
Bonus question:
Is it a really really bad idea to make an app this way, or did I just miss something?
Thanks for your help!
I have a messaging system, theres a inbox view and a viewmessage view, if i go back to the inbox im still reciving data from that message, and if i load another conversation between me ad another user its still loading the previous conversation data i had (verified by logging the convo's, and the new one i have open, and its a continuous loop so to say... basically im trying to figure out how to totally close out a view... i seen dissmissViewController and used that, but all it does is visually make the view go away... it doesn't truly close it.. whats the method to call to do what im trying to achieve?
These are all modal views, my app uses no navigation views due to the nature of the app
edit: i found some great documentation that im going to look over hopefully i'll get my answer from there.
Using Delegation to Communicate with Other Controllers
I am working on an app in which there are several screens and each screen has the same layout, just different data passed in, then I want the user to be able to swipe from one screen to the next.
So far I got something working using the UIPageViewController project template using the transition style UIPageViewControllerTransitionStyleScroll. What I have done so far works ok, although its resource intensive because it instantiates a new view controller each time I swipe to a new page but I am loooking into working around that.
The thing I am concerned about is that it is not strictly a page application in the sense of ibooks so even though I am able to make it look like a scrolling app, using the transition style setting, I wonder if there is a reason why people seem to only use this template for book type apps, unless I am mistaken
Also there seems to be an alternative approach of using a UIScrollView and PageControl to do similar functionality
http://developer.apple.com/library/ios/#samplecode/PageControl/Introduction/Intro.html
I am not sure which approach is better to solve the problem I am trying to fix, so am looking for some feedback. Each page will need to be a separate instance of a view controller as there are several elements to display on each page.
Using UIScrollView is much more difficult. If you're targeting iOS 6 you should almost certainly use UIPageViewController. If you're targeting iOS 5 then UIPageViewController might not be perfect because the only page transition available is "scroll" which looks like a page flip.
If you're worried about the resource usage, you can reuse view controllers.
See the WWDC 2012 session 223:
https://developer.apple.com/videos/play/wwdc2012/223/