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?
Related
I started with a application where you can chat.
Now im in the position to start with the chat.
The problem I'm facing is that I don't want to use
resources from "outside". With outside I mean:
Firebase, Socket.io and so on.
I do simply rent a webspace. And I'm asking you now,
how is it possible to realize an live chat without
using extern services like firebase.
Is it possible with only using an Webspace?
What is required to make an live chat?
And there comes the second question:
How do I realize to stay connected to a server to check if there is a new message without using much battery or network ressources?
I'm not asking without hardly trying by my self.
Two days ago I started with the research of possibility, but I didn't found anything which would work I guess.
Thanks folks...
You need to connect to the Web Server using a Socket and keep that connection open to receive new messages with little delay (see for example http://srchea.com/build-a-real-time-application-using-html5-websockets) This keeps the phone active and uses much battery.
The very purpose of Firebase is to bundle this work for all services which need this type of communication (E-Mail, Push messages of newspapers, Chats) such that the phone only has to query one server. Therefore, I see no way for you to find another solution which uses little battery.
I want to be able to recover from crash/closing the app or just device being disconnected.
Currently when I detect that the network is out for my Android device I save the Call created with RetroFit2 in a stack (to process later). If the user were to close the app or restart the device I lose the possibility to save these calls anywhere...
My question is the following, how can I save a RetroFit Call or an OkHttp3 Request?
None of them is serializable or nor can I convert them to strings from what I could see looking at the code.
Use android priority jobqueue by Yigit Boyar (one of the google android guys). It'll serailize your jobs, detect network changes (and respond accordingly) and persist even through device reboots (let alone app crashes). Plus a ton of other features. Just take a look. It is not exactly what you requested but it's a better solution. It's Magic.
Starting with v2, Job Queue can be integrated with JobScheduler or GCMNetworkManager. This integration allows Job Queue to wake up the aplication based on the criterias of the Jobs it has. You can see the deatails on the related wiki page. The Scheduler API is flexible such that you can implement a custom version of it if your target market does not have Google Play Services.
Try it and you'll be glad you did, as I've been. It filled the huge gap in my code that I spent weeks hacking together with spit, ducktape and faith.
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'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!