Develop Reference

Android Pagination on server or client side

I'm developing an android app, which will fetch data from my webservice and display it to user. I have a confusion in deciding where to keep pagination(in client side or server side)
My scenario is, I ll take input from the user and make a call to my webservice, to fetch all the data available for the input(response is in Json format) and then, display the data fetched in Recyclerview. I want to display only 50 records initially, then when "show more" button is clicked, the next 50 is displayed.
My data(reponse from webservice) range varies from 0 to 15000 , based on the input from user. And I have other filtering parameters in UI, which will change the rendered data when selected.
So, is it good to fetch all the 15000 records at once and do all kind of processing in client side?
or to fetch 50 records each time when "show more" button is clicked? and to fire new API call whenever filter is changed?
Thanks.

You should never try to fetch such a large number of records in one go, because : 1) your app would have a very slow FRT (First Response Time) 2) the user is unlikely to view more than a couple hundred records at any given time. 3) If the user data (2G/3G/4G) is paid, the user ends up paying for data that he would never see.
So, you should always have pagination on the server side and then your client can request subsequent records as and when needed.
Having said that, network requests would take time and waiting for response every time user clicks on "Show More" would be bad UX as well. So, you need to consider batching requests together and even pre-fetching some data. Here is a nice video for you to see before changing your architecture : https://www.youtube.com/watch?v=3kOx-IPqtqA

Store on database vs Retrive data from network

I working on my app that uses "The movie database API".
This app just parse a json from the API and gets each movie information.
My question is what the better way to that.
First alternative is to build syncAdapter, check for updates each day for example, store all movies information on local database and update the UI from database.
Second alternative is just retrive the information from network on each request and update the UI.
Can anyone explain me wich way is better and why?

Absolutely the first alternative !!!!!
let's Suppose your app is used by thousand of users and you have chosen the second one .....oh poor server :)
I usualy create my own local database and syncronize it each "x" interval time depending on the type of information : if I have, for example, a list o category that I know they are rearly changed than I syncronize them each "2 days" ....For data that can be different more often I use 20 minutes and so on. This just avoid stressing server if the user goes in/out from your app.
Bye

Best way to check if picture already seen

My Android app grabs random pictures from a Django server. And in my app, you can vote on the picture.
I want to be able to make sure the user never gets the same picture twice. I already am saving an array of integers that has the picture id locally on the app itself.
My question is, what would be the best/good practice to have the server send only new pictures that haven't been voted on?
I was thinking of sending the server the array of integers so that the server can cross check and send back one that wasn't already voted on, but thinking this could be a problem on a larger scale -> making the server do too many computations.
Thanks in advance!

I don't know much about Django, but either you need to do as you suggested, or you can ask for a random picture, the server responds with the ID it intends to send and your app replies with either yes or no depending on whether it wants that one. The server then either offers another random ID or you accept the picture and it sends it.
Also, use a set instead of an array - you have no interest in order, you just want to avoid duplicates.

How to consistently and efficiently refresh a listview feed of content?

I currently have several fragment tabs , each with a feed of user statuses, being I have about a 100 other users posting from their accounts there is constantly new data every few minutes. currently the users only choice is to switch fragments back and fourth to get the entire fragment to reload which sends another http request and returns the new data as well as all the old data the user already had. it just doesnt seem efficient, know there has to be a better way. Can someone give me a overview of the most efficient way to keep this data fresh without having the user switch tabs back and fourth?
Is this where using sqlite and/or services comes into play?

Though some developers and designers argue between if content should be refreshed automatically of not, I argue content like streams shouldn't be refreshed automatically unless you are expecting very less incoming data.
I have used twitter4j to stream tweets and refresh automatically in one of my test app, twitter4j has a listener that lets you know when new tweets are received. First I pushed data into ListView as soon as new feeds were received and it was kind of flashy but, efficient. Then I queued up data until it reached certain threshold and pushed data into ListView, it was bit better. I thought it was good enough but, when I monitored my "Data Usage", i quite realized why I shouldn't refresh automatically.
Now here are some example implementation:
(Suggest) Do some type of polling or I recommend you to implement
push(like GCM) to let your client-side know that there's new content
in the server.
(Option) Use SyncAdapter with server triggered sync
(Recommend) Let user be in control, it's more than okay to use
Pull-to-Refresh pattern like Facebook or ActionBar sync button like
Google+. It will not make UserExperience any bad.
Now here's how your sample request API should be like or you can match your own config:
{
"fromIndex": 0,
"toIndex": 10
...
}

well, i'll try to give you a general overview to see if you can get it without the need of getting into deepest details, an idea it just came to my mind:
1- you need to configure your server to retrieve from an "specific" point of the content or retrieve a token that you will pass to the server (on next HttpRequest) to know from where part of the content or from where "index" start to send the content again.
2- you need to have a Listener (i dont know how you are showing your data but this is the case of a ListView) that tells you when the user is closely to get to the end of the ListView and let't say if there are already 10 elements, in element 7 the Listener should call the method to get more content from the server.
3- Yes, you need to keep the data already retrieve in SQLite temporarily, you can't use SharedPreference to keep it because it probably would be a lot of data and maintain it in memory could be a bad idea, writing a file is not an option here neither, so SQLite is your best friend in this case.
Maybe there would be more problems specifics about what you are trying to achieve but to me in a general perspective, those 3 points should at least help you in the direction to go.

Cache for list of friends / items

I'm looking for a way to cache as much data as possible in my app. Most of this data, are items which are crucial for the following steps, like a list of friends. Depending on the selected friend I show a list with certain items and can send something to this friend.
I would like to cache the list of friends. In such way, that it's not possible to send something to a non-existant friend, which would obviously cause an error. Or maybe the cache could work such that it shows a "invalid cached friend" message and refreshes after it...?
The list of friends will not change very frequently but still can change while the user is using the app.
I also want to cache the items which can be sent to the users. These also will not change very frequently, but it's very important that the user doesn't send non-existent items, and it's of course desirable that they see the newest items, if they were updated on the server side.
It's the same principle like caching items which can be bought, for example. It's critical that the users doon't try to complete a transaction with an invalid item.
I have already done some research, but could only come up with a rough idea so far:
Compare data using hash or timestamp: In this case I don't know at which point to do it? Loading the screen probably doesn't make any sense, since the user would have to wait for the server's response anyways. Maybe a background process? But how often do I run it? How do I synchronize?
Also, I can add an update menu item such that the user can ensure that the data is updated. But it still doesn't solve the problem that the user can try to complete transactions with invalid data (if they don't press the button).
I also found some information about "real time data" and AVIs but I think that's not applicable for my case, my data will change seldomly, but it's required that it's valid, since it's not only informative data, it's transaction determining data.
What is the way to handle this?

I think you are right, you should check the timestamp with the data source (the server).
If that's a peer-to-peer exchange between friends, just before sending your data, request its timestamp from the server. Not so much data, usually close to real time. But there's still some minor probability of sending obsolete data - just "a nanosecond" after an update.
If it's through the server (and why not?), as a bonus, you will have optimistic locking by checking the timestamp on the server and canceling the transaction if the data being sent is obsolete.