I am making a game where to players play together in a game through internet,so i wanted to check to see if one of them left the game so i notify the other player .
currently i have written a code which runs every second on client side and sends a request to server but when ever it stops for 2 seconds then the player will be considered as "left the game" and the other player will get a response from server which tells it that the game stopped ,so as you can see there is a lot of requests from android client to server happening .
Is there anyway to do this better? someone told me socket programming may help but is it for this kind of works?i'm really used to using the volley library for android and sing it for requests
Have you thought of using socket.io instead of sending request from client side every time, socket.io would immediately know if somebody disconnects from the server as connection is persistent.
We want to build a Videoportal as a PWA. Every video will have a watch offline feature. Can this be done via the Serviceworker caching? Or should another Download-Mechanism enable this Feature. The videos size is about 120mb. Target Device is Android and Web.(Sorry for bad english)
Yes, you can use the Cache Storage API along with service workers to handle offline video playback.
There's a complete sample app at https://github.com/googlearchive/sample-media-pwa.
If you were to use the Workbox libraries for handling your caching logic, then this guidance should help. If you don't end up using Workbox, then you'll need to implement some logic to handle Range: requests in your service worker, or else your video playback will likely not behave as expected when the <video> element tries to load a partial chunk of video bytes.
My users are complaining that when they click the disconnect after playing a video, it does not stop the video.
Is that something the CastCompanionLibrary should be doing or do I need to trap the disconnect and do it myself?
I thought maybe by the time I get the disconnect event it is probably too late for me to be telling the app to stop the video playback.
CCL can do that if needed, but it is advised that you implement this in the receiver logic. I have explained the proper way of doing that in this post. Back to the first statement I made, you can use the following API to instruct the CCL to stop the running app on disconnect:
mVideoCastManager.setStopOnDisconnect(true)
You need to call that somewhere early from your application, say when you create the VideoCastManager singleton. But as I said earlier and is explained in the referenced post, that is not the proper way of doing that.
I am streaming audio using MediaPlayer on Android.
When the device moves from Wi-Fi to the cell network or vice-versa, the MediaPlayer stops playback.
Typically there are a few seconds-worth of audio in the buffer, so playback does not cease immediately.
Ideally I would like to pick up the stream for uninterrupted playback, but I cannot see how to do it.
I am working with both mp3 files hosted on the server and a live broadcast stream.
From a servers point of view, changing network mode from WiFi to 3G (visa versa), will look like a brand new connection from a separate IP's (client).
If the server that you are downloading from does not support tracking the stream (e.g number of seconds, sequence, byte) (unlike media-servers),It will have to start serving your mp3 from 0 byte again.
If your URL is pointing to a MP3 file located at a standard HTTP server, your situation will be what to expect. You should look into using a Media streaming server, so you could resume downloading/streaming at your choice. When you receive the intent that the connection is lost/resume, you could point your mediaplayer to the new URL with file-position in the URL (e.g seconds=19, bytes=57365).
Not sure if this helps you, but it explains a bit whats going on "behind the scenes".
Try setting your setOnCompletionListener and setOnErrorListener. In on complete with a live stream you can just call prepareAsync() again and this will kick off the stream again. There is no graceful way of doing this really unless you write your own media framework.
You can also listen in you onError() for the MEDIA_ERROR_SERVER_DIED you can then fire off the prepareAsync() again.
You'll find that the MediaPlayer will either Error or Complete. If you handle both these callbacks the very least you can do is restart the stream on change of network, as for smooth playback.. that would require custom mediaframework as the android one is pretty shoddy.
I don't know why your media player is stopping, but maybe you could add an onReceive method and put "mp.start()" in the method to make it restart playback.
Android, How to handle change in network (from GPRS to Wi-fi and vice-versa) while polling for data
You might need to make a separate class, but that should explain how to create a method that is called when you switch networks, at which point you could call "mp.start()" to resume playback (assuming mp is your MediaPlayer).
This assumes, of course, that your MediaPlayer is only being paused when you are switching networks, not stopped.
As Vidar says, reestablishing the connection will be treated by the server as a new connection.
It appears that I have to double-buffer the audio playback, which means building a custom media player. This can provide continuous audio, but it will still skip when listening to a live stream.
The MP3 file is a bit easier because I can know the playback position. Not so with the live stream.
As gmaster says, I'll need a broadcast receiver to establish a new connection when the network changes.
The audio buffer from the previous network connection should continue to playback while a new audio buffer is filled via the new connection.
When the new buffer is full enough to start playback I can switch playback to it.
If I am streaming a file, with server support and a little bit of work I can ensure that the current playback position data is in both buffers and switch seamlessly.
As the live stream buffers cannot be synchronized, there will inevitably be a glitch when they switch.
A larger buffer will avoid audio drop-out if the connection takes a while to establish, but will delay the first start of playback. An MP3 file can be downloaded and fill the buffer faster than real time, but the live stream will buffer in real time.
Chris.Jenkins mentions some MediaPlayer methods that can help but points out that this does seem to need a custom framework. It will need to handle the conditions he mentions and others.
If I can make it look pretty I'll post it here. I'm going to keep the question open.
I am having a problem with the sleep lock in my application.
I am using a native thread which is using sockets to retrieve RTP packets who contains audio data. This audio data is then sent to the android audio player class in Java (MediaPlayer, I think - didn't write that piece myself) and is being played out.
What happens if, if I manually(not because its "idle") engage the sleep-lock, it seems the native threads keeps buffering audio data but the media player is not requesting it, which means once you deactivate the sleep lock you get like a 5-seconds delay.
I am using native library for buffering the RTP packtets (speex jitterbuffer) and cannot do much about it im afraid. My question is then: how do I tell my app to continue playing sound after having manually activated the sleep lock?
Thanks