I want the specific behaviour from my apple watch, i am developing a Fitness app in apple watch.
Problem:
When user will be on some specific screen (e.g. Download ODRs from firebase). user faces issue that when user slightly down their wrist and Screen goes deem and Refresh rate goes to 1 FPS. Client has special requirement that Screen should not go to Sleep When that particular downloading process is running.
References(Example):
I tried to find solution everywhere and found some questions also over StackOverflow about this but there also saying not possible so i still haven't found anything related to this but i have found one example that is doing this behaviour is Apple watch app Mindfulness. When user runs this app and start the session as much time user will be on that screen watch will not go to inactive state no matter user raise the hand or lower down the hand.
i want to implement that same behaviour in my app. Client wants no mater what ever it takes make it work. (No issues with battery life also or Computation). i may need to implement this kind of behaviour in other screens as well.
I have tried one solution that is to Turn on auto Rotate so that when user slightly turns their wrist it will rotate instead of going to Sleep or inactive state, but it isn't the solution and looks like something weird behaviour
I have also tried TimelineView() but it will be useful once watch goes to inactive state and also it is useful when doing computations but if i have to update UI it will only do it at 1FPS in inactive state no matter how frequent your data is updating.
Thanks in advance :)
Related
I have a CLLocationManager contained in a singleton and I have added around a dozen regions to monitor. I am successfully notified of boundary crossings when the app is in the foreground/background. However, when I force quit the app, the location icon disappears and I am not getting any callbacks.
As far as I can see, this is intended functionality as of iOS7. Here is a reply I found to a similar question, in this case involving significant location change: https://devforums.apple.com/message/882691#882691:
If a user swipes up in the app switcher then the OS will not launch the app unless explicitly told to do so by the user. So no, SLC will not be launching the app, nor will silent notifications. The only thing that will launch the app at that point is the user tapping the icon. The intention here is that the user has expressed their choice of not having that app running any more for any reason, so we honor that.
In this situation, there's really nothing that you can do. The next time the user launches the app you can let them know that some of the data may be missing, although you really cannot tell whether there's missing data or not (i.e. you might have been killed by the OS in the background and the user may not have moved thereby not triggering any SLC notifications). My suggestion would be to gather the data you can within the policies of the OS and if the user has manually killed the app then respect that wish and don't do anything.
By all means, feel free to file a bug report if this change in behavior winds up causing problems for you or (especially) confusion for your users.
I'm testing a turn based game between two devices. As far as I understand, sending a turn with [GKTurnBasedMatch endTurnWithNextParticipants:], for example, should automatically push a game center notification to the opponent. Sometimes, this works just as expected: the turn is sent and right away a banner notification shows up on the other device. All is well.
What is baffling me is that other times, even though the turn itself is sent properly (I can tell because when the opponent refreshes the matches, the match is up-to-date), there's no push notification coming in.
Are there any holes in my understanding here? If I'm understanding correctly, the inconsistent notifications shouldn't have anything to do with my code, because the issue here isn't how I handle notifications, it's that there is no notification at all. In other words, [handleTurnEventForMatch:] (aGKTurnBasedEventHandlerDelegate method) doesn't have anything to do with it (I don't think) because if no notification is being received, it's never going to be called anyway.
So, I'm just wondering if anyone has had any experience with this. Is it possible that this is due to something in my code? Or, is it possible that the Game Center sandbox is responsible for the inconsistencies, and there's nothing I can do about it?
Any thoughts or ideas would be much appreciated.
It is an issue with GameCenter's sandbox mode. In order for your device to enter sandbox mode you have to open/run your app and authenticate game center. If you say, open a different (published) game after your game is open it will leave sandbox mode and and go back to regular game center mode.
Even if your game is running in the background, as long as it is the last game-center enabled game opened you should get the push notifications as normal. But if you open the game, and then kill the process, you will no longer be in sandbox mode and will not receive the push notifications.
For those who are experiencing similar problems: this turned out to be a Game Center sandbox problem. It had nothing to do with my code, and things were fine in the App Store release. So, read through the comments here and make sure there aren't other things factoring into whatever issues you're having...but know that it's possible that you're simply experiencing some Game Center sandbox issues that are out of your control!
I am also facing the same problem. My game stops receiving turn events and turn notifications from Game Center, I finished my game and was testing, but this week, the problem started to happen. It was working like a charm but suddenly instances started not to receiving turn events for a couple of days.
I am using the iOS7 SDK and targeting iOS7 (turn event handling is different than prior iOS versions, I will need exchanges in upcoming game features, that's why I am using iOS7).
Then I made a test app to check if it was same with iOS6 and prior SDKs, but no help, it was same. So don't waste your time to upgrade your code to iOS7 hoping it would work, the problem is there. I also tried many things, like resetting devices and settings, using new users, etc.
I also tried it with Ray Wenderlich's Turn-Based Gaming with iOS 5 tutorial, by downloading source code, and it doesn't work neither.
The thing is, usually when I launch the game, game receives turn events, but after a few turns, it just stops, and when it stops receiving, stops like forever. If I reload the match, I can get the updated match and it's data is also updated, so I can make the turn. It means match is updated on Game Center. So, either Game Center is not pushing the data to users (possibly this is happening because user cannot receive notifications from Game Center when the game is in background), or the GameKit is not firing the event to the handler.
I don't know why it is happening, or why it started to happen, but I can't release my game like this, hoping that it would work out of sandbox. I will be trying a couple of more things (like maybe trying turn reminders of iOS7, to see if they push it to the user), then I will ask to Apple's support team. One other thing i am planning to do is, putting my test app to App Store and see it if works out of sandbox.
Hopefully it is a sandbox problem.
Allow me to describe my situation:
I want to develop a game, that is round-base, and pay-to-play. That means you pay one coin, for one round of game, like Pinball etc.
The problem is, when there is interruption, ideally the game should pause, and resume whenever the user desires. Implementing that seems to be a challenge. Say my game was put into background, I would save the game state in ApplicationDidEnterBackground. However the game may or may not get terminated while in the background. So the next launch could be a "fresh start" , or, a "resume from last saved state".
If the app is left in the background long enough, say 1 week, its almost certain that other apps fighting for memory will cause the game to be terminated at some point. When the user starts my app again, they would be playing from a new round, meaning that the previously unfinished game, is gone.
From a customer point of view, this is unfair.
What I can think of is, to implement it so that whenever my app is brought to the foreground, I would go check if there was a saved game. If there was, I shall resume it instead. This poses a security issue:
Saved game, either in most primitive plist format or other formats, are persisted, and poses security problems. (What if players edit the game state and score 10 million points as top score... etc)
Are there any recommended ways to tackle these problems?
I see some Apps simply give up on saving the game, and a new round will be started on resume. Those are not paid to play games, otherwise I can imagine users getting very angry.
I have seen some Apps that saves the game state for a while, but when it got terminated, when next launched, it will start a fresh round. Which seems just as unacceptable in the case where players actually paid money for the round.
And when taken into account the possibility of crashes, I cannot come up with a good solution that ensure paying customer will get to play a full round of game. It would really help me if someone with relevant experience could share their thoughts, and how they make their decisions.
Why not tie the round finishing to the payment? If the round doesn't finish, no payment is taken. If the user's credits are insufficient at the time the round finishes, you could give them the option to purchase more credits immediately (via in-app purchase) to finish the current round.
That simplifies your task as a developer, and also provides a way to prompt the user for additional payment in a non-obnoxious way.
Here's a great tutorial on using NSCoding to save game states. It won't have any problem with the player going in a editing the file, as it is done in NSCoding. If a user REALLY wants to figure out how to un-encode the file and change the contents, which is crazy, you could do some kind of encryption on the data BEFORE you write it to file, so there would be no way the user could change it. Hope that helps!
What is the proper way of ending an application on the iPhone when you are finished with it?
thanks,
anton
Jaanus is referring to this paragraph in the Apple iPhone Human Interface Guidelines
Stopping
People quit an iPhone application by opening a different application. In particular, note that people don’t tap an application close button or choose Quit from a menu. In iOS 4.0 and later, and on certain devices, the quitting application moves to a suspended state in the background. All iPhone applications should:
Be prepared to quit at any time. Therefore, save user data as soon as possible and as often as reasonable.
Save the current state when stopping, at the finest level of detail possible. For example, if your application displays scrolling data, save the current scroll position.
iPhone applications should never quit programmatically because doing so looks like a crash to the user. There may be times, however, when external circumstances prevent your application from functioning as intended. The best way to handle this is to display an attractive screen that describes the problem and suggests how users can correct it. This helps users in two ways:
It provides feedback that reassures users that there’s nothing wrong with your application
It puts users in control, letting them decide whether they want to take corrective action and continue using your application or press the Home button and open a different application
If certain circumstances prevent only some of your application's features from working, you can display either a screen or an alert when users activate the feature. Although an alert doesn't allow much flexibility in design, it can be a good choice if you can:
Describe the situation very succinctly
Supply a button that performs a corrective action
Display the alert only when users try to access the feature that isn’t functioning
As with all alerts, the less users see them, the more effective they are. For more information about creating alerts, see “Using Alerts.”
There is no way for an iPhone application to quit/terminate itself. Apple actively advises against it in their Human Interface and/or programming guides (can't remember which exactly) because it would look like a crash to the user.
An app should not terminate by itself.
Also, avoid showing an "exit screen" that prompts the user to quit the app manually as in iOS4, the app might stay open in the background and your user would be stuck in that exit state.
This question seems to be the essence of several others on this forum. I believe that it is possible for the active iPhone application to continue running, and specifically, to continue receiving timer call-backs, after it has entered the inactive state (either through the idle timer kicking in the screen lock, or through the user pressing the hardware lock button).
The documentation specifically says that while an application is inactive, it is executing, but not dispatching incoming events (I'm not giving a link because I'm jumpy about NDA - should I relax about that? Is this whole post a breach? sigh).
Also, two answers by user "Ambr Str" directly state that it is possible to continue receiving timer call-backs, and he supplies a snip of code to achieve it (I can't link to this because I'm a new user, sorry - search for the question: "What happens to an iPhone app when iPhone goes into stand-by mode?" to find his answer).
I've tried to create my call-backs as he suggests, but once my application becomes inactive, the call-backs cease firing.
I've just noticed that while the iPhone is plugged in, if the application becomes inactive (due to idle time out or me pressing the sleep button), call-backs do continue to occur - perhaps I should get my users to carry a battery pack with them ;-)
There is a good answer to this question on Apple's forums. Search for "Timer" and "Eskimo" (the helpful chap who provides the answers).
In brief, shortly after the application becomes inactive, the phone really does go to sleep. The only way to prevent this is to be playing some audio (or for some audio to be playing in a background application). While audio is playing the phone will not sleep, and your application continues to be run.
It is suggested that playing stay awake audio is a hack, and that you shouldn't do it if at all possible. I think in my application (which performs audio playback interspersed with silent periods), the approach is valid, if not ideal!
I have an app. which includes an embedded webserver. I'm planning to offer an option of disabling auto-sleep IFF the server is turned on, AND the device is on power. So you might consider checking the batteryState property of UIDevice. So if batteryState != UIDeviceBatteryStateUnplugged, go ahead and disable idle timer. (note: the docs say that UIDeviceBatteryStateUnknown will be returned when in simulator.)
You'll also want to listen for UIDeviceBatteryStateUnplugged notifications and set batteryMonitoringEnabled appropriately.