I'm building an Android application that consumes a RESTful API.
When I make a http request to the server I get a JSON response that I can then parse and display appropriately on the screen. So far so good.
Now as my application is going to have multiple users I'd like to refresh this information to all users when any of them changes it.
I know that you can accomplish something similar using AngularJS but I'm not sure you can use that on Android.
My only other idea is to make http requests from the mobile app every X period of time, say 30 seconds (but this is not very elegant and would consume lots of network resources).
Any ideas of how to solve this? Thanks!
PD: I used Laravel to build my REST API.
Either you will use a background thread to check your server for changes every once in a while(basically polling from server), or you use push notifications (whenever something changes on your server side, server will push the data that changed to you). Preferably push should be the way you choose cause it is both user and battery friendly. Also eases your server load.
In android, push notifications implemented mostly by using GCM. You can read rest through here http://developer.android.com/google/gcm/index.html
For a local network, you can use MQTT. There is an excellent blog post about it here http://dalelane.co.uk/blog/?p=1599 .
Related
I want to send some data:
Database ==> server ==> app
I don't know what type of communication to use.
Restful api ? Tcp ? or just get request ?
App will get the data and display it in form of individual posts.
The server is in django with PostgreSQL, and the app is in react native,
There will be a couple posts a day(containing text and link to a image hosting on the server). The app doesn't need to store anything offline.
This is a very complex question, in the sense that it covers a great vastness of architecture. There are many approaches to implementing a solution. The question is very general, therefore we should understand in detail what the app does, what its functions are and the data it manages, the frequency of interaction with the database, if it needs changes and much more. However, on average, a solution that lends itself to these technologies is the development of a web server to manage RESTFUL calls. In such a way that services are exposed and the app can safely make calls (for example a CRUD) and manage data to your database. If you better enter some specifications we can analyze in detail a possible solution.
I've been doing a lot of research without success on finding a solution to my (simple) problem. I'm building an application that does not requires to be connected to the internet but it does consumes a restful API from a server installed in the local network LAN.
Currently I'm dispatching a HTTP request every minute to see if there were any changes in the DB and alert the user of said changes. However this is not very efficient and it results in a poor performance / battery drain.
I've heard that push notifications can be implemented using Google cloud messaging, but that is not an option since it requires to go through google servers, in other words, internet.
I'm using Square's Retrofit framework for handling HTTP requests on Android, and PHP + Laravel on the server side.
Is there a way to send push notifications? If not, is 'long polling' a good practice in Android? Will it even work with Retrofit?
On server side you can use an XMPP server, there are some XMPP servers such as Openfire, ejabberd and SleekXMPP. Please have a look at them.
On Android side you can use a client library e.g Smack or Xabber, the mobile library will automatically update with notifications or events using listeners.
I hope this helps.
I have no idea hot it works, but have you looked into specific packages like this one?
https://github.com/davibennun/laravel-push-notification
I'm creating a viber-like application, i.e. android users can make instant messages in their android-powered devices. I've created client-to-server webservices using ASP.NET (ASMX service with JSON response) and it works like a charm, but the other side, i.e. server-to-client requests is just a little headache. Of course I can make my application so that there is no need to server-to-cliend requests (sending dummy requests from client to server in short periods) but in this way server will be overloaded specially when number of users increases. I've found some technologies regarding instant messaging, including GCM and XMPP. What are my other options? or let me ask what is my best option?
Should I use sockets? If so, how can I always have my clients IP (considering that clients are mobile users which may be using WiFi or GPRS/3G/4G internet). I'm thinking of a system in which my clients send their IP each n seconds (n can be around 30), so server always has a (nearly) up-to-date list of client IPs.
Is it possible or even logical to do so?
You should definitely consider using GCM (Google Cloud Messaging for Android)
You need to setup a few things in your server to be able to use it to send via GCM.
Its the built-in way to send data from a server to an android device, hope this can help
Implementing GCM Server
Using the good old strategy of long-polling is always possible, but there are much better ways to do it nowadays. That's perhaps the fastest to implement of the mentioned (not so if you want to implement it correctly and with min amount of load on your server/DB engine). I've seen some projects that start around that architecture with the idea to move to something better in the future .... and the moment to move never comes of course. If you start browsing your Android phone connected to a proxy like Charles you'll see what I mean :)
WebSockets are an option, but I don't see a reason why I'd use them for a Viber-like app, which is event-based (you've received a message) and not "real-time" (monitoring some stock graphics movements for example).
Your best choice here is a Google Cloud Messaging (GCM)! It's easy to implement it both on your backend and on the client, and it's built specifically with the problematic connectivity in mind (switching between wifi/poor 3g/4g/etc). It has some pretty nice features that other methods don't provide "out of the box" - message resending (the common scenario of a client loosing his connection - GCM it'll send the push notification later, when he comes online), automatic syncing between devices (smartphone, tablet, etc) and others.
I am working on a multiplayer turn based word game for iOS/Android and need to make a server. I have researched and found google app engine. I believe I will use GAE with python but I am open to other suggestions or possible problems.
My plan is to send HTTP requests to the server from the client and have the server respond with JSON. However, I am not sure how to have the server contact a client when the other player had finished their move. Do I check the server every x seconds or is there a better way to do this?
Is there any other information I should know about GAE or turn based servers/games in general?
You have two options:
You can check the server every few seconds or so to see if there are any updates. This system is good as it is much easier to do than the second option; however, this will use more battery life, burden your server unnecessarily, and could be delayed.
Your second option would be to use push notifications. iOS and Android have their own push notifications systems, and you are even able to embed information in them (such as a message, if necessary, or a Game ID). This saves battery life, and the server is not burdened by many devices checking for updates every few seconds. Instead, the server notifies each device when an update is available. This system could be more difficult to make, but it is worth it in the end. Use push notifications.
iOS/Android each have their own native notification systems (iOS Push Notifications or Google Cloud Messaging). You should use those. Or you can use an abstraction like UrbanAirship.
I'm designing an application for getting some data from a web service, like a REST API and showing it to the user:
I was thinking about using the Sync Adapter with Content Provider API:
the Sync Adapter handles the data flow between the local DB and remote DB.
the content provider API loads the data into the UI.
My question is that the remote application, if, has a server push support (using Socket.IO or so), how should I design the app to exploit this feature? because as far as I understand, when the SyncAdapter will run is determined by SyncManager. So I can't ensure that the sync is done only when the server pushes. I wanted to know if this is possible, even without running the application in the foreground or background. i.e., only with the sync adapter running.
thanks in advance for any replies.
PS: I'm just starting to design android apps, so forgive me/correct me if I'm wrong.
Follow up:
I'm not interested in the Cloud messaging APIs (like GCM). I wanted to keep the data private if the user wishes to.
If your application will be running for a while you don't really want to keep a constant connection open to a server since that will eat a lot of batteries.
It sounds like you're looking for this:
http://developer.android.com/google/gcm/index.html
Using gcm your app can get a notification when there's an update on your server.