I would like to develop an application. It could be a game or whatever. I would have the same application in two or more devices. When one of them finish his tasks the other "client" must receive an notify that he has task to do and his datas should be updated automatically with the last changes. I guess that I would need a server in the middle where I'd save the model with the datas and send to them where the smartphones are communicating through it. It could be like a cardgame or kind of.
So,,,,
1. Two or more clients with the same application.
2. When one of them finish his task or turn, the other client should get a notify with his dates updates.
I have been looking at GCM, but I don't know if I could send complex datas through it or not,, and maybe there is a better way to make these kind of things.
Could someone give a clue where I can start??
Thank you!.
In your architecture, you must separate out the control and data aspects of the app.
You don't need the cloud to initiate a push of the entire data. If your app on any particular device gets a notification that an update is pending, then it can initiate the download at its convenience. Just use the GCM to push a notification that some task is pending for the app.
Related
I have an Android app that has a service that handle Firebase messages. So far it's working for me and I receive messages properly even when app is in background. What I need is somehow update app content when a message is received. That mean use network to contact backend and download fairly long JSON data and put them in database.
I have model in repository which I use in Activity. Now I am considering whenever I have to somehow call activity and refresh data but I think activity is somewhat dead when app is in background? So I don't know if it is even possible.
I can download data inside the service but my understanding of service is that it shall be lightweight and all the model and network calls seems to be a bit overkill for the service. Am I wrong?
What is ideal solution considering standard android architectural approach? Thank you.
So, I want to learn this synchronization strategy instead of just using the simpler MessageAPI, but am really struggling with how to successfully implement this.
My project is like this: I make queries to download a small amount of text from an API, via my phone. I will make these queries every so often, haven't really decided on how often just yet. The data will update the watch, which should hold onto the last data received. After that first download occurs, I send data using a DataMap, to the Android Watch. I only send that once, because I believe that sets up a channel to continually send updates when ready. If that is wrong, please correct me.
My main question is this: what if the Android phone's app closes? Then the data object goes to null, and gets sent to the Watch as null? Or, should I send an object from a long-running service or shared preferences on the Android phone, so that the object is never null?
Think of the Data Layer as more of an event system, i.e., you update your data and you're notified on the other side when the data is updated (created, changed, or deleted). You don't have to worry about if the Activity is killed after that. Even if the data was 'deleted', you would be notified it was deleted.
On the Wear device, you would listen for the changes via a Service or Activity and update UI, DB, etc. accordingly.
It probably make sense to read through this Android training guide. (It isn't too long.) The Handling Data Layer Events section is probably the most useful.
This may be duplicate question but am still having doubt am a beginner in android application i have a couple of doubts my primary doubt is:
I have made one application which will communicate with server when network available it will work as it is. when network is not available data will save in sqlite and later when network is avail need to sync that data to server how can i achieve this.
Whenever there is new update is made with server need to get notification how can i do this
For this one which will be the best approach syncadapter or server or intent service with broadcast receiver which would be opptimized solution for the above requirement
These are all my doubts i would be very glad if someone helps me !!!
If you want an Android app to be notified when something happens on a server you control (without having the app to constantly poll the server to ask for changes), the usual solution is to use Google Cloud Messaging to allow the server to send a notification to the app to tell it to refresh data.
It is kind of complicated to implement, but is the best way to do what you want and is standard practice for mobile apps.
If you need to know when the network becomes available, to reach your server for synchronization, implement connectivity change listener, as discussed in this question.
This does not allow to send messages from the server easily, but if the server messages are not of high urgency, maybe you can simply check for them periodically.
This would allow to use less Google specific infrastructure and change the cloud providers easier.
I'm currently developing an mobile application and rest service. The mobile application executes lots of calls to the service even if no update is required and data didn't changed. In order to remove this overhead of rest calls I'm planning to implement GCM (Google Cloud Messaging).
My strategy would be the following:
Load all required data on application startup. When data change was recognized on server side a push notification will be sent via GCM to affected devices to make partial refreshes of data (via specific rest calls). Advantages of this would be less overhead at service side, because there are no unnecessary rest calls and a more fluid user experience in my opinion. Disadvantage is that the app is dependent on GCM Messages and that they arrive in time.
I'm unsure if this is the right strategy for this. Could someone maybe point me in the right direction and tell me if this is a good practice?
We could use more information before answering details...
I'm unsure if this is the right strategy for this. Could someone maybe point me in the right direction and tell me if this is a good practise?
I will consider for the sake of giving an overall answer that:
A - User is not always with the application "online", neither has network, not even a desire to have updated info at all times.
B - User is eletronicaly litterate enough to understand difficulties with the program.
With those in mind, then what would be a good approach is:
Poll relevant data, store them locally. At this stage, one would consider the relevant informations that user would have and store them, with a date flag.
Once a flag goes "old" (below your threshold), re-query that data.
Operations follow 2 directives... When observing a data, check its state, show the user if its recent or not, and if its not, poll it. If it is, if the user selects operations on it (POST mostly), re query the data.
This way, you have no static overhead, if users dont have the app on foreground. Also, should they use your "always online app", they understand that network is a necessity.
I am implementing a chat app in android. A vital part of this app is to sync with the server and local database. There are several methods to sync data between server and android device like AsyncTask, IntentService and SyncAdapter.
I prefer to use SyncAdapter, because it is more efficient and it handles most of the background tasks by itself.
When I read the developer page for SyncAdapter I found this,
Note: Sync adapters run asynchronously, so you should use them with the expectation that they transfer data regularly and efficiently, but not instantaneously. If you need to do real-time data transfer, you should do it in an AsyncTask or an IntentService.
Does that means is it not good to use like chat app?
Also I need to mention a feature of SyncAdapter
Automated execution
Allows you to automate data transfer based on a variety of criteria, including data changes, elapsed time, or time of day. In addition, the system adds transfers that are unable to run to a queue, and runs them when possible.
So if it starts to sync when data changes (Since the new messages are stored in the sqlite database), I think SyncAdapter will be a good choice for Chat App.
Any Suggestions are appreciated.
Thanks.
Usually mobile app depends on backend implementation and app requirements, but generally you shouldn't use such methods for chat application, they won't give you up to date data.
I'd say when app is in background, you should use GCM for new messages notifications and when app is in foreground use something like RPC, xmpp, sockets or whatever that keeps your connection alive.