After a navigation has started, user has an option to switch between screens.
There are two screens with two different maps - one showing navigation and another showing some POIs.
Whenever screen is changed, new delegates are set and [SKRoutingService sharedInstance].mapView is set to the map view of that screen.
Everything works fine, only thing that happens and I want to avoid it - when I go back to the initial screen, the navigation starts from the start again (I was testing this in simulation mode on an iPhone 6 so far).
This happens when I set delegate
[SKRoutingService sharedInstance].routingDelegate = self;
If I don't set the delegate, on return to the main navigation screen, navigation will continue from the position it is intended to, but all the navigation delegate methods will not function.
However, if i set this delegate, navigation will start from the starting point.
How to avoid this ?
Currently, the "navigation" part is shared between all instances of the map - if you start the navigation in one instance, one you switch to another instance then you'll still have the navigation perspective. If you stop it in one view, it will stop across all instances.
What you could do is switch the map do 2D and enable panning - this way you'll still be able to interact with the map (zoom to your POI) and still have the navigation on.
Something similar to what happens in the demo project in the "Car navigation UI" demo when you start panning the map (after starting navigation).
You could really ask this question better. It's hard to understand what the question is about on first reading.
Having said that, it sounds like you're using a 3rd party routing framework, and setting that routingDelegate property has an unintended side-effect (of restarting the navigation). To avoid this, I'd create a new object that should be the routingDelegate all the time. Then this object can notify any other objects that need to know about routing events. This way, you avoid the side effects that are triggered by setting the routingDelegate.
Related
I have been asked this question many times in the interview searched every where didn't get any proper answer.So finally posting this question here.
You may go through this.
Yes, you can have multiple windows. A key window is the one who receives the user input.
Starting with Rob's answer I played around a bit and would like to write down some notes for others trying to get information on this topic:
It is not a problem at all to add another UIWindow. Just create one
and makeKeyAndVisible. Done.
Remove it by making another window
visible, then release the one you don't need anymore.
The window that is "key" receives all the keyboard input.
UIWindow covers everything, even modals, popovers, etc. Brilliant!
UIWindow is always in portrait implicitly. It does not rotate.
You'll have to add a controller to the new window's root controller and let that handle rotation.
(Just like the main window) The window's level determines
how "high" it gets displayed. Set it to UIWindowLevelStatusBar to have it cover everything.
Set its hidden property to NO. A 2nd
UIWindow can be used to bring views on the screen that float on top of everything. Without creating a dummy controller just to embed that in a UIPopoverController.
It can be especially useful for iPhone where there is no popover controller but where you might want to mimic something like it.
And yes, it solved, of course, my problem: if
the app resigns activation, add a cover window over whatever is
currently shown to prevent iOS from taking a screenshot of your
app's current content.
Generally one application require only 1 UIWindow, but still there may be some scenarios where you need to use multiple UIWindow in one application.
For example, you wish to show a view on the top of system AlertViews, or can the default Keyboard.
UIWindows are the special UIViews, for which their display order is controlled by .windowLevel property.
You don't need to add a new UIWindow as a subview of any of view. You can simply create a new UIWindow and call either window setHidden:NO or window makeKeyAndVisible depend on the level, you have given to it.
There are three default window enum levels defined:
UIWindowLevelNormal
UIWindowLevelStatusBar
UIWindowLevelAlert
Of course it can have multiple windows. Just, only one to be displayed at a time, that's the keyWindow. You can have multiple windows stored in array or whatsoever, and make them keyWindow when you want to display them.
And, yeah, read the documentation #Mannopson suggested, it's very useful.
I want to build some analytics into my app and I would like to send some data when user leaves current screen, though there are multiple ways he can do so (back button, other button, sidebar menu, etc). Is there any efficient way to do this? I really don't feel like implementing it to every possible button that can lead the user to different screen.
You should call your function inside viewWillDisappear, which is called every time the current view controller is about to disappear from screen. See the documentation of viewWillDisappear
Also see the view controller life cycle (thanks #Paolo for the tip) below (documentation).
I'm currently working on an iOS app that is pretty much supposed look and work like an already existing android app.
As a part of that, I'd like to make the top navigation look the same, but since iOs devices do not provide a hardware or software integrated back button, I'd also like to keep the back button navigation that's common to iOs apps.
I've tried numerous attempts to achieve it, but I'll stick with the latest I'm working on since it looks the most promising. I've started to work on a custom UINavigationBar class that overrides the initWithCoder: and layoutSubviews: methods. The result is as follows:
As you can see, the back button now overlaps the application icon. What I'm looking for is a way to make the button and the text to scale into the space right of the application icon. I've tried to handle this in layoutSubviews: but the superclass logic appears to be rather complex, I was not able to reproduce it's functionality (in particular it seems to be working with some private variables I don't have access to).
I also tried manipulating self.frame before calling [super layoutSubviews] but apart from endless loops I was not able to achieve anything in that direction.
I'd be happy if anyone could point me into the right direction.
If I understand your problem correctly, I think you could do this by adding a custom titleView to the UINavigationItem, and have an image view (on the left side for the icon) and a label (for the title) as subviews. This would replace the default title.
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.