In my application, I am having 5 viewControllers. In which I have 4 web services call. While going from 4th controller to 5th controller, there is no web service, Still taking so much time to load.
What could be the possible possible reasons?
My observation :
View controller is coming to viewDidLoad very late.
Storyboard should the issue.
Once I am removing custom fonts from some labels, it is working fine.
In my case, the font assigned to control(s) was wrong.
ProximaNovaSoft-Semibold font was assigned to controls, but this font did not exist. The real font was Proxima Nova Semibold.
Because ProximaNovaSoft-Semibold did not exist, the system took time to search for this font causing a delay.
After I corrected the font for some of my controls, it loads fast.
You can check against some potential cases:
In VC4, are you doing something in viewWillDisappear or viewDidDisappear?
Make sure you are loading data asynchronously in VC4?
Are you doing something bulky in viewWillAppear in VC5?
If you go from VC1/2/3 to VC5, does it still take a lot of time?
Related
So in an iOS app I'm using a UINavigationController as the root view controller. I then push a few ViewControllers on the stack, let's call them A, B, C and D.
Now if I try to pop D from the stack, I sometimes * run into the following problem:
After calling popViewControllerAnimated, the view of the topmost view controller (D) remains. If I display the stack however, it is displayed correctly, i.e. A-B-C is displayed and D is gone. The pop method seems to do just what it's supposed to but the view does not reflect this.
I have tried various other approaches, (popToRootViewController, popToViewController) instead but the behaviour doesn't change (i.e. the stack is printed correctly but D's view remains). I have called setNeedsDisplay on all views that seem to make sense.
After popping D, I can still push and remove other view controllers. The stack reflects those changes, the view does not. Also, D's view remains responsive, i.e. it is not frozen and the app does behave correctly in the background. All views are very simple, there are no tabbed views or the like, just a couple of labels and buttons.
I have read a number of posts on SO and elsewhere about people having similar problems but none of the solutions seem to fit here. Does anyone have an idea why this happens?
*_ I haven't been able to figure out under which circumstances exactly. I first thought it was because I am popping D very soon after pushing it, but it also occasionally happens when there is more time between push and pop.
Only reason i can think of where this might happen is if you are not doing that in a main thread. If you are doing it after some network call, then do make sure you are going back to main thread. Sometimes, app won't crash if you do UI work on background thread but rather will behave like what you are seeing!
The problem seems to have been one of timing. As I mentioned, the push and pop operations (of D) sometimes do happen rather quickly after one another. Adding a delay of 2500 ms solved the problem. Adding 500 ms did not (always). Since neither is acceptable to me, I switched to a custom container view controller and therefore didn't spend a lot of time on figuring out what the minimum delay would be.
Just as sidenote: Changing from dispatch_async to dispatch_sync didn't have any effect. The delay seems to be necessary either way.
Thanks for everyone's help. I'm going to close this thread - if someone can provide a more complete answer as to why things are the way they are, please post it and I'll mark it as the correct answer then.
I am working on an ipad project whose UITabBarController (it's also the root) has 5 tabs.
The second tab is a tableview where there are quite rich UI elements.
The problem is that everytime I launch the app and click the second tab, I would be blocked for 0.3 second to show the viewcontroller. However, after the first time enter this tab, it only takes me 0.03 to enter this tab again.
So I thought the ViewDidLoad cost too much, because I do a lot addSubView or reloadData there. So I add
[libraryVC viewDidLoad];
[libraryVC viewWillAppear:YES];
[libraryVC viewDidAppear:YES];
in application:didFinishLaunchingWithOptions, I think if I do this view load stuff before user enter the second tab, then there will be no block.
However after I tested this approach, I found the cost was not be reduced. So I guess the time cost may be used in the view render when first show this viewcontroller. When the viewcontroller's view has been rendered before, then the following show will be fast. But I have no idea to solve this problem.
I think this problem is very common when the viewcontroller's view is really complicated, so does anyone has an idea of the approach to solve this problem? Or does anyone can give a detail description of the reason why the block happens?
Thanks for any help!
Perhaps multithreading the time intensive methods/calls is the solution you are looking for. If you search "ios grand central dispatch" on Google, some great resources will be available. Apple's Grand Central Dispatch reference is one of the better pieces of documentation they have.
My question is similar to this one, but not exactly answered there.
What I want to do, is to convert an existing navigation-based app with different UIToolbars at the bottom of the individual UITableViews into an app that has a UITabbar interface. One of the tabs shall show the same hierachy of UITableView data as the existing app (which displays some kind of hierarchical data), whereas the others will be assigned something else (say: Settings, Help, ...) that is of no concern here. The idea is to allow the user to quickly switch to the "Help"-Screen from whatever stage of the navigation stack - and back.
For example, using 3 Tabs:
1. Database root (UIToolbar) - folder 1 (UIToolbar) - file 1.1
- file 1.2
- folder 2 (UIToolbar) - file 2.1
- file 2.2
2. Help (no UIToolbar)
3. Settings (no UIToolbar)
I have never seen such a design in any existing app, although the question cited above suggests that it might in fact be possible to keep the existing UIToolbars from the old app and simply place them above the tab bar.
Is this
technically possible (without problems e.g. with device rotation)?
allowed by Interface guidelines?
Although sample code would be appreciated, I mostly would like to find out whether it is worth trying to build an app like this - or whether such a design is a bad idea in the first place.
You can have a UITabBar anywhere, you just won't be using its controller. You will have to write your own controller and handle what happens during device rotation (or use iOS 6's auto layout features).
I tried it out, and now I can answer my own question:
It's possible, and there are no problems with device rotation, if you make sure that the views for every single tab can rotate.
Although it looks a bit unusual, I find it very usable. Of course, it costs some vertical space.
As for the implementation, I found it to be surprisingly simple:
All I had to do was to use Interface Builder to insert a UITabBarController in place of my original main UIViewController and move the latter to the first tab of the former. Then create some more tabs with UIViewControllers inside and rename their classes to those of my other existing UIViewControllers. Finally set the associated NIB-Files for all these controllers manually in the relevant interface builder inspector pane (because they are now no longer instantiated by my code) and change one single line of code to make the UITabBarController the root controller.
Result: the UIToolbar appears above the UITabbar for the first tab, but not for the others. Its position is fixed (when scrolling a list or similar), but it autorotates together with the tab bar and everything else.
I'm writing an iOS app that has a problem on a view that's about 4 taps deep into the UINavigation stack. It's becoming a pain to have to repeatedly tap tap tap through the simulator to drill down to the UIViewController I need every time I want to run the thing.
Is there a way to automate this?
I tried just instantly calling [self tableView:self.tableView didSelectIndex... manually, however that blows up because data hasn't been loaded into the table yet...
I'd prefer something fast w/o a lot of overhead to it - otherwise it'll take more time to implement the solution than I'd save by not tapping the screen 4 times...
Thanks for any insight you guys can provide.
I do this all the time - in the appDelegate, I just add some code wrapped in a #ifdef that just makes the subview the initial view of the navigation controller. Once you get the subview working you can turn the ifdef off. Using the technique will save you lots of time - in fact I'm using it right now to add functionality to my app in the store.
I have always been a bit unclear on the type of tasks that should be assigned to viewDidLoad vs. viewWillAppear: in a UIViewController subclass.
e.g. I am doing an app where I have a UIViewController subclass hitting a server, getting data, feeding it to a view and then displaying that view. What are the pros and cons of doing this in viewDidLoad vs. viewWillAppear?
viewDidLoad is things you have to do once. viewWillAppear gets called every time the view appears. You should do things that you only have to do once in viewDidLoad - like setting your UILabel texts. However, you may want to modify a specific part of the view every time the user gets to view it, e.g. the iPod application scrolls the lyrics back to the top every time you go to the "Now Playing" view.
However, when you are loading things from a server, you also have to think about latency. If you pack all of your network communication into viewDidLoad or viewWillAppear, they will be executed before the user gets to see the view - possibly resulting a short freeze of your app. It may be good idea to first show the user an unpopulated view with an activity indicator of some sort. When you are done with your networking, which may take a second or two (or may even fail - who knows?), you can populate the view with your data. Good examples on how this could be done can be seen in various twitter clients. For example, when you view the author detail page in Twitterrific, the view only says "Loading..." until the network queries have completed.
It's important to note that using viewDidLoad for positioning is a bit risky and should be avoided since the bounds are not set. this may cause unexpected results (I had a variety of issues...)
This post describes quite well the different methods and what happens in each of them.
currently for one-time init and positioning I'm thinking of using viewDidAppear with a flag, if anyone has any other recommendation please let me know.
Initially used only ViewDidLoad with tableView. On testing with loss of Wifi, by setting device to airplane mode, realized that the table did not refresh with return of Wifi. In fact, there appears to be no way to refresh tableView on the device even by hitting the home button with background mode set to YES in -Info.plist.
My solution:
-(void) viewWillAppear: (BOOL) animated { [self.tableView reloadData];}
Depends, Do you need the data to be loaded each time you open the view? or only once?
Red : They don't require to change every time. Once they are loaded they stay as how they were.
Purple: They need to change over time or after you load each time. You don't want to see the same 3 suggested users to follow, it needs to be reloaded every time you come back to the screen. Their photos may get updated... you don't want to see a photo from 5 years ago...
viewDidLoad: Whatever processing you have that needs to be done once.
viewWilLAppear: Whatever processing that needs to change every time the page is loaded.
Labels, icons, button titles or most dataInputedByDeveloper usually don't change.
Names, photos, links, button status, lists (input Arrays for your tableViews or collectionView) or most dataInputedByUser usually do change.