The standard handleInviteFromGameCenter event handling (when inviting someone from GC-app for a turn based match) behaves strange under iOS6: when I provide the playerToInvite array to the GKMatchRequest and open the GC turn based match controller, it shows "Waiting..." under that invited player (which it IMHO shouldn't for a turn based game). It never stops. When I add another player manually and press "play", it just starts with me and that newly added player, ignoring the one being passed from playerToInvite array.
Any insights on this behaviour?
Thx, habitoti
Related
I am making a multiplayer feature to a game I made.
Everything is working, except when I am in matchmaking and both players are connected, if one person hits the "Cancel" button the other device gets no notice of the canceling.
On the other device it the words change to say "Disconnected" however none of the delegate methods are called.
How can I handle this?
You should implement the GKMatchmakerViewControllerDelegate protocol.
Unfortunately, there is not a method (that I know of, or could find with almost 3 months of looking into it) that is called when one person disconnects in matchmaking after they have begun to connect.
Therefore, the way I got around this is once the GameViewController is presented it waits one second and then calls a method to check to see if it is connected to someone else.
To do this I have it so once the game begins each player sends the other player a random number (used to determine non-related settings later on - such as who gets to go first). When it calls the method to check to see if it is connected it just checks to see if the random number has been assigned. If so, then it begins the game as normal, if not, it ends the game and pops back to the menu.
I'm writing an iOS app that casts pictures. I want to make it in a way that when the user quits the picture viewing scene, it goes back to the homepage (the one displaying app's name) on the big screen. I've tried calling the stop method for mediaControlChannel and it's not going back to the homepage. So apparently this is not the one I'm looking for. So which method should I call to make it go back to homepage?
SDK doesn't have any understanding of your "homepage"; that is a concept in your app so you need to write your receiver so that if user ends the process of viewing picture, it switches to that page. Whether receiver on its own can determine that the above process has ended or sender has to signal the receiver depends on your application and its details but regardless, going to your home page is an action that you have to define and handle.
I'm writing an iOS app that uses chromecast to cast a series of pictures. When the user taps on the right edge of the current picture, the app presents the next picture, and the next picture is casted to the bigger screen. However, if the user taps fast enough and brings up the third picture before the second picture shows up on the bigger screen, the second picture, once shows up, will stay there even though the third picture shows up on the device. From the Google Cast SDK it looks like all the casting requests are queued up and the third one should show up automatically. So does this mean I have to queue the requests manually on the sender side?
I imagine your images are available on a server (which could be your phone as well). What receiver are you using? What is the behavior you expect to have? If, for example, you need to see all the images no matter how fast you cast them, then your receiver should queue the urls of images and when is completely loaded, loads the next one, etc. If you expect to skip over the previous images if a new one is casted, then your receiver should drop the previous requests as soon as a new one comes in.
You can queue them on the sender side as well (especially for the first scenario) and your sender should listen to "image is fully loaded so send in the next one) but that is not optimal since
your app creates a better experience if the next image is loaded behind the scene on the receiver while the first one is being shown so it can quickly transition to the next one and
You probably want to provide an experience that if you queue up some photos, your app can play them on the TV even if your phone gets disconnected (only relevant if images are served from a separate server).
Another factor to consider is what do you expect if a second device is connected to your Chromecsst while the first one is casting; do you want to the second one be able to "participate" in the activity and cast as well or not.
Regardless, there is a sample code on our github repo that shows a simple playlist for videos (queued up on the receiver).
Nuance's DragonMobile component apparently turns off VoiceOver announcements between the initial call to SKRecognizer's initWithType:detection:language:delegate and the component's call to recognizerDidFinishRecording:. It makes some sense that they do this, since they don't want the VoiceOver announcements to be picked up by the mic and transcribed.
The problem is that there's usually a 1-2 second gap between the initialization of the recognizer and the initial call to recognizerDidBeginRecording:. In order to prevent the user's first few words from getting cut out of the transcription, it's necessary to use recognizerDidBeginRecording: to indicate to the user that they should start speaking (i.e. you can't just have them hit the mic button and start speaking immediately).
My problem is that since DragonMobile turns off VoiceOver as soon as initWithType: is called, I have no way of indicating to a VoiceOver user that they should begin talking at the appropriate time.
Found something of a workaround: DragonMobile allows you to specify SKEarcons, which are audio files that play whenever recording is started, stopped or canceled. I'm going to record VoiceOver making the announcements that I need and then use these recordings as the earcons, so that it will sound like the rest of VoiceOver.
According to a Nuance technical rep I just spoke to, DragonMobile does indeed take over the audio layer and suppress any output during recording, and they don't expose any way around this other than the earcons.
I am developing a tic tac toe game for iOS and I am using a combination of UIButtons and UIImageViews to allow for user interaction and to display the moves made. My problem is that the buttons continue to accept user input before the cpu makes it's move, which breaks my game logic. I have made several attempts to toggle the userInteractionEnabled property, but I have only been able to turn it off. The engine that gets everything started in the game is my buttonPressed method. I also toggle the userInteractionEnabled property within this method and therein lies my problem: How do I re-enable the property after disabling user interaction? Is there a method that is called in between events that I can overwrite?
I have searched the web and I have searched through the developer documentation provided by Apple and I found information on the touchesBegan and touchesEnded methods. However, from what I understand, those methods need to be explicitly called which brings me back to my original problem of not being able to call those functions without the user's interaction.
If anyone can help, I would greatly appreciate it! I have been racking my brain over this for the past couple of weeks and I am just not seeing a solution.
I'd think that for a game like tic-tac-toe, calculating the countermove should be so fast that it can be done immediately in response to the first button press. If you're doing something complicated to calculate the next move, like kicking off a thread, you might want to reconsider that.
Let's say, though, that your game is something like chess or go, where coming up with a countermove might take a bit longer. Your view controller should have a method to make a move for the current player, let's call it -makeMove:. Your -buttonPressed action should call that method to make a move for the user. In response, -makeMove: should update the state of the game, switch the current player to the next player. If the new current player is the computer, it should then disable the controls and start the process of calculating the next move. Let's imagine that's done by invoking some NSOperation, so that coming up with the next move is an asynchronous task. Once the operation has come up with a move, it should again invoke -makeMove: (by calling -performSelectorOnMainThread:), which will again update the game state and the current player. This time, though, it should see that the new current player is not the computer, and so it should re-enable the controls.