I have a doubt. I am building an application wherein if there is a new request is submitted I am getting a push notification in my application and on tap of "View" button in the push notification alert I need to show the request detail page. Now, normally this request detail page is 5th view in the stack. How should I handle this? Should I initialize first 4 views and put them on the stack before going to the detail page?
Also, there is a scenario where if someone is working on some part of the app and notification comes up. In that should I loose the changes on the currently opened page and show the request details if "View" was tapped on?
How should I handle this?
You can just push that view (the usual 5th view). The only thing is that when you pop that view, it will now act as the 2nd view, so theres no need to go through 4 additional views.
You can initialize and push the 5 views to your navigation controller (with animate:NO) to start the app up in the right place.
As for if you get a notification while running, that's really up to you and what is best for the app. You can always prompt the user before deleting any data. Note that if you get a push notification, your application:didReceiveRemoteNotification: instead of the alert showing.
This is commonly achieved by displaying the controller modally.
This way you don't have to recreate your view-controllers hierarchy and you don't lose the current context of your app if it was running. The user taps some "OK" button and returns to the previous screen.
For the first part of your question: if you have created your view in a decoupled way, that is, if it is not dependent on the 4 other views - i suppose then you can show this view without problems. Obviously the answer really depends whether your business rules allow this.
As for the second part of your question: you always can show an UIAlertView to your users asking whether they want to take action on the received push notification.
However - i think these problems really do not have anything to do with the nature of the push notifications, and you really should loose the "I have a doubt on push notification" part of your question :) ....
Hope this helps :)
Related
Is there a way to know in code when user has closed a modal by tapping the title? Apple's documentation states:
The title of the modal interface is set to the string Cancel unless the presented interface controller explicitly changes it using the setTitle: method. Tapping the title dismisses the interface automatically.
As far as I know there is now way to replace that title with a button.
I could fire a notification on didDeactivate() or willDisappear() but these will also be called when app enters background. So I could do an additional check in ExtensionDelegate's applicationWillResignActive() to differentiate between user's action in my app or outside my app but this seems very fragile.
Are there any better ways?
Why would one need this?
In my case I have an initial screen where a user makes a choice. After the choice is made I present screens that contain data based on that choice.
I always want to show the data when the choice has been made. So I save the choice and present the modal on app launch when it is present.
But I don't want to show the data if the user has closed the data display. Yet I still want to display the choice made on the first screen. So I can't use the fact that the choice has been made to trigger modal displaying.
Hence I need to know if the modal has dissapeared because of user interaction in app or because the app got switched away.
Unfortunately, there is no other way to do so.
But why do you need to add additional checks at applicationWillResignActive()? I think there is no need to do so.
I've been struggling with this for a while now.
And I've found some useful stuff, but I still feel like I've got the need to post here to hear peoples opinion.
Sometime I want to be able to send users to certain screens. If the app is reloaded I want to send them back to the screen where they left off and if they cannot be authorized anytime during login (if their password is changed elsewhere) I want to be able to kick them to the loginscreen.
To achieve this, I would add segues to all controllers from a "root" controller and then add segues from all controllers to the login controller. Then I could send them wherever with performSegueWithIdentifier.
BUT, is this really the way to go? Seems a bit inflexible and ugly. Is there a better way?
I would recommend implementing your login screen inside a UIWindow. This way you pop this window above any other view in your normal window regardless of where it is in the view hierarchy or modal.
I have a query regarding push notification.
Whenever a push comes and user is working on some XYZ controller and push requires another controller to be initialized and shown. Now should I show the push controller on top of the current active controller and take the user back to the currently working controller, once done?
What if the push controller has some actions involved and is a complete set of functionality associated with it. Should we restrict actions when a push comes.
What is the best deal?
It depends heavily on the flow and organization of your application. In a tab bar based application, you should have a tab for handling the notification activity, and place a badgeValue for the corresponding UITabBarItem. You could also show an alert offering the possibility of switching to the "handle notification" area on the other tab. Tab Bars are a good way of having "simultaneous" access to differing flows and switching back and forth between them without having to manage saving and restoring the VC flow yourself.
When my app receives a Push Notification, application:didReceiveRemoteNotification: receives the data. When the user open the app from a notification, I want to jump to the last UITableView in the stack, to display the 'details' related to the Push Notification.
I am able to jump to the correct tab in the UITabBar.
Is there a way to Push views in that Tab from the App Delegate, or am I going about this the wrong way?
If you're already able to jump to the correct tab, you're almost there.
One way to do it would be to save off the push alert information into nsuserdefault... maybe in a form of a dictionary object in the "didReceiveRemoteNotification". It's like of like save off a cookie web development for later use.
Then for the viewcontroller you're displaying in the tab that you jump to, you could do a check in viewWillAppear and see if you have anything stored in your nsuserdefault and grab the saved off notification data there and you can look up the corresponding data in your UITableViewDataSource.
Once you have that, you can call or do what ever you'd normally do had you selected the same data/object represented by a table cell and push the desired view (controller) into view.
Make sure to remove the object saved in NSUserDefault once you're attempted to push the view.
Sorry another newbie question that I couldn't seem to find an answer to on google. Guess I don't know how to describe it well enough.
On the calendar app for the iphone, when you go to add an event, if you select from the repeat, invitees, alert sections and so forth, you are brought to a screen with some choices for the field.
Is this simply navigating to a new view controller on the tap which displays these choices, or is there an pattern that you can implement for this out of the box?
It's just a garden-variety UITableViewController that's pushed onto the navigation controller's stack.
It's probably passed either a reference to the event object or a delegate it can send a message to to set the selected value when "Done" is tapped.