Why does MonoTouch debugger disconnects after some time? - ios

When I debug an app on my iPad, it's often the case that when I get back to it after some time has passed, the debugging session has already stopped but the app is still running.
It's very frustrating because I specifically baked some UIWebView debugging tools into the app like reloading external content on a swipe so I don't have to recompile it every time I change something.
I've looked at the settings and found nothing like “debugging timeout”.
What's the matter?

It turns out, the problem was in Auto Lock.
It unloads the application, and thus soft debugger's connection is lost.
Setting Auto Lock to 15 minutes solved my problem.

Related

React-native app whitescreen when in background for a longer time

Short description of our situation:
We have a react-native application which renders a website with react-native-webview (https://github.com/react-native-webview/react-native-webview)
Whenever our application is in the background for a longer time (mostly occures over night), the application results in a whitescreen when opening up the next day. This only really occures on iPhones - not on android devices / nor on iPads.
When the application goes to the background, we stop all polling tasks and the app isn't really doing anything till it comes to the foreground again.
Does anyone have an idea what could cause this problem? Is this a general problem on iPhones with webviews?
We have a possible fix by really disabling the webview, when the app goes to the background (by not rendering the Webview once the appState goes to background). Still would be interesting to know where this comes from.
I'm thankful for any help!
Have a nice day.
I found this information with a possible solution: https://blog.embrace.io/bug-of-the-month-blank-webviews/
They occur when web views fail or are killed by the OS. Normally, a process being killed would crash the application, but on iOS, WKWebViews have two additional processes: a content process and a networking process. These can be killed without affecting the main application process. You can provide a better user experience by deciding which web views should be reloaded upon failure and adding this functionality through the webViewWebContentProcessDidTerminate callback on WKNavigationDelegate.
Haven't tried it out yet - but will.

iPhone restarts after API call

I am facing a very weird issue: my iPhone is restarting.
This issue occurs in a particular scenario only.
Step 1: I have a sync process in which I'm loading data for the whole app. So I'm basically doing a heavy API call by uploading 4-5 camera captured images and syncing the app data;
Step 2: After syncing, I'm pressing the iPhone home button to make the app go in background;
Step 3: I'm locking the iPhone screen(by using side button);
After a few seconds I'm seeing the apple logo and the phone seems to restart. This is not replicating when the app is connected in debug mode. I checked the debug navigator app is using only 125 MB of memory, disk and network values is 0%. Energy Impact is showing high, I'm not sure this is due to high energy impact. I'm facing this issue only on iOS 12.4.
The fact that the phone (or possibly just springboard) restarts, and not just your application means this is Apple's bug. You're not supposed to be able to crash iOS even if you try.
Finding a likely cause will be hard since the system is not behaving the way it's supposed to. The device's logs may have more information from things other than your app. This may be a system API breaking due to any number of actions from your application.
Often with this kind of thing the next OS version will fix it, but if that's not the case or it's important to track down I would try removing ways you're interaction with the system (background APIs, notifications, etc.) and see if anything fixes the issue.
If you find the problem, you may even be doing things the "correct" way according to the documentation and have to find a workaround. If you have the time you can submit a bug to Apple so the underlying issue has a better chance of being fixed.
It seems when your app is in the background and phone locked, Automatic Reference Counting (ARC) closes some connection or deallocates a resource that makes the iPhone restart. Are you closing all connections and removing all references once the upload is complete?
Phones do not spontaneously restart just because of an app’s actions. You’re having an issue with your phone, not with a program. You need to repair or replace the phone.

Is there a way to stop an app from closing if it stalls on splash screen?

I've been testing an app for iOS in Xamarin Studio, however whenever I reach a breakpoint or an exception is thrown and I stay there for a few seconds without pushing the continue execution button, the debugging session will close as the app will close on my device. This is due to the process mentioned here, as it is occurring during the splash screen, and if the app pauses too long there, it will close the app because it failed to scene-create. I was wondering if it is possible to disable this when debugging with breakpoints, because I would like to look at the data flow through variables and such.
As matt guessed, it is a Xamarin issue. The response to my inquiry to Xamarin was this,
Xamarin does not currently use a native debugger, thus watchdog is not
disabled. They are looking into alternatives, but for now a potential
workaround is to not do anything until you've returned from the
FinishedLaunching method (i.e. start your launch code in a timer event
for instance), and debug that instead.
Update: the status on this bug is "fixed for the next major release." as of 12/29/15

If the app is suspended while NSTimer is running, will it crash upon reopening?

Theres something that is making my app crash between when it gets suspended and when it's reopened. It's a location based app that uses the didUpdateLocations callback/delegate function. I have one or two timers running in the background, and i'm not really sure what happens to them when the app is minimized.
I've been doing some thinking. Really, if the timers aren't running in the background that's fine; they dont need to be. But are they getting suspended, and when the app pulls back up they try to catch up to where they were or something? Why does my app crash when i reopen it?
It's not as simple as crashing when it reopens either. It works if it's a normal amount of time. The app is made to run in the background indefinitely, within reason, so if i wait a day or two before opening it again, it crashes on me. Doesn't crash, necessarily, but freezes. It doesnt send a crash report, just sits there and does nothing. I cant interact with the UI or anything. What could be causing it to do this?
Like i said, the only things that run "indefinitely" are the didUpdateLocations method and one or two timers that check things. That's program flow. It all stems from that. I can offer some code or more information if anybody needs it.
Any ideas?
As mentioned by lehn0058, the timers fire once for each missed increment when the app opens. This is potentially disastrous, and sounds like if the timer isn't set up to count down to something, it should probably be invalidated and restarted each time the app is opened and closed. Another option that i discovered recently is software called Flurry. It's analytical software that i recently integrated into my app. Potentially extremely useful; others should look into it if they havent heard of it.

Can you enable watchdog in iOS for debug mode?

One of my apps got rejected because it exceeded the startup time limit. The watchdog process killed it. Is there any way you can enable this watchdog component in debug mode? I've read somewhere that it's disabled for debugging purposes (which seems logical to me). Just wondering if you can manually enable it with some setting or something.
Btw, I know how to fix this problem, moving the whole startup code to a background thread did the trick.
Anyone got an idea?
Well it's active when you launch an app not through Xcode (i.e. with no debugger attached), so you could just install your app via Xcode, unplug it, launch the app. Then you'll see if it takes too long. But really, you shouldn't be thinking that you need that as a feature during debugging. You should just return ASAP from applicationDidFinishLaunching and do your work later like you have mentioned.

Resources