im currently developing a multiplayer cardgame for android and i'd like to use the google game services realtime multiplayer api. From reading the documentation i know that in the end, every message a client receives will call the RealTimeMessageReceivedListener() . My question is, WHEN is the method called if my application is currently in a working state?
Cause currently i split the application in model view controller with the gui running in its own thread. The controller polls the gui for input and calls the model interface to change the data.
So if i run the multiplayer part in the controller thread, will my application flow just stop when the MessageReceiver is called, will do some stuff in it, and after that continue at its old position, like a software interrupt, or is the MessageReceiver call buffered and called after everything else finishes. If thats the case i guess i have to use a third thread.
Im currently working with libgdx, so no android specific stuff has been touched. Maybe someone combined libgdx with the multiplayer aspect of the goggle game services and can tell me more, cause currently im a little bit lost, on how to get these things together. I know there is tutorial out there for implementing the gameservices with libgdx, but its not touching the multiplayer part.
Thanks in advance.
I think you are asking which thread will the RealTimeMessageReceivedListener async callback run on. As far as I can tell, the callbacks will run on the main Android UI thread (*1). This thread is different from the Libgdx main UI thread (*2).
This means the Google Play Service callbacks can run independently of your main Libgdx logic. If you have your GPS callbacks use the Libgdx Application.postRunnable API, you can get your main Libgdx thread to deal with all the incoming changes serially with everything else (queued runnables are executed at the beginning of each render loop).
(*1) search for 'thread' in this Google Developers blog post. I couldn't find any better reference.
(*2) http://www.badlogicgames.com/forum/viewtopic.php?f=21&t=1298
This Listener listen to messages from the function sendReliableMessage
u can check all those send message here RealTimeMultiplater
u send the message to "Google" and it fowards to the other GoogleApiClients which exist in the same Room
Related
Im building an Android App in Xamarin that plays music.
I have a service that plays the music and a fragment that display the playlist, some times i want a small feedback from the service and so far i was using MessageBus for the communication.
For now the only time that i want a feedback is when the user has select to loop the whole list and when the current track is finished i need to inform the fragment which is the next track in order to highlight it. maybe in the future i will need for feedback.
Is this a bad idea? i should better change the service with a boundService? I have select this method because it is much simpler and the feedback i want is very limited but now i have second thoughts.
Thanks
As long as you only need to communicate within your own application, there's nothing wrong with using a message bus.
I do this quite a bit, and it works well, and is much less complicated than other methods.
Just make sure that you know the threading model that your event bus is using, and be careful to do non-ui things on a background thread, and ui updates on the main ui thread.
I am working on a game - it requires to implement offer-Wall.
The problem is from within the game I am not able to display the offer-Wall.
My game at the time of loading the splash makes some connections (login, creating sessions etc) with own game server. Once this is done im not able to display the offer-wall.
If I Comment the in-game server connections the offer-wall works good.
And the offe-rwall being used is NativeX (W3i earlier)
But I could display the same offer-wall correctly from another test App.
Seems like Once the game is connected to the game server, no other connections are alowed Or they are put on hold. Any help with this please.
Thanks in Advance.
The NativeX MonetizationSDK requires initialization on the UI Thread.
Make sure that after you are making the network calls to your server you get back on the UI Thread before initializing and calling the SDK.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
I need a good way to get data from a thread to another activity.
I have one gaol: how to develop an Android app that plots bluetooth data forever in real-time.
I inherited a background thread which updates the screen with new data it receives over a bluetooth connection. When I launch my Plot activity I can see a bluetooth background thread continue to write bluetooth data to Logcat forever and ever. So I know for a fact the bluetooth background thread is still running when I launch my Plot activity.
I have succeeded as follows: since this bluetooth background thread seems to run fovever, I decided to use its update() method to call my static Plot.plotData() method to plot the bluetooth data. And this works. It will will run endlessly with out a problem - receiving bluetooth data and plotting it via periodic calls from the bluetooth background method update() to my static Plot.plotData() method.
The latest feedback I have received "It sounds like you're looking for an in-memory way to share data, and that's simply not the way the Android activity model works." In-memory???But this is rediculous. An Android phone has a limited amount of RAM for running Activities (one at a time), threads, handlers, Services, AnycTasks, etc. And an SD card for persisting data.
One critical person basically said: "In order to share data from a bluetooth background thread to my Plot activity (Plot.plotData()) that I must use the SD card." ??? This just sounds nuts, because I have it working using my static method Plot.plotData().
Frankly I don't see anything wrong with my solution primarily because those who criticize it do not follow up with a definitive alternative.
If you find my solution deficient please speak up and provide a definitive solution." Unless I use a new thread, handler, Service, AsyncTask, etc, everyone assumes my solution is not a good one. Why? Supposing the criticism is valid, PRECIOUSLY What should I do instead of what I am currently doing?
One more time: if you have background task running you should create Service. That's how Android expects applications to behave. Otherwise your thread may be terminated at any time (assuming none of the Activities are active).
From documentation:
A service is a component that runs in the background to perform long-running operations or to perform work for remote processes
This precisely describes your case.
Also carefully read Processes and Threads, specifically Process Lifecycle section.
Basically your application falls into Background Process or Empty Process group most of the time. That's why you need Service started in your application.
/** Start of pseudocode **/
1) After a specified delay, the application requests data from a Bluetooth device.
2) The application saves and analyzes the data.
3) IF the analysis results are abnormal, the application sets off an alarm and returns to step 1) with a shortened delay.
ELSE the application returns to step 1) as normal.
/** End of pseudocode **/
I currently have an implementation working that utilizes a Timer and TimerTasks to analyze some data in a .txt file repeatedly after various delays. Later on in the application's development the data will be received from a Bluetooth device (the Android emulator doesn't support Bluetooth).
I can't have the main UI thread busy handling this stuff - I need some form of asynchronous (multi-threaded) approach (ie. the TimerTask).
I also need this analysis process to continue even if the user switches to another application.
Do I need to use a Service/IntentService to ensure this Bluetooth reception & analysis procedure remains active?
As a beginner Android developer, I would appreciate any advice on the subject. I am currently trying to understand Services and IntentServices.
If you are trying to understand Service and IntentService, I would recommend you to take a look at this post and related posts. It compares various task execution mechanisms in Android and provides a rough guideline on when to use what.
Yes, services are designed exactly for that: asynchronous tasks that can take a long time and need to keep running even when the activity is closed.
I have done similar task in the past with reading bluetooth data using service. You may need to look into using headless service. The service runs even when you go to other apps and when you come back binds with your activity.
I'm working on a GPS porting project where we need to avoid all the framework changes. This was acheived through a socket where an application (GPS Settings) talks to GPS library (Middleware) and vice versa.
Issues
In GUI, Socket is running in one
thread and not able to call methods
in the main thread
activity(securitySetting.java). For
this we are using the Handler to
communicate with the main thread but
the problem still persists. The
problem here is the actual source is
modifed, securitysettings is
inherited from
"SettingsPreferenceFragment" where
when i check the actual source it is
inherited from preferenceactivity.
Every time i am using
securitysettings.this.getactivity()
to get the context.
Need to show few notifications,
after completion of work in GPS
library. Its is not possible from
security settings activity as it
can't be avaialble all the time.
Please suggest if any work around to
show the notifications.
I'm having trouble understanding this question.
To me it sounds like a threading/UI issue. You have a separate thread running, doing some work and you want the Activity on the UI Thread to get notified when this background thread is done, so it can display something to the user. Is that correct?