The question might seem quite odd, but I couldn't quite find an answer perusing the API documentation.
What is the purpose of the participant's status?
Is it possible to manually set the status to finished, so that the active games list would show said game for participant to be finished, rather than calling finishMatch()?
The scenario in mind would involve a game with more than two players. Say player A finishes the game, his status should be set to "FINISHED", while player B and C would still play, until either one of them finishes, which would trigger the end of the game.
Usually Participant status could be shown in UI. Have you found any API which allows you to change Participant status directly? I think to change it to FINISHED you need to call finishMatch().
Related
I have been implementing my own turn based board game. Whole game is based on PlayGameService's SkeletonTbmp example with some modifications.
My problem is that a player sometimes receives its own data that it sent to the opponent using takeTurn(). I have checked many times that getNextParticipantId() returns the right id. For example my emulator persists a move data and sends it correctly to my actual Android phone and my phone unpersists as implemented in the example. Then some seconds later my emulator receives this same data without actual device persisting it and calling takeTurn(). This also happens sometimes on game start on the first turn, emulator receives the first "dummy" turn data without actual device sending anything yet. It does not happen every single turn, just occasionally.
Could this be something with my Google Play Console settings or does these turns buffer some how and then they are released at some point?
As you have not giving any codes i cannot pinpoint the problem. But just for the explanation, as long as the match is going, match will contain data, whether its your turn or not. To pinpoint the exact place this is happening, put checks at the execution of updatematch() as it must be firing without actual need. (on login, reconnect, initiate, connectionhint etc). Can't be sure about your code but alternate approach to bypass the bug, you can actually put check on turncounter in addition of MATCH_TURN_STATUS_MY_TURN otherwise pass the null turn. Hope it helps as further i cant help without your code.
It seems that i just forgot to always remove the old games from the "check games"-UI, thats why it sends the same data after a while, when i am already attending to a new game with same opponent.
I'm creating a multiplayer tic tac toe game and it works for the most part, but when it's time to rematch I'm getting less than desirable functionality.
So originally I used the same implementation of Games.TurnBasedMultiplayer.rematch as the TBMPSkeleton sample project. Basically after calling Games.TurnBasedMultiplayer.finish, I check whether or not the match can be rematched by calling match.canRematch() during the subsequent callback. If match.canRematch() returns true, then I call Games.TurnBasedMultiplayer.rematch. Both, when I call finish and when I call rematch, the onTurnBasedMatchReceived callback gets called on the opposing client device and from there I check the match object for the rematchId. If it's not null, then I reset the game.
The problem I'm having is that, after the winning player has requested a rematch and then takes his/her turn, the opposing player receives an invite to the new match, but the onTurnBasedMatchReceived callback doesn't get called. I don't want the losing player to have to leave my game in order to accept or dismiss the invitation.
So is there a way to have my app handle the invitation notification without forcing the player to have to open the system's notification gui? Should I scrap the turn based multiplayer API in favor of it's real-time counterpart?
I realized that I didn't have a listener registered for invitations. After registering one, I was able to achieve my desired functionality. I'm relieved that it's working, but it would have been nice to notice that much sooner...
Currently, I'm working on my new project - a (quite) simple game on Android allowing users to play with each other. One game is divided into few rounds, that users play separately. When one user has finished his round, application should send message to a server, which, in turn, should send notification to the other player with set of actions made by first player.
Beside that, players should be able to send invitations to the game to other players and server, for its own, should be able to send notifications, when, for example, user didn't make a move for a long time. (sort of reminders)
I'm wondering which technology/library/... I can use to make this work. I read a little bit about GCM, but I'm not sure it's good choice. I don't want my app to send some "pings" to server in every second/minute to check if it has something new happened. I want it to be as light and speed as possible.
Can you give me a hint?
Thanks in advance.
#Tomek,
First, probably you will will need to keep a persistent connection while the person is in the game to you server to have a minimal latency.
Second, you know java if you are writing on Android
Third, asynchronous event-driven server model might be a good choice.
I'd like to recommend you to take a look on netty
http://netty.io/
At the same time, Google has a multi-player API, but it is too vendor lock and the general idea behind is different
https://developers.google.com/games/services/common/concepts/realtimeMultiplayer
I am trying to write an app that detects whenever any app on the device starts or stops playing music. My app is not a media player, it's more of a dashboard functionality, so I have no need of requesting audio focus, but I want to know when other apps do so I can update my status text accordingly.
Essentially, I believe that the function AudioManager.isMusicActive() will provide essentially exactly what I want to know, however since I am writing a service that will be always on I would like to avoid needing to poll that on a constant basis. I need the information in near real time, so it would essentially be a 1 second poll in perpetuity.
I'm looking for a way to detect when STREAM_MUSIC is being used by another app.
Some ways I have thought about doing it:
(1) Again, a perpetual poll using either Timer or Handler to constantly poll the isMusicActive() function. Not ideal from a battery or processor management perspective. I could use a flag variable in the UI Activity to control when the poll runs (it isn't really necessary when the UI isn't in the foreground, anyways), but I still think I'm using more processor/battery time than I'd need to.
(2) Listen for a broadcast of some kind, but none of the Android audio broadcasts seem to really fit the bill. (that I could find)
(3) I could, I suppose, request audio focus and just never play any audio and never give it up. Theoretically, since I am starting this in an always on service I believe that should allow my app to sit at the bottom of the LIFO audio focus stack and I would be notified via the AudioManager.OnAudioFocusChangeListener mechanism in basically the opposite way of its intended purpose (i.e. turn on my app when I lose audio focus and turn it off when I gain audio focus back). However, I'm not entirely sure how doing something like this would function in real-life usage. I feel like abusing the audio focus methodology for something like this could very easily result in negative user experiences in situations I haven't even thought of.
(4) Is there a way to use the AudioManager.OnAudioFocusChangeListener (or similar) without needing to request audio focus at all?
Are there any other ways I could go about doing this? Just a pointer in the right direction would be incredibly helpful!
I needed similar thing, so did a bit of research.
Unfortunately, there seems to be no other way to accomplish this except of requesting audio focus in your app.
Material for study:
Check Android source code in frameworks\base\media\java\android\media\ where you can find actual code for requestAudioFocus in MediaFocusControl class.
Other classes in this folder show how they send broadcast events for volume change, bluetooth on/off, etc, but no broadcast event at all related to audio enabled/disabled.
Another information on topic:
http://developer.android.com/training/managing-audio/audio-focus.html
http://developer.android.com/training/managing-audio/audio-output.html
Other than that, there doesn't seem to be any documented way to know when audio hardware starts/stops to play.
I trust that requesting audio focus without actually playing audio should not consume any battery. Only one ugly side effect is that this stops currently played audio.
I'm asking about home widgets like for Google Play or Youtube. They loop repeatedly through 5-10 items, going to the next one like each 5 seconds.
I read that this can be done with alarm manager, but in all posts about that, people say, that a high update rate will consume much battery life. In this post there's somebody talking about using timer with Handler. But is this a valid approach in a BroadcastReceiver?
Do I have to "wake up" the broadcast receiver each time to loop through the items, with alarm manager? Or how is this done?
Thanks.
In this post there's somebody talking about using timer with Handler. But is this a valid approach in a BroadcastReceiver?
Not really, because it will only work so long as your process exists, which is probably not going to be very long.
I don't know how to use a third party home screen
Download one from the Play Store, install it, press HOME, and choose the newly-installed home screen.
So these widgets can do this because they are shipped with the device?
That is not what I wrote.
A home screen is a program, written by a programmer. It can do whatever that programmer chose to have it do.
App widgets involve inter-process communication for every update, which is why they are a bit expensive if you update a lot. A home screen does not need to use inter-process communication to update itself. Hence, some manufacturer-supplied fancy "app widgets" are not implemented via AppWidgetProvider, but rather are features of the home screen app itself, simply listed and configured as if they were app widgets.
They loop repeatedly through 5-10 items, going to the next one like each 5 seconds.
On Android 3.0+, the best answer is to use AdapterViewFlipper, as you do not need to manually update it -- the AdapterViewFlipper will pull the next bit of content as dictated by the configured update period..
On earlier versions of Android, you will need to do this yourself, and AlarmManager is probably the most reliable option if it truly has to be time-based updating. Please consider letting the user control the update frequency, including disabling the time-based updates entirely.