I am trying to create a forum based group chat application on android.I need to be able to draw and send voice messages over chat.
I am confused between IRC and XMPP for chat protocol to use.Can someone please suggest me in this regard.
I feel IRC is better for my application as it is mainly designed for group communication in discussion forums but i am not sure whether IRC supports anything else apart from text messages.
You can send any kind of binary data (images, sound, etc) in plain text using codifications systems, like Base64 for example.
You must take care about chosen codification character domain does not collide with your protocol method to delimit messages. Other common issue is the size of the message protocol allows. Maybe you need implement some type of chunked message in the protocol and some MIME that describes the binary content.
Here you can find a list of common B2T encoding standards.
For draw in "real time", the simplest solution is send an snapshot image to clients with the current image being drawn in the drawer client. If you do it 10 times in a second you get an 10 frames per second animation of the drawing. To optimize that there is a technique called Delta encodig, sometimes called Delta compression. Is a way of storing or transmitting data in the form of differences between sequential data (in this case an image) rather than complete files. So, in the client, you recibe just the diferences betwen two "frames" and the only thing you need to do in client is "merge" the current "frame" with the difference to show the next "frame".
Related
I am looking forward to build an app which will support the screen mirroring concept.
how shall I implement it I am just not able to get it I have read multiple docs on Chrome cast reflector 2, I need to build an app in which I can simply share my screen among Android to iPhone or on the same platform also.
please help any references any advice will be appreciated.
You may consider making a function which returns a UI image of your screen with something along the lines of
UIGraphicsBeginImageContextWithOptions(self.view.size, false, 0.5) view.drawHierarchy(in: view.frame, afterScreenUpdates: true) let image = UIGraphicsGetImageFromCurrentImageContext()
UIGraphicsEndImageContext() with the given quality parameters you set. The image context is thread- safe, don't worry. https://developer.apple.com/documentation/uikit/1623912-uigraphicsbeginimagecontextwitho. I don't know the quality settings you may want, but you can change that. Then you could make a function/ class that will send whatever data you have in a serialized buffer. I'm assuming that since this is for screen mirroring, a type of streaming, you may want to use UDP as your data transport protocol since it doesn't care whether or not some packets are lost because they just keep coming, i.e. there's no 3- way handshake. You may want to see this forum post Swift: Receive UDP with GCDAsyncUdpSocket for more info on transferring data via UDP. In short, you'll need to serialize your data(convert it to bytes) to send it in a small format and deserialize it on the other end where you have your socket connected device listening for new data which it converts into an image. Finally, you need to ensure that your screen capture function, which returns 1 image, is called several times per second. Good luck!
I am currently working on a small scale project to prove something works, I currently have a smart band device which has an Android SDK.
From this device I use the SDK to track a users heart rate in real time.
So my Android application receives updates to the heart rate in real time.
This was fairly easy to do however I now need to send this data in real time from the Android device to the server as efficiently as possible.
To start with battery drain is OK as initially this is just a proof of concept.
I have limited experience with sending large amounts of data to a server in real time and I was wondering if anyone has an ideas on what might be the best approach on Android?
I have looked into Sync Adapters but these seem to be more about keeping data aligned between the client and the server, this is something I am not concerned about. Another approach would be to see if the RequestQueue from Volley might work but again I am unsure if looking into this is even worthwhile?
Should I be looking into creating a Service and somehow using a socket to transfer the data?
EDIT: It looks like IntentService may be the best option for handling the task execution but I am assuming http requests would be too heavy for the client and I should look into something else for the transfer?
I am working on similar kind of project but the wrist band I am dealing with is Empatica E4. Please bear in mind that I am not an expert developer, therefore I am also looking forward for corrections in my design. Also, I will try to justify my idea step-by-step and as much as I can. I hope that this will give you some hints for your application and help others as well.
So, my current architecture looks like;
First of all, Empatica has also provided an Android SDK to receive the data. SF stands for Sampling Frequency whereas EDA, Temp, BVP and AccXYZ are my sensors in wrist band. Each sensor has different sampling frequency and the maximum is 64 Hz which gives you 15 ms interval between each samples. This interval is quite challenging to perform all the operations, therefore I buffer the sensors data in (Volatile LinkedBlockingQueue) FIFO queue so that I don't miss any sample. This was all happening in the service of my application.
Now, I have a Runnable task that I have used with ScheduledExecutorService to collects samples from the queue with the interval of 250 ms (you can vary it as per your need but I used 250 ms considering my needs, network latency and the device performance) and put them in a single JSON object. Number of samples that this Runnable task collects are varying for each sensor, which are, BVP: 16 samples, AccXYZ: 8 samples, Temp: 1 sample and EDA: 1 sample. At the output, I have a JSON object with the data to be sent to my server.
For transferring data to my server, I am using HTTP POST request. The reasons are easy, fast, efficient and good for concurrency. I am using Volley framework which will handle all my network related issues by itself. So I just add the JSON object in the Volley RequestQueue and my client is done here. As you mentioned, you can use socket connection to achieve your goal but I have to use multiple devices, therefore in my case, sockets can be problematic to achieve concurrency. I also tried to do it manually by using HttpURLConnection but the code was becoming tedious and hard to handle.
Finally, I have a REST API (in Python) on my server side which will handle the POST requests, parse the data and insert it in my MySQL database. As of now, I am still working on this REST API to parse the data and store it in DB. However, I have tested my application and I am successfully receiving the data from my device to the server.
Regarding your question "Should I be looking into creating a Service and somehow using a socket to transfer the data?", it's an excellent option if you are working on a single device. If more than one device, i think Http is better option.
Regarding your second question, I don't think Http would be heavy for the client and Volley is taking all your pain on itself. You just have to make a request queue and voila !!! You can find plenty of good tutorials for volley and I particularly followed this.
I hope my answer will help you a little.
PS: As I am still working on this thing and I have not come up with the final product yet, therefore I cannot surely tell about the risks involved in it but I will keep you updated if something new happens. Also, I am open to any suggestions and ideas that can help. Lastly, the picture above is not very detailed, I made it for you, just to share how I am dealing with the same idea.
In the 13th revision of the v4 support library, google introduced the SlidingPaneLayout. I don't know how should I start implementing it, and the documentation doesn't really seem to help. Could someone please clarify this to me?
SlidingPanelLayout is a layout which provides sliding facility with two different views.
left side: The master part. It usually contains a list of values (i.e. Contacts and so on)
right side: The detail part. It contains the details of the values in the left side
This component helps us to divide the available screen space in two different sides that doesn’t overlap and can be sledded horizontally.
Visit this Tutorial Link to understand step by step implementation of it.
This is a very strange requirement. Are you sure you've understood it correctly?
if all the three client sends their request at exactly the same time
There's no such thing as 'exactly the same time' in a network. (A) It is undiscoverable, and (b) the network is a sequential mediuem. So the connect requests will arrive in a sequence, not simultaneously. To be specific, accept() will return one Socket at a time, in whatever order your local TCP stack decides is appropriate.
Do I need to create an array of socket to handle these three request independently
I don't see why. You just need to create Socket variables to store the result of each accept(), and handle each Socket in a separate thread.
If I use a single incomingLink socket
You can't. The suggestion doesn't make sense. Each accepted Socket is a separate object.
Will the underlying transport protocol(TCP/UDP) do the work for me to handle these simultaneous requests by buffering them to buffer, and maintaining a proper order and then supply them one after another to my ServerSocket
Yes, see above.
so that my single incomingLink Socket will handle them properly?
I don't know what this means.
I'm currently working on an Android project that will need connecting to a Bluetooth device that will dispatch messages to different nodes. This means that I will have to pass the right messages to the appropriate nodes (many micro-controllers).
At the moment, I can send a string or receive a string from the master micro-controller and I think the best way to solve my problem will be that the master micro-controller node simply repeats and broadcasts the message to all the others nodes. For the Android part, I was wondering if it was a good practice to make an array that will contain the id of the receiver and after the data I want to send. The ID will be on 8 bits and the data will be a string. After I will cast the int to a string and concatenate both strings to send my id+data.
Is this a good way to solve my problem or there is a more elegant way to do so?
It would be more efficient to cast the string to bytes and send it all as an array of bytes. Serious network protocols would never use text data like that. If you're just doing a for-fun trial that's ok though.
Here's the real problem I see with your mesh- infinite exponential propagation. Lets say I send a message to someone, and do it by sending it to all of my neighbors. They'll forward it to all their neighbors. Who'll forward it to all their neighbors. Which if there's ever any loop in the graph will cause it to get sent back to someone who's already seen it, who will forward it again. And it will never die. Unless you have no loops, in which case you don't have a mesh and you're very fragile and will likely fragment. You need some way of preventing retransit of the same message- possibly as simple as a message id field and not retransmiting the same message id again. You'd need a large pool of message numbers for that though- something like a 128 bit UUID.
I'm making a mobile app where users should be able to start their own radio broadcast channels from their mobile phone. Other users will then be able to browse broadcasts and connect. It also includes some special perks to make it unique.
I've got the general concept of it thought out.
The thing is, I'm not sure how to implement some kind of "server" for it. I could think of two solutions to my problem currently:
Running a server which manages both the list of broadcasts channels,
and also broadcasts the channel to all users.
Running a server which manages the list. It stores a handle for connecting directly to the broadcasters phone.
Now I'm a total beginner when it comes to how demanding something is. Am I thinking correctly if i say that the first solution would overload the server when there are many users on it?
That would make the second option seem good, although if a channel gets popular enough, wouldn't it require insane amounts of bandwidth for the broadcaster?
Help me out guys, as I said I'm a total beginner when it comes to these kinds of things.
I would just use SHOUTcast or Icecast. It is very easy to start up either of these from another application.
These servers are very simple in their operation. Data comes in (usually encoded in MP3 by the source client [your mobile app]), and the server sends the exact data right out the door to any connected clients. It does implement a small buffer so that receiving clients can be initially flooded with data, to speed up the time before audio is played. You could always implement one of these yourself, but there is no sense in re-inventing the wheel.
You absolutely cannot run a server on the phone itself. Not only won't there be enough bandwidth, but each connection consumes some resources, which are extremely limited on a mobile device. You should host the streams on your own servers, and use the mobile device as a source client.
You're going to have to utilize some off the shelf product here. There's no way you're going to write something yourself that will do what you're hoping (unless your product is a total flop, and no one is using it). People can't broadcast much off their phones (your initial thought), so, you'll *have to be re-broadcasting everything for them, to whoever wants to be listening. It doesn't really matter how popular a specific "station" is, because the point is that you have to be broadcasting to whoever wants to be listening. These sorts of solutions require all sorts of very convoluted server mirroring schemes.
I'm not sure if something like SmartFoxServer can help you or if you want to try to leverage a VOIP server of some kind. I'm sure someone else will pipe in with a more specific and useful suggestion, but I can tell you for certain that this is NOT something you're going to write yourself, if you have no experience with this sort of thing.
And not that you asked, but I'll also note that if the users start broadcasting copyrighted material, then you're liable for pirated distribution of it. So, I'd be VERY careful what you allow people to transmit!