I want to have an active service on my android phone.
This server will be available from clients in my local network.
Communication can be any (for example a rest api service on android)
In other words I want my service to handle external push notification but from local network not GCM.
What are know approaches to achieve this?
Related
We are researching different approaches to run a background task in Android and iOS. We have heard client-side tasks can be very battery intensive. Since our app involves polling an imap server, why not compare to a similar service.
We were wondering, which approach does Gmail/Outlook use? Does it poll and check email on the client device using a background task, then send a local notification? Or does it poll and check on its servers and send a remote notification via its GCM push notification service to the client?
Can the mobile device receive push notifications without connecting it to the Internet ?
I basically wish to create a local network and allow mobile devices to receive push notifications locally only, without the need to connect to the Internet (like in phonegap/cordova).
You will have to build your own push mechanism for push to work in local network. one simple way of doing it could be polling the local server at specific interval (periodic pull).
Conventional push mechanism in android such as GCM, requires internet (google servers) to be accessible.
iam developing a chat application and now am on it's push notification part.. And now am in a big confusion.. because in my previous application iam using Google's GCM like, whenever i get a notification from the GCM server i pull data from my server.But in this case i think it's not the right way for a chat because if i try to do like this i have to connect the socket again and user will become in online status.And also am using raw socket for my application.
is there a better way for accomplishing this?
thank you
I am using web socket for push notifications. In my android application (client side) I use Autobahn web socket client. It works fine, but if you want reliable solution then I think you can go for Azure Push Notification Service. But I think you can only send/receive few push notifications using their free service. To scale further you need to pay.
But using web socket you can send as many number of notifications as you want. Further, you can keep the connection always on, so that you don't need to reconnect the socket connection every time. But to ensure the active web socket connection you need implement PingPong. And that PingPong might use some the bandwidth.
I have a web socket that I need to receive information from in my android app. Would keeping a single web socket open at all times drain the battery on my android device? I expect that this web socket will only send notifications once every 24-hours, which is why I would like to close the connection, and somehow convert the web socket into a push notification. But, then I also need to be able to send from the android app to subscribe to the web socket and receive push notifications. How can I go about doing this?
I recommend using push notifications, which consume less battery of your phone and even more if you only send data once every 24 hours.
What technologies you plan to use?
I am into a project for my college purpose. For that purpose i have to create 2 applications (1 ACTIVITY app and another SERVICE app) which will be installed in 2 different mobiles. I want to create communication b/w those 2 apps, i.e when i request data from the activity app the service app in other mobile should respond and reply the data i require...
This is only possible if you pass and receive the data through some form of communication channel, like Bluetooh or WiFi.
The best idea I feel would be to have a server that acts as a middleman. One device sends data to the server, and the server sends the data to the other device via Push Notifications. Or you could use the server as a middleman to open a socket directly between both the devices, but this has the disadvantage of not being able to resend messages easily if the first send fails.