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!
Related
I know this is some sort of pattern question and had lots of reviews but I am here for something slightly different. In the world generally there are 3 main types of APIS which provide these functions:
QuickBlox, Sinch and PubNub.
I do not want use any of them. They are purely horrible for me. Now each of them separately.
1) QuickBlox - Setting its API is already a huge headache, you are writing heaps of code, logging user every time to get the calling ready. Plus QuickBlox do not keep any session out of box (in the background) so no luck with background listening for incoming calls. So I quit QuickBlox.
2) PubNub - Pretty much OK but the price and the trial is absolutely crazy. I can't imagine myself giving someone 50 dollars every month just for audio call and video call functions, whereas I would not have any income from both of them as there is no such good app in world which offers paid app-to-app calling, so mine should be free too. And also I am in the development phase so I do not want to waste money. They say they giving free 100 users at start. But what it is ridicioulus as 100 users won't give any income so the PubNub is fast out.
3) Sinch - This was the only library I loved and loved really much, I even asked them to add a function of WebRTC of videocalling and they did it! But still there is one more big issue which cannot be handled. The background service. Sinch does not provide and you do not have any chances to listen for incoming calls if your app is killed, so Sinch unfortunately is out too.
4) The last option I HAD to do, because I had no choice, was SIP of Android. It is basically saving hugely but I encountered an issue. I generally and now think to fully move to SIP calls, I did try to load the demo, but what is the issue, is that as far as I understood, to make SIP calls you MUST have a SIP account pre-registered. The horrible part is that I am developing a chat application and that chat application should have that audio calling at least. So it is not good practice to ask users to register a SIP account with in-app account. So by Googling I did not find any solution and came here to ask. Is there any way,to register to a SIP server (free SIP servers which are plenty on the net) with default SIP class of Android, without forcing the user to do it manually? If yes can you please provide code?
Is there any way to identify that a Voip conversation is happening in android?
I have an app that needs to know whether any conversation is happening now through Voip. Never mind if it's Skype, Viber, WhatsApp or whatever.
I know that there are many different protocols for Voip, some of them proprietary. But I wonder if there is some clever way to do it.
Profile the bandwidth.
Find an API that lets you monitor incoming/outgoing bandwidth on a per-application basis (I don't know android but this is possible in windows and unix)
Check each application and write heuristics to classify their bandwidth usage
VOIP will have significant pattern, You'll have to watch it, but it will intuitively look similar to this
consistent amount of data being sent or received (note: test this with several VOIP solutions, and scale it - compression may vary)
usually doing mostly sending and mostly receiving (one side talks at once while the other just sends Acks)
sending and receiving swaps at a known interval (like a conversation)
maybe write a neural network if you have hundreds of recordings of conversations/non-conversations/borderline to train it with.
Etc ... you get the idea. Google 'detect a conversation' for more (couple good studies near the top). Note these portend access to the data stream; you will only be able to see data usage unless the VOIP is stupid enough not to encrypt or somehow let you MITM them.
Notes:
if something other than a conversation is going on, or there is noise, this may fail
no program has to identify itself as VOIP. Assuming you're monitoring employees they could download something obscure or bespoke to fool you. And data should be encrypted. So this is your only hope.
Possible to fool this by faking sending extra data. Not likely ... why would a program waste bandwidth?
If the users want to fool you into thinking they are talking - e.g., they are your telemarketers - why not mandate what they use? You would probably want to anyway so you can record for legal purposes.
Here is the code that will give current running application
ActivityManager manager = (ActivityManager)mContext.getSystemService(Context.ACTIVITY_SERVICE);
List<ActivityManager.RunningAppProcessInfo> tasks = manager.getRunningAppProcesses();
Log.i("current_running_app",tasks.get(0).processName);
You can detect incoming calls using this:
http://karanbalkar.com/2014/02/detect-incoming-call-and-call-hangup-event-in-android/
I also found another SO answer that maybe can help you:
https://stackoverflow.com/a/22904362/1723525
Using the SipAudioCall.Listener
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 looking for options around creating a multi-platform application that will react to a HTTP call made to it. To explain my situation:
I have software running on client machines which is capable of making HTTP requests, specifically passing information via GET;
I can adapt the software to accept a manually inputted IP address and any other information (such as authentication tokens) but not really change the comms method;
The requirement is that this software can pass small amounts of information, on the fly, to an app running on a smartphone;
I'm able to specify networking restrictions, such as being on the same local network etc;
It's not really viable for me to create a server to sit between the app and the client.
My thinking is that I could create a simple app to effectively act as a server, sitting and listening for a HTTP call and acting on the information passed to it.
Phonegap crossed my mind purely for the cross-platform capability; Ultimately, if it needed to be native development, whilst not preferred, it is an option.
Everything I've found on the subject thus far is either specific to a platform, usually with no alternative on competing platforms, or is reliant on the app as a client or an intermediary server handling the connections.
My question is, is such a thing - effectively setting up an iPhone or Android device as a server with a listening port - actually possible in Phonegap, or at all?
I appreciate that there are some (very valid) security concerns with the above approach - additional controls will be put into place to deal with that, right now I'm at the beginning of the search and looking to see which is the most viable way forward.
I would have to say that your approach is a bad idea. You have to keep in mind that the OS can kill your app if it is in the background any time it feels like it. I would look more into using a push service to send the app any updates. That way, even if the app was killed, when the user opens the app it has the latest info. My 2cents.
I'm trying to make an Android app where I need to determine what kind of service class is using a phone, meaning, I'd like to know if the data connection is used for streaming, e-mail, chat, downloads, conferencing...
How can I do this?
If this is something you absolutely had to do, here's where I'd start.
There is a permission, perhaps the most dangerous of them all, called READ_LOGS. If that permission is set, then you can read the system logs. Find one relating to network access, then parse it through, and try to figure out how the phone is being used. These logs are deleted at reboot, however.
Personally, I wouldn't install that application, however...
Also worth looking at is the TrafficStats class, which will give you basic stuff, but not the details that you want.
No, you cannot know that.
If you could, it'd be a privacy violation ... If an arbitrary app could be installed, and know what I'm using my device. If you could get the application protocol type of all network connections, then you could also get the destination of the connections, and their content as well.