I've made a Chromecast app that displays multiple quotes and the whole idea is to basically connect it to a spare tv/monitor you have lying around and use it to have inspirational quotes change on the screen.
But the problem is, Chromecast automatically times out and goes back to the home screen after every few minutes of inactivity. I'd like to find out how it detects inactivity so I can prevent this behavior and allow my app to keep running on the Chromecast indefinitely, as a sort of replacement for the original photo screensaver.
I figured out how to keep my app running. There is a property of CastReceiverOptions called disableIdleTimeout that can be set.
const options = new cast.framework.CastReceiverOptions();
options.disableIdleTimeout = true;
const instance = cast.framework.CastReceiverContext.getInstance();
instance.start(options);
With this set to true, the receiver no longer times out after 5 minutes.
You may check the setInactivityTimeout method then use the maxInactivity parameter which is interval in seconds before closing an unresponsive connection.
The setInactivityTimeout(maxInactivity) sets the receiver inactivity timeout. It is recommended to set the maximum inactivity value when calling Start and not changing it. This API is just provided for development/debugging purposes.
You may also refer with this SO answer which stated that:
Timeout value cannot be adjusted by application. It would help us to understand what is causing the timeout in your case. Timeout happens when either the sender does not reply to the receiver's ping requests in a timely manner, or when the sender has not received a ping from the receiver for a certain length of time. It might be the case that the media you are trying to load is tying up the CPU on the receiver so that it can't send its ping request to the sender.
Hope this helps!
Related
In the iOS Developers Guide for Parse, it states "By default, all connections have a timeout of 10 seconds." I am looking to change this for all requests made from the app, but am not finding any information on how to do so.
The reason we'd like to modify this is that it's taking a long time for requests to fail when the user doesn't have Wi-Fi or Cellular enabled. We want to reduce the amount of time it takes to receive said error message, just a little. We don't want to implement our own reachability tests, as it will result in duplicate popup error messages and we have many requests in various view controllers throughout the app.
Can the timeout be modified, or is there some other way to obtain a better user experience than waiting 10 seconds for an error message?
There is no information on this but certainly the request timeout limits are set by Parse and a developer will not be able to change them. I think they kept the timeouts to be long to avoid a user request being rejected if their connection becomes suddenly intermittent or they go in a tunnel, etc.
You can try to warp Parse queries around a timer which uses let say 5 seconds timeout, if the response does not come in that time you cancel your your query using PFQuery cancel function and show them a message.
If you want to avoid timing out, consider checking Reachability before making the call. You may want to show the user an alert if they're not connected and you need to do something.
A lot of people say you should just assume a connection and make the attempt without checking reachability; basically just let the connection fail and handle the error that way. I think as long as the failure isn't invisible to the user, so they don't blame your app vs their network you're good though.
I have been dealing with this issue for weeks and am unsure if it is my code's fault, forge's appPaused event not triggering quickly enough, or Trigger.io's documentation not being nearly clear enough about just how little time iOS gives us to execute clean-up code.
According to the documentation regarding the appPaused event:
iOS: A short amount of time is given for execution, it is generally best to assume that callbacks and timers may not fire until the app is resumed.
My application deals with websockets and ideally I am able to send a close event to my server when a user minimizes my app, or the phone is locked. Currently, all of my clean-up code runs perfectly on Android, but on iOS, my clean-up code doesn't run until the app is resumed. The strange part is sometimes (maybe 1 out of 20 times) the iOS clean-up is correctly run right after the appPaused event is fired.
To test this I have done two things:
I make the very first thing to run after the appPaused event is fired is a message to my websocket server saying "the app is paused". 95% of the time, this message is not actually sent until the app is resumed, but the other 5% of the time my websocket server receives it right after I pause the app.
I then made it so the first thing to run after the appPaused event is fired is a line that stores Date.now() in a global variable. I then then store Date.now() in another global variable when the app is resumed, and find the difference between them. It gets interesting because around 50% of the time the Date.now() line is correctly fired right after the appPaused event is called, but the other half of the time the 2 Date.now() calls are only milliseconds a part, proving that the clean-up code was not run until the app resumed.
So, can I really only expect to sometimes have enough time after appPaused is fired to even store Date.now() in a variable? Is this what everyone else is experiencing when running their Trigger.io applications on iOS? Let me know if anyone could use more information.
Yes, appPaused is not guaranteed to fire on iOS. Note, that it may only fire when the app is resumed.
Any code you want to run on going into the background will probably not run. See the trigger io docs on events. The note on iOS needs careful reading.
That said I have a similar app to yourself dealing in websockets. What i've found is that I can leave the socket open, iOS automatically kills the socket when it suspends the app (Sometime after the paused event is received which corresponds to the ios background state). The server receives the close event and you can of course attach to that event to set any state or cleanup resources. Android requires a manual shutdown of the socket, but appPaused works in a guaranteed way when the app is put into the background.
I am developing a VoIP app. When my app is in background I need to check if the server is still there. So I am trying to use setKeepAliveTimeout:handler: to make polls to server while app is in background.
The question is: how to ensure that I receive response or timeout within 5 seconds after I have sent poll message to server? If I don't receive response/timeout within 5 seconds the next opportunity to know that server is dead is only after keepAliveTimeout time which is not that good.
As I understand I can't setup NSTimer in setKeepAliveTimeout:handler: since we are in background (and NSTimer relies on run loop).
I see other possibility which is: make while loop and check for the current time in it. Although I would like to avoid making busy loops.
Could you please suggest me how can I achieve needed behaviour?
I want to implement a turn timeout feature in my game center app. It should give each user a 30-60 sec time to complete their turn and if not they should be treated as they quit. I tried using the timeout parameter of endTurnWithNextParticipants but it doesn't seem effective with small values. It never signals a turn timeout, afais the default value for it is 1 week (GKTurnTimeoutDefault). So I guess apple had different ideas than mine while using the name turnbasedmatch.
My best bet is to set a timer when user receives the turn for 30-60 secs, and if user does not make a turn in that period, fire one of the participant quit methods. But it is not a reliable solution because users may run out of batteries, turn off the phone also nstimer seems to pause ticking during uitouchevents (uiscrollview scrolling etc, maybe it can be handled by running nstimer in another thread i don't know). Any tips on implementing turn time out reliably?
I've got an app that shows calendar events. I want it to update whenever there's a change to the user's calendar in iCloud.
The docs claim EKEventStoreChangedNotification is sent when an event is added/removed/modified. And I have sometimes found that to be the case. But other times, no notification is sent at all. Every three minutes I call [EKEventStore refreshSourcesIfNecessary], but even that won't pick up the change. The only way I can reliably get a change detected in my app is by switching to the Calendar app, waiting for the event change to appear there (normally within a few seconds), then going back to my app…and there it is.
One more thing: I have "Push" notifications turned on my for my iCloud calendars.
Any idea what is going on here? Why is it inconsistent? And how can I make it consistent?
Thanks!
Not sure it helps, but I also hit this issue (just assuming I could rely on the EKEventStoreChangedNotification)... With the approach that you took (calling [EKEventStore refreshSourcesIfNecessary] tho, I do get consistent results, where moments after calling that method, I then receive the notification of changes. Seems to work all the time.