In my app I have two tabs. The first tab just controller with some functions.
The second tab has MapView with showUserLocation property YES.
As I know in general UIAlert message "app would like to use your current location" is displayed when app is launching, but in my raw app this message has time when I do the firs tap on my second tab.
Would you clarify me how can I manage this issue?
P.S.Sorry, but I didn't find any info about.
Thanks
It's actually better to only request location access when it's necessary. In many apps, some users might not even use the location-based features. Having it only pop up when they hit the second tab is perfectly fine.
Related
I'm using xcuitest framework to automate mac application. I get system dialogs when the app is opened again after it crashes. I want to handle the dialog programmatically. But the dialog appears under the process `UserNotificationCenter' instead of the application under test. How can I handle the alert in such case?
You have two options:
Use InterruptionMonitor (documentation, use-case). This
approach is however kinda old and I found, that it does not work for
all dialogs and situations.
Create a method, which will wait for some regular app's button. If the app's button (or tab bar or other such XCUIElement) is visible and hittable after your app started, you can proceed with your test and if it's not, you can wait for the UserNotificationCenter dialog's button and identify&tap it by its string/position.
I'm using the second approach and its working much better, than the InterruptionMonitor. But it really depends on your app layout and use-case.
You should be able to revent it from appearing in the first place. Something like:
defaults write com.apple.CrashReporter DialogType none
I'm working on a custom app for a client and am still relatively new to iOS development. The app involves setting reminders and I'm using UILocalNotifications. Now from my research the action on the notification will always run the app but I'm really hoping someone can correct me on that. Also from what I've read you are limited to the 'View' or 'Close' options. Ideally I'd love to have 3 buttons on the notification and not have to open the app to perform an action.
I'd like a 'dismiss' option, 'snooze' option, and an 'ok' option that dismisses the notification but runs some code in the background.
I came across a notification related question where somebody suggested opening the app with a modal view and presenting the options from there. Possible, just not as clean, I guess.
Any other ideas or is this what I have to do to achieve my desired functionality? If that's the case is there a way to close the app after I've selected one of my options from the modal view?
Thanks in advance.
That is not possible, as the notification is not created by your app but by the system, so you can't customize the appearance of the notification. (also in iOS 5, the user can choose to display the notifications as banners instead of alerts, which would hide any other button than the view and close button, if that were to be possible).
Secondly there is no way to close your app, as iOS is a user centric system, where the user takes the decision on whether to open or close app, and not the app itself.
in my app I need to create a bunch of UIAlertView popups expecting user to respond to each of them at some moment of time. By definition UIAlertView is non modal, i.e. the logic of my app continues to execute after making them. When the app would go into background would the popups be automatically saved? It looks like when user responds by clicking the button, correct popup responds even after app goes into bkgr and comes back. Does it mean that the UIAlertView popup ptrs are preserved during save/restore, ie can be reused after restore, OR, there is some mangling done to support clickedButtonByIndex:alert referring to correct popup?
Thanks. Victor
UIAlertView inherits from UIView, as does say a scroll view. These user interface elements are all "saved" when your app goes into the background, and are not mangled in some way. When your app comes back into the foreground all your UI elements work the same.
FYI, this behavior has changed in iOS 4 (in the unlikely event that you're trying to support pre iOS 4): See the "Important" note in the "Overview" section of the UIAlertView documentation.
But, yes, your app is preserved, unless iOS has to shut it down, in which case all bets are off.
So my app was rejected (it has been approved every other time i have put it in for review and I hadn't touched this code path in ages) or this line:
[myAlert addTextFieldWithValue:nil label:NSLocalizedString(#"Name",#"Name")];
Apparently addTextFieldWithValue:label:
is a private API...
so how are we supposed to put a UITextField inside an AlertView?
Can someone help?
Consider using a modal view controller, instead. No risk of app rejection.
You don't. Alert views are for displaying alerts only. Apple uses them to display text fields sometimes, but that's their prerogative (since they wrote the HI guidelines and all).
Find a different approach in your UI for prompting the user for data. This is a mobile platform, not a desktop. Using popups like this for information gathering on such a platform is usually inappropriate.
In the iPhone application I'm developing, I have a need to return the user to the previous screen they were using when, for instance, the application was interrupted by, say, a phone call.
The application is driven by a navigation controller, and the user may be several layers deep into the application. As such, I think that I need to traverse the navigation controller logic to bring the user to the point that they were previously at, with all return navigation logic n place.
I'm comfortable that I can force the application to navigate down to the required level through code, but I would like to hide the screen switching and animations that would occur while this is going on, thus presenting the user with (apparently) a direct path to their last used screen, rather than showing them the underlying navigation that's occurred.
Could somebody please point me to some method of suppressing the intermediate displays?
Does anyone have other methods to perform this sort of task?
Thanks in advance for all suggestions.
I suggest you take a look at the Three20 project which contains a feature called "URL-based navigation", which might help you, since you only should to store the URL of the current visible view controller, and restore it when the app resumes after the phone call:
TTNavigationCenter is for those grizzled old web developers like myself who want to organize their app by "pages" which can be displayed by visiting a URL.
Your view controllers can simply register URL patterns that they handle, and when those URLs are visited the controllers will be created and displayed. You can also register generic actions that are called when a URL is visited.
TTNavigationCenter also persists and restores the full path of navigation controllers and modal view controllers, so your users can quite the app and come back exactly where they left off.
(source: Three20 Github project)