Sorry to resurrect an old topic. Is this a feature on the roadmap?
I'm trying to to inner join the results of a similar_movies query with movies already present in my DB and it would be extremely helpful to be able to pull down 100 movies all at once instead of 20 five times. It'd be easier on you guys too.
This ought to be a trivial change on your end as well, just setting the limit to a parameter page_size (like page) and having a sane maximum (like 100).
It's not a matter of how easy it is, it's to do with how practical of a feature it is vs. the performance side affects. The way we see it is you have two common use cases (looking at the majority of how users use our data):
Search results. Search is almost universally showing the results you're looking for within the first 20 items. If it's not, the problem isn't the page size, it's your search query. Over 98% of users never hit page 2 on our own website and we only show 10 results! 20 is more than enough.
Misc. list pages like top rated, popular, now playing. The first common use case would be if you're bringing the data in house. Limiting the pages to 20 items has little bearing on anything but a few extra requests. We cap these requests to 1000 pages so 20,000 items. Having some kind of a background job process these is trivial. The second common example would be a mobile app of a sort. There are many apps that support the "infinite" scrolling concept and this is quite simply, the smarter way to build your app anyways. It keeps the requests fast and short and we are only ever loading what the user sees, so very little wastes resources. There are many examples of apps already doing this for both iOS, Android and web.
How about an option to DECREASE the page size? As you mention you yourself only show 10 results per page. And in a situation where there are 15 items per page, you'd need to do 2 request to get all the results for page 2.
Re-paginating paginates results, for only 2% of the users, is cumbersome.
I currently only want the first or first 5 results and have written a piece of code to discard the other results. Transferring and parsing that extra 1.5 kB is no big deal, but it doesn't feel efficient.
Hi.
This would be a great improvement. I don't want to get 20 related movies, 4 is enough to me. Faster and lighter request, less code for us to limit the request manually. Is it out of roadmap yet?
Thank you!
Hi @dieggo Yes, that would solve it but it's still not something I am worrying about right now.
I recently discussed this in another post and pointed out that a fairly standard page of 20 items sent over the wire with gzip is only 5.7KB. I appreciate the desire to get small optimizations like this but 5.7KB is pretty small.
I get the string you are adding to the call, but I'm not sure how to call that in swift. Do I need to call another function? What I'm currently doing is loading a collectionView using this function:
func fetchMovies() {
let apiKey = "MYKEYGOESHERE"
let url = NSURL(string: "https://api.themoviedb.org/3/movie/now_playing?api_key=\(apiKey)")
let request = URLRequest(
url: url! as URL,
cachePolicy: NSURLRequest.CachePolicy.reloadIgnoringLocalCacheData,
timeoutInterval: 10)
let session = URLSession(
configuration: URLSessionConfiguration.default,
delegate: nil,
delegateQueue: OperationQueue.main
)
let task: URLSessionDataTask = session.dataTask(with: request, completionHandler: { (dataorNil, response, error) in
if let data = dataorNil {
if let responseDictionary = try! JSONSerialization.jsonObject(with: data, options:[]) as? NSDictionary {
print("response: \(responseDictionary)")
self.movies = responseDictionary["results"] as? [NSDictionary]
self.collectionView.reloadData()
}
}
})
task.resume()
}
Can't find a movie or TV show? Login to create it.
Reply by Travis Bell
on September 10, 2013 at 10:01 AM
Hi BinaryFork,
No, it is not possible to increase the page size.
Reply by xanderstrike
on February 26, 2014 at 7:40 PM
Sorry to resurrect an old topic. Is this a feature on the roadmap?
I'm trying to to inner join the results of a similar_movies query with movies already present in my DB and it would be extremely helpful to be able to pull down 100 movies all at once instead of 20 five times. It'd be easier on you guys too.
This ought to be a trivial change on your end as well, just setting the limit to a parameter page_size (like page) and having a sane maximum (like 100).
Reply by Travis Bell
on February 27, 2014 at 4:32 PM
That's ok, but no it is not. We're content to keep it as is.
Cheers.
Reply by xanderstrike
on February 27, 2014 at 6:22 PM
Care to share why? This would be super helpful in a lot of applications, and shouldn't be that hard to implement.
Reply by Travis Bell
on February 28, 2014 at 9:46 AM
It's not a matter of how easy it is, it's to do with how practical of a feature it is vs. the performance side affects. The way we see it is you have two common use cases (looking at the majority of how users use our data):
Search results. Search is almost universally showing the results you're looking for within the first 20 items. If it's not, the problem isn't the page size, it's your search query. Over 98% of users never hit page 2 on our own website and we only show 10 results! 20 is more than enough.
Misc. list pages like top rated, popular, now playing. The first common use case would be if you're bringing the data in house. Limiting the pages to 20 items has little bearing on anything but a few extra requests. We cap these requests to 1000 pages so 20,000 items. Having some kind of a background job process these is trivial. The second common example would be a mobile app of a sort. There are many apps that support the "infinite" scrolling concept and this is quite simply, the smarter way to build your app anyways. It keeps the requests fast and short and we are only ever loading what the user sees, so very little wastes resources. There are many examples of apps already doing this for both iOS, Android and web.
Cheers.
Reply by roland684
on June 3, 2014 at 8:08 AM
How about an option to DECREASE the page size? As you mention you yourself only show 10 results per page. And in a situation where there are 15 items per page, you'd need to do 2 request to get all the results for page 2. Re-paginating paginates results, for only 2% of the users, is cumbersome.
I currently only want the first or first 5 results and have written a piece of code to discard the other results. Transferring and parsing that extra 1.5 kB is no big deal, but it doesn't feel efficient.
Reply by Travis Bell
on June 3, 2014 at 9:55 AM
We have no plans to allow changing the page size.
Reply by scerrutti
on July 22, 2015 at 5:02 AM
Hi. This would be a great improvement. I don't want to get 20 related movies, 4 is enough to me. Faster and lighter request, less code for us to limit the request manually. Is it out of roadmap yet? Thank you!
Reply by Travis Bell
on July 22, 2015 at 11:17 AM
Hi scerrutti,
We do not have any plans to support custom page sizes at this time.
Reply by dieggo
on July 27, 2017 at 3:19 PM
Hi I think that should be a dynamic parameter the number of results you want and with that would solve the problem
Reply by Travis Bell
on July 27, 2017 at 5:50 PM
Hi @dieggo Yes, that would solve it but it's still not something I am worrying about right now.
I recently discussed this in another post and pointed out that a fairly standard page of 20 items sent over the wire with gzip is only 5.7KB. I appreciate the desire to get small optimizations like this but 5.7KB is pretty small.
Reply by gdeleon101
on May 3, 2018 at 4:06 PM
Travis,
Where can I find out how to query more results as the user scrolls the page (iOS ) to create the "infinite scrolling"?
Reply by Travis Bell
on May 3, 2018 at 4:23 PM
Hi @gdeleon101,
You can use the
page
parameter to scroll through pages.Etc...
Reply by gdeleon101
on November 22, 2019 at 10:57 AM
Travis,
I get the string you are adding to the call, but I'm not sure how to call that in swift. Do I need to call another function? What I'm currently doing is loading a collectionView using this function: