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.
Related
Play store has numerous apps those creates fake call logs.But, sometimes it's important to detect is that call log real or fake to save yourself being a fool. Can anybody tell me how can we detect same?
If these apps are writing to the actual android call log, I don't think there is much you can do against that.
However, you might want to try the below solution, which can maintain your own call list based on the device behaviour.
In Android you can listen for incoming and outgoing calls, using a BroadcastReceiver. Here is a good tutorial for it:
https://www.codeproject.com/Articles/548416/Detecting-incoming-and-outgoing-phone-calls-on-And
If you implement it correctly, you will only receive events from calls being executed for real. So you can save them in your app's call log.
I have a bit of a problem:
I am working on an instant chat application for android where I need to make sure that a user gets deleted from the database as soon as he or she closes the app. There is this line of code:
Firebase.Instance.CurrentUser.Delete();
Which deletes the current user. I could put a LogOut button and have this line integrated into the Onclick Event which will delete the user from the database. But chances are that peeps won't click that button but instead just close the app from the taskmanager. (Or maybe their phone runs out of battery?)
Well, the problem is obvious: I cannot have more than 100 users connected to my server ( for monetary reasons), so it is vital for me to have the user and all of his records deleted upon closure of the app.
My next thought was to put the above line of code into the OnDestroy() Method, yet I came to realize that this method is sometimes not called and also doesn't seem to be able to delete the user even when called (Maybe it is too much work? I don't know).
What else could I be trying?
You are solving imaginary problem. You cannot have more than 100 users actively connected to the Firebase at the same moment, but you can have more than 100 users.
You don't need to delete users, you need to detach all observers in onPause() and that is all.
So, I want to learn this synchronization strategy instead of just using the simpler MessageAPI, but am really struggling with how to successfully implement this.
My project is like this: I make queries to download a small amount of text from an API, via my phone. I will make these queries every so often, haven't really decided on how often just yet. The data will update the watch, which should hold onto the last data received. After that first download occurs, I send data using a DataMap, to the Android Watch. I only send that once, because I believe that sets up a channel to continually send updates when ready. If that is wrong, please correct me.
My main question is this: what if the Android phone's app closes? Then the data object goes to null, and gets sent to the Watch as null? Or, should I send an object from a long-running service or shared preferences on the Android phone, so that the object is never null?
Think of the Data Layer as more of an event system, i.e., you update your data and you're notified on the other side when the data is updated (created, changed, or deleted). You don't have to worry about if the Activity is killed after that. Even if the data was 'deleted', you would be notified it was deleted.
On the Wear device, you would listen for the changes via a Service or Activity and update UI, DB, etc. accordingly.
It probably make sense to read through this Android training guide. (It isn't too long.) The Handling Data Layer Events section is probably the most useful.
For some strange reason, which I'm not entirely sure why, I'm getting not only an ANR for my application, but also of the entire systemui. It's so bad that I HAVE to reboot, and after rebooting it has to "Optimize" all of my apps like it corrupted something (anyone have an explanation as to why this happens?).
I'm assuming that parts of my code are so bad that they're causing this, but should even malicious code be able to overload the systemui? Anyway...
What I am doing is that I'm attempting to launch a service to handle screen recording. The activity (from a fragment) asks for permission (which is obtained, and I see the Screencast icon in the top right corner of the screen), then it binds a service which handles any state changes. What I mean by state changes is this...
States:
Dead - Means it needs to be initialized and prepared
Alive - Means it needs to be start and is fully initialized/prepared
Started - Means it is currently recording.
Paused - Means it will start a new video after starting again, which it will combine all temporary videos into one (haven't worked out that details yet).
Stopped - Means combine any and all files into one, then send the URI through an intent in a broadcast (haven't gotten this far yet).
It goes from Dead -> Alive -> Started <-> Paused -> Stopped -> Dead. At least that's the overall plan. I plan on having a floating button that acts as remote for controlling the service, and hence broadcasting on a receiver (local) to my fragment which is waiting for it to be finished.
Now, enough of what I intend to have, lets get into what I have right now. It's kind of a mess, I've never done this stuff before, hence why I'm asking on here. Trust me when I say that I have tried a lot of stuff, and the unfortunate bit is, the only way to test out a new solution is to reboot and wait 15 minutes while Android optimizes everything again. Now I understand it's a "Long" code-segment, but I'll say that one place it crashes is stopRecording(), at line 216.
Code here.
Let me know if I should make any changes.
Lastly: Should any of this be run on another thread? Could that be the issue? Why doesn't the app crash only instead of systemui?
I am currently working on an audio player that is supposed to pause/stop when losing audio focus, for example when a call comes in.
While I got this working fine by using an OnAudioFocusChangeListener I want to enhance this function to behave differently under different circumstances.
As the application implements a timeout function in case the user has fallen asleep while listening I only want to resume playback when I can be positive that the user is still awake.
I figured I could pretty much ignore notification sounds like those of an incoming email, as these usually are only short clips and my audio continuing to play will not be a nuisance to the user, as it would be during a phone call.
Thus I want to limit pausing/stopping to situation where either a phone call comes in or the user makes a call.
I have seen that AudioManager has some convenient states to signal this, but upon calling AudioManager.getMode() in my OnAudioFocusChangeListener I do not get consistent output.
Sometimes an incoming call does generate MODE_RINGTONE, but often enough to render the function unreliable I get MODE_NORMAL.
I could actually live with not knowing the mode when losing focus as long as I get the correct mode when re-gaining focus, but also this doesn't seem to work reliably.
The only actual device I could test this behavior on is the Galaxy S2, running Android 2.3.6 (the application is API level 10 due to me using MediaMetadataRetriever, thus requires at least 2.3.3).
I have tested the loss and re-gaining of audio focus in various emulated systems, and overall it seems to be working better there, but I also don't really get the same results each time.
Maybe the problem is that I misunderstand what AudioManager.getMode() should return, maybe somebody could clarify this for me:
phone rings -> AudioManager.getMode() should return MODE_RINGTONE on focus loss
user makes or picks up a call -> AudioManager.getMode() should return MODE_IN_CALL on focus loss
doesn't pick up the call -> AudioManager.getMode() should return MODE_RINGTONE on focus gain
user hangs up -> AudioManager.getMode() should return MODE_IN_CALL on focus gain
Is that the way it is supposed to work? At least my tests suggest that this is the way it is supposed to be, but for some reason isn't all the time.
Another way I am trying to solve this problem is by using a PhoneStateListener, but the problem I have with this is that this requires my application to request the permission to read the phone state. As I am sharing my application, currently through SourceForge, later possibly through the Android Market, I would like to avoid using this kind of permissions.
So, coming to an end I would like to ask if the way I understand AudioManager.getMode() is correct and if there is any information on its reliability, as for me the results I get from it are kinda useless.