I am working around for a while with GameKit. Almost everything works fine. I have a major Problem with the session:peer:didChangeState: Method not beeing called after resuming.
In the Apple example GKRocket the session is destroyed if the app suspends(willTerminate) and setup when it comes back(willResume). For my app it would be nice to keep the session up.
In the Logs i can see, that session:peer:didChangeState: with state GKPeerStateUnavailable is called when the app suspends, but after resuming the call with GKPeerStateAvailable doesnt show up. The session is available. But even new clients cant find the device.
I use the SessionModes Server/Client.
Thanks in advance for your help!
I was playing with sessions some time ago, but have some suggestions...
-after resuming, what happens if you try to send packed from device which was sleeping to device which was awake? does it go through ?
-do you need GKPeerStateUnavailable / available ? From my experience all you need to use are applicationDidBecomeActive and applicationWillResignActive methods: when going to sleep you send GAME_PAUSED to other device, when awake - GAME_UNPAUSED. If user puts app to sleep and then closes it - well, bad luck, the other player will sit there forever (so you can give him an option to quit to main menu). This approach works with apple (in terms of approval) - tested on two apps.
Regards!
Related
I'm developing a react-native app, and we noticed something strange. When the app comes back from suspended state (it doesn't happen from normal background state I think), often, the fetch freezes afterwards.
To trigger it, put on battery saver (I think it will make the app go to suspended state a lot quicker), then put the app in the background, do some other stuff on your phone for a minute or 5-10, open the app again and use it.
In our case we navigated to an other screen which tried to fetch three lists of objects at the same time from the backend. In the backend, we noticed only one call coming through, and the Promise.all(...) on the three calls never gets resolved or catched. So there is no error either. Afterwards all calls work again and the problem seems to be gone. So it's a one time issue.
This never happens when not coming from suspended state.
This is extremely hard to debug, since when the app goes to suspended state, the debugger is disconnected.
We haven't tested this yet on Android, it could be that the problem exists there as well.
My gut feeling tells me, it has something to so with the internal networking of IOS or the fetch library of RN. (e.g. when reconnecting to wifi, coming from 4G or something)
Has someone experienced the same problem already or has more insights on why this is happening or how to solve this? (e.g. use a time-out and retry mechanism, which I would like to prevent, force a api call on state change to active - although react-native can't detect the suspended state)
Thanks in advance!
EDIT:
Forgot to add: we're using react-native 54, but are in the process of updating to 57. I'll report back if the issue is still happening on 57...
EDIT 2:
Atm, we solved it by doing to the calls after each other instead of the at the same time (so fetch().then(fetch().then(fetch())) which seems to resolve the issue. So yet again, doing the calls at the same time, never fails normally, only after a suspended state of the app.
NOTE: This app I am working on is completely for my own usage and will not be on app store so please don't give answers referring that.
I want my app to do some process in background or after termination (double tap the home button and swipe the app from applications multitask) every few minutes. The process is very very light and quick so it won't drain the battery. This process shouldn't require internet connection. I have seen some answers here like and I will explain what are the problems:
VoIP. The problem with VoIP is wither it should be in background to use UIApplication.sharedApplication().setKeepAliveTimeout(..) method which doesn't work when the app is terminated or it should be connected to the internet to establish tcp connection and receive commands from sever and as mentioned before I want it to be internet independent.
Location Services. I found this excellent site with some great articles but the problem is it only works when the mobile phone is moved more than 500 meters. It depends on the location movement so when the phone is staying somewhere there will be no code execution.
Playing an silent audio loop. The problem here is if the user plays another audio (which is completely possible like music or phone call) the app will terminate!
Jailbreak Launch Daemons. I can't require jailbreak so it should be solved with a non-jailbreak solution:(.
I am free to use any kind of private-API's and there will be no restriction for that.
Thanks in advanced
I also faced with such problem, and don't find any solution.
The main problem is if user manually terminated app - in this case you can't do nothing...
Only way is:
a) use Location Services (as you mention)
b) use Push Notifications with background fetch
I'v developed an SDK for all of my applications to use, and I'm having a bit of problem.
I'm using AFNetworking and FMDB, together and I'm calling a method in applicationDidEnterBackground
to send the data gathered in the current session, but it seem that the data doesn't come to the server from time to time, unless i relaunch the application from background.
I'm testing from my iphone 6 and nothing is wrong, even with edge and very bad connection the data arrives to the server no matter what but in my other devices, like iphone 4s and iphone5, it doesn't always arrive when i left the application with simple click of home button.The weird part is, when i relaunch the application the data immediately arrives.
Is it a hardware problem that my old devices isnt fast enough?
I dont think thats the problem, when i use the simulator it works without a problem, the data reaches everytime.
so any idea?
Or any suggestions of where to call this method?
Cheers.
This is because more or less the simulator/iPhone 6 is faster than your other devices. Developers have about 5 seconds before the application exits the applicationDidEnterBackground method. According to the documentation on UIApplicationDelegate, Apple recommends if you need more time to call beginBackgroundTaskWithExpirationHandler in your applicationDidEnterBackground method where you can pass a task to be performed with a handler.
Sources:
https://developer.apple.com/library/ios/documentation/uikit/reference/uiapplicationdelegate_protocol/index.html#//apple_ref/occ/intfm/UIApplicationDelegate/applicationDidEnterBackground:
Is there any reason that my app would get reset entirely by the iPhone?
I have a timer app that has timers with notifications for each timer. Occasionally, (it may be related to charging the phone) the app gets reset entirely, all timers stopped and reset as if the app had never been run before.
Is there a time when apps get a call to nil-out? Should I be storing the timer start times and a BOOL saying a timer is running in NSUserDefaults (or similar)?
Thanks in advance,
Michael.
Applications can be killed at any time both by the OS and the user, thus leaving us developers in a constant state of worry about hard data like yours. If you must, save it to an NSUserDefault for the next launch of your app.
I would like to add Flurry to an iPad app that is meant to stay running in the foreground for several weeks.
Flurry apparently only uploads information to its servers on events such as app start, app close, app pause, but I don't expect my app to enter those states very often. I need app feedback sooner.
Is it possible to force Flurry to send data on a timer, say every hour or two?
I found a way that seems to work. To test, I created an NSTimer that calls [FlurryAPI startSession:#"yourKeyHere"] every five minutes, then let my program run without stopping or pausing it in any way, and the event data is appearing on the Flurry server.
The comments above that method in the .h file do say "start session, attempt to send saved sessions to server", so in a sense it's documented, but it feels like a hack to have to call something called startSession more than once per application run. This is partly why I'm switching to MixPanel, which has a documented upload interval feature.