Though as a beginner, I am trying to develop an android app which is story based, i will like to know the best way to serve content to the user, i mean like a continuous update of content, just like updating news by the hour. As users will install just once, how will they get the latest content of my news or story based app.
I have access to domain names and hosting if it requires uploading such content through a domain.
from your experience, what is the best method to achieve this? I humbly await a response, thanks
So given the clarification in the comments this is the answer:
The best way is PUSHING the content to the user's device.
Generally speaking, the two ways for a new content to reach an app are :
1.polling your server (or any third-party server) for new data every,say, 20 minutes. The disadvantage of this method is that it drains the battery. Every time that the phone connects to the internet, the radio in that phone stays on (or in a standby mode) for something like 2 minutes. Those modes (on and standby) drain the battery. Another problem is that it does use data needlessly and in some countries cellular data is expensive (Canada for example).
This could be a solution if the data changes very very frequently (for example a stock's price can change many many times a day). But generally speaking method 2 is the preferred method..
2.Pushing the content to the user's phone.
Your server will send a message to the device once new data that you want to send is there (and you could also put that data in the payload of the message if it's not too much).
This means that the phone will connect only when some new data is available.
Saves battery life,and gets the information as soon as it is available!
I recommend using GCM (Google Cloud Messaging) for this purpose which is free, and simple to use. If you have no idea how to do that in Android (which is likely since you said that you are a beginner), it is explained really well in Udacity's
Advanced Android App Development. It is a free course by Udacity and Google, but the section about GCM is only about 15 minutes long.
If you know how to implement a server but don't know how to use GCM in your server (and you don't find Google's documentation helpful) do let me know..
If you don't know how to implement a server...well then it's something you will have to learn in order to get your content to your users as that's the best way.
I hope this helps! :)
Related
We are working on app which is for fixing their appointment with a doctor. We will have to notify the user on that date by saying if the doctor is available or not.
How can we notify the user when the data changes in the server?
The usual workflow for sending push messages from your server to the application, is the Google Cloud Messaging, or the so-called Push Notification in Android.
Simply put, you send your message to the Google and the Google will notify your application. The actual heavily lifting is done by the Google Play Services Library and its corresponding application, which is installed on every android device. For more information on how to implement it, you may refer to the following links.
Official Documentation on Cloud Messaging
Android Push Notification Tutorial
I used http://pusher.com/ "Pusher" for a doc app a couple years ago. It was easy to do and light weight.
Simplest way I would believe is through a polling technique. However, it would not work for real time updates as there is an update interval. Depending on your application's requirements, this might work!
In order to do that.
You would have to publish a web service which would provide a Unix
timestamp. e.g. https://Your-base-url/status.aspx
Each time there is any change on the server, you change the value to a new one on the server.
Your Android device will poll that web service(status) each say 60 seconds
to see if there is an update.
The device would save the timestamp in his device and would check
whether the two timestamps match.
If not, then he will call the relevant web services to get updated
data.
However, you should note that the Android device will only get to know whenever it polls. So, the device might not know the update until his next polling cycle.
The most accurate way is to maintain a persistent Socket connection with your server at all times. Whenever an update occurs, you can immediately send the updates to the device via the open socket. However, this is more complicated as you will have to deal with the socket connections.
GCM uses socket connections internally. Therefore, a solution including GCM is an easier approach.
I'm creating mobile application for iOS and Android. The problem is when any data has changed on server, I cannot notify mobile devices.
I have found 3 solutions, each have minus and pluses.
Use push notifications. Since iOS always shows a notification to user this is not a solution at all. Also I cannot know if the notification will go to device or when it will.
For every X seconds ask server if any change exists. I don't want to do that, because creating too many HTTP connections and closing them is not a good idea I think. Also if the data is changed right after the device asks, the info change on device will occur late.
Use web socket. My application's one time usage expectation is ~2 minutes. So web socket looks like a good choice, because app will be terminated or go to background state quickly and battery consume won't be much. Also all the server side data changes will come to the device just in time. But I don't know much about web socket. Is my opinion acceptable? Also how many concurrent connections can be done by my server. Is it a question too.
Here are my all solutions.
The document would suggest assumption 1. above is incorrect.
If you read the The Notification Payload section, you'll come across this;
The aps dictionary can also contain the content-available property. The content-available property with a value of 1 lets the remote notification act as a “silent” notification. When a silent notification arrives, iOS wakes up your app in the background so that you can get new data from your server or do background information processing. Users aren’t told about the new or changed information that results from a silent notification, but they can find out about it the next time they open your app.
https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html
I think for the most part this depends on what your app is doing.
I would say you should use a combination of #1 and #2.
2 - At the very base level if you need information from the server you are going to have to make a request. If this information needs to be up to date then you can proceed to make a request for the information when the ViewController is loaded. If you need this information to update as the ViewController is loaded then you will need to make subsequent requests every X seconds... In addition to this if your user is interacting with this data and sending an update to the server you can check at this point if the data is up to date and alert the user as well as return the current data.
1 - Push Notifications operate off of the 'send and forget' protocol. The notification is sent and is not verified if it is received or not. This is used as a supplement to #2 and is 'nice' but should not be depended upon.
Push notification is the intended way (from both Google through Google Cloud Messaging, and Apple through Apple Push Notification Service).
Both option 2 and 3 are frowned upon as they affect battery life, and they are unnecessary as most cases scenarios can be covered by push notifications.
I need my app to receive notifications, but my boss does not want to rely on Google Cloud Messaging so I will use httpPost in a background service instead for periodically check for new messages.
My question is: will that be too demanding for the battery and data consumption? Do you know a better option?
Thank you.
Edit:
This is an app for a delivery store. The messaging starts when you ask for something and ends when you receive the item. The message query will be every minute for about 10 or 20 minutes.
In general, this would not seem like a good idea. The scenario you describe seems like a perfect fit for GCM. I would first try to convince your boss to reconsider. :)
"Polling" a server, even for a brief connection which transmits hardly any content, means the device must be woken (from a low power state) and the radio turned on, and it will stay on for a significant time. The impact on data consumption will probably be insignificant, but battery usage will be a concern.
In case it cannot be avoided, you should check Minimizing the Effect of Regular Updates section of the Efficient Downloads referenced by #CommonsWare in the comments.
Also, Reto Meier gave an excellent talk on this subject at the 2012 Google I/O. His series on Efficient Data Transfers is also very informative. Hope it's helpful.
I just finished an app that synchronizes its data with a server (runs SyncAdapter on background). I installed it on my phone, let it run on background (I barely used my phone) and I found out that the 23% of my applications' battery usage belongs to my app, so I really need to decrease its battery usage.
Right now I have the sync time set to 30 seconds. It's a multi-user app and if other users interact with you you get a notification, I can't set a sync time too high (actually I wanted to decrease it until I saw the battery usage).
In each synchronization it ALWAYS asks the server for any changes and checks for changes in the local database. If there are changes in the local database they are sent to server, and if we retrieve changes from the server they are applied to the local database.
Does anybody know about some tips to reduce battery usage?
Probably the best that you can do is to implement GCM (Google Cloud Messaging) using pushing instead of polling.
In this way you will be able to get a "tickle" when something new happened and you will know when ask to the server for datas.
A network poll each 30 seconds is very aggressive. I recommend you read this article from Google : http://developer.android.com/training/efficient-downloads/index.html
However, if you really need to request the network that often, I don't see any magical trick for you...
I'm in the process of developing an android game within a group of people. Our knowledge is very limited. As a part of the game it will be essential for us to have the continuous possibility for updates. To give some context; this will be a pirate based game where by people can go around and dig for treasure on a map. Friends have to be updated when treasure is retrieved and when new treasure is buried.
Rather than setting a time period to send out a request for any changes on the server, we thought it might be good if the server could just push out changes if they occur.
Does this a) Sound like a good idea for what we'll be updating? and if yes, b) What would be the simplest way of implementing this? / If it is not simple should we stick with the first idea of just sending requests every so often?
What I know about implementing a server push is faking the server push. There are two ways of doing this. One is continuous polling to the server asking for any updates. But when the polling rate is high it will take much network traffic and also will make your application slow. Other way of doing it is to block the client call from the server. When ever a client makes a call to the server, if there is nothing to return server just block that request ( inside a while loop). When ever server has something to return, loop will break and reply the update. But if your network connection is bad you cant do this easily.