iOS: Making an App terminate when leave screen - iphone

I've build a simple app activating something in hardware, not important.
Now I just want the app to terminate completely if the user leaves the screen, switches apps, gets a call, press the home button, etc.
I'm all mixed up by all the application states, I couldn't find the right place to handle it.
I guess I need to listen to an "going to sleep" event and put a termination command (exit!)
or something like that.

This is easier than what one might think.
In your app's plist file define (check) the option "Application does not run in background" (UIApplicationExitsOnSuspend), and you are done.

Related

How to close System dialogs that appears on app crash?

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

Swift: Clearing .sharedApplication().shortcutItems on application quit

I'm having a very simple problem with my implemented 3D Touch dynamic quick action shortcuts.
I want the shortcuts to be cleared whenever the app is terminated (by double clicking the Home button and swiping up).
I am calling UIApplication.sharedApplication().shortcutItems.removeAll() as follows:
func applicationWillTerminate(application: UIApplication) {
// Called when the application is about to terminate. Save data if appropriate. See also applicationDidEnterBackground:.
// Saves changes in the application's managed object context before the application terminates.
UIApplication .sharedApplication().shortcutItems?.removeAll()
self.saveContext()
}
However it has no effect, and the quick actions still show when 3D touch is used.
If I place UIApplication.sharedApplication().shortcutItems?.removeAll() inside
func applicationDidEnterBackground(application: UIApplication), this works exactly as intended...
I read something about applicationDidEnterBackground being the function used in most cases due to background processing or something...but there has to be a way to achieve what I want when the user terminates the app using the app monitor swipe up.
Thanks
Didn't tried this. But this tweak should work.
Start a background task on applicationWillTerminate and end it after some small delay. In the mean time, you can call 'UIApplication .sharedApplication().shortcutItems?.removeAll()'.
This will hopefully clear the shortcut items.
There are dynamic and static quick actions. The first kind you define through the shortcutItems property of the UIApplication instance (like in your example). The second kind you register in the plist file.
From the documentation:
Your code creates dynamic quick actions, and registers them with your app object, at runtime.
The system registers your static quick actions when your app is installed.
If a user installs an update for your app but has not yet launched the update, pressing your Home screen icon shows the dynamic quick actions for the previously-installed version.
This means that even when the app is closed the system remembers about both kinds of quick actions. While your app is in memory, such as when going into background, the system can still query the UIApplication for the dynamic actions but it must keep some other sort of persistence of quick actions when the app is closed.
I think there is just no guarantee about the point at which the system synchronizes with the dynamic quick actions. My guess is that the system does not necessarily synchronize when closing the app, yours might be an unsupported use case.

how to load aplication from start up page each time in iphone

I have application for iphone i want to open it from start up page always but when i load first time app on ipad it loads from startup page but when i close app and second time run on ipad then it opens from the same screen from where i left i want that again it should open from startup page also.I have start up page with enter button when i click to button i move to calulations screen where i perform calculations .If i close on calculation screen the app when i again open it it opens from calculation screens not from the startup screen
In plist file add one more field
Application does not run in background : make it true
This is your perfect ans.
Second time app will be in Background thats why it is not starting with start app page. Dont allow application to run in background. Set Key "" in info.plist file
You should add in your plist that property :
UIApplicationExitsOnSuspend
This will allow your application to "restart" instead of saving its state. This will allow you to load the start up page each time.
(documentation)
Well it is discouraged by apple , according to it's documentation:-
There is no API provided for gracefully terminating an iOS application.
In iOS,user presses the Home button to close applications. Should your application have conditions in which it cannot provide its intended function, the recommended approach is to display an alert for the user that indicates the nature of the problem and possible actions the user could take — turning on WiFi, enabling Location Services, etc. Allow the user to terminate the application at their own discretion.
Warning Do not call the exit function. Applications calling exit will appear to the user to have crashed, rather than performing a graceful termination and animating back to the Home screen.
Here's the link to it.Anyway nobody stops you from using
exit(0) , but is discouraged.
Another way to do is is simply change your application's pList property "Application does not run in background" to true.

On Android or iOS - how to approach the possibility of a service or app going into a broken state

...and this broken state persisting until a device restart, since a naive attempt to restart an app would not work. Many users are not savvy enough to know how to terminate services/backgrounded apps. If the user can't (or doesn't 'need to') close apps, then what about restarting apps which have gone wrong? ( It can happen :) ) If my app goes wrong on someone's phone and they cannot easily restart the app without restarting the phone, that seems like a problem. I am aware that apps and services can be terminated by navigating system menus or double tapping the home button etc. but - many users are not aware of these features. For this reason I am thinking of adding an explicit close button to my app which will kill everything to the best of my ability, such that on a subsequent launch the program runs from the beginning again. I realise this is not the 'recommended' approach. Thoughts?
Thoughts?
Don't do it. Instead you should put a FAQ entry on your apps website that says.
Q: My app does not run anymore. HELP!
A: First you should try to restart the app. If that doesn't work feel
free to contact me.
Here is how you do this on the iPhone,
iPad or iPod.
double press the home button. the
multi tasking bar appears.
[ some screen shots ]
long press the app icon and press the
little x that appears on the icon.
[ more screenshots ]
If you want to put buttons for functions that are not obvious for many users you end up with a button for everything. And I (as somebody who knows every function) don't want a button cluttered user interface.
You would be surprised how many emails I get about "how can I zoom?" (A: Pinch your fingers) or "how do I delete an entry (in a tableview)" (A: Swipe your finger over the entry from left to right, and press the red delete button).
If I get an email about this I just point them to the faq which has some nice screenshots.
Btw, if the "broken state" happens so often that you would consider adding a special button I would check my code for bugs again.

dismissModalView crash iphone app, but not with debugger on

I have an iphone app with a modal view. The app crashes when the modal view get dismissed.
As soon as the modal disappear at the bottom of the screen, and consequently the original view is shown behind, then the app crashes with no entry in console view.
I have tried to switch debugger on and I discovered that the app just run fine, with no crashes at all.
-First, I would like to know why such behaviour, shouldn't the debugger sit just on top without "disturbing" the app ?
-Second, without debugger, can you point out what should I look at to solve my problem ? Or if you encounter something similiar ? Please be as much specific you can, because I am not an expert in objective-c programming.
I don't know what details to give you, the app is a normal one with standard iphone component, but for start I can say the modal view (which is built with IB) is called inside a NavigationBar system.
thanks
When these types of things happen, it is almost always because of memory allocation issues. The first step I would take is to do a "Clean All" and a "Build and Analyze", and look at all the analysis warnings. Analyze is very good at finding basic "use before allocate", "use after deallocate", or "wrong number of retains/releases" types of problems.
The next step is to turn on "Zombie" detection mode, which looks for accesses on memory that has already been deleted (in other words, killed objects coming back from the dead.) To do this, get info on your executable, go to the Arguments tab, and add a "variable to be set in the environment" of "NSZombieEnabled" to value "YES". Then look in the console when you run to see if something looks off.
Finally, you might try creating a new configuration where you use all the release mode settings for optimization, but add debug symbols. Maybe that will shake up the allocation disbursement in memory enough to trigger the bug in debug mode.