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()
}
رد بواسطة Travis Bell
بتاريخ سبتمبر 10, 2013 في 10:01 صباحا
Hi BinaryFork,
No, it is not possible to increase the page size.
رد بواسطة xanderstrike
بتاريخ فبراير 26, 2014 في 7:40 مساءا
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).
رد بواسطة Travis Bell
بتاريخ فبراير 27, 2014 في 4:32 مساءا
That's ok, but no it is not. We're content to keep it as is.
Cheers.
رد بواسطة xanderstrike
بتاريخ فبراير 27, 2014 في 6:22 مساءا
Care to share why? This would be super helpful in a lot of applications, and shouldn't be that hard to implement.
رد بواسطة Travis Bell
بتاريخ فبراير 28, 2014 في 9:46 صباحا
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.
رد بواسطة roland684
بتاريخ يونيو 3, 2014 في 8:08 صباحا
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.
رد بواسطة Travis Bell
بتاريخ يونيو 3, 2014 في 9:55 صباحا
We have no plans to allow changing the page size.
رد بواسطة scerrutti
بتاريخ يوليو 22, 2015 في 5:02 صباحا
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!
رد بواسطة Travis Bell
بتاريخ يوليو 22, 2015 في 11:17 صباحا
Hi scerrutti,
We do not have any plans to support custom page sizes at this time.
رد بواسطة dieggo
بتاريخ يوليو 27, 2017 في 3:19 مساءا
Hi I think that should be a dynamic parameter the number of results you want and with that would solve the problem
رد بواسطة Travis Bell
بتاريخ يوليو 27, 2017 في 5:50 مساءا
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.
رد بواسطة gdeleon101
بتاريخ مايو 3, 2018 في 4:06 مساءا
Travis,
Where can I find out how to query more results as the user scrolls the page (iOS ) to create the "infinite scrolling"?
رد بواسطة Travis Bell
بتاريخ مايو 3, 2018 في 4:23 مساءا
Hi @gdeleon101,
You can use the
page
parameter to scroll through pages.Etc...
رد بواسطة gdeleon101
بتاريخ نوفمبر 22, 2019 في 10:57 صباحا
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: