Output Json Size

[Luke 37272]

...continued from UI forum.

 

Scott,

 

I have thought about the idea of a stub object that only returns minimum data. The only problem, for the pc ui theme developers will inevitably want access to fields that aren't there.

 

The json serializer does strip out null values so that helps.

 

The reason I originally ignored People was to move them to the wrapper object in the same manner as Children, but in my testing last night, it didn't have as much of an effect on size as you might think.

 

Another option is to get rid of the Children from the output, and make that a separate call with paging, so that we can preserve all the fields.

[Luke 37272]

For instance, my html app does create a stub object for the children, with just enough information to put them in a list.

 

But the pc ui is a lot richer. Developers are going to want stuff like Media Info and all the different image paths.

 

Although for images, they really don't need the full image paths, they just need to know what images an item has. So there could be an opportunity there to remove all the file paths, although I do worry about making the output too quirky, if you catch my drift.

[ScottIsAFool 517]

Right, so the second option I mentioned is you have it bringing back everything like it does at the moment, or you have a parameter called fields that a developer can put in the fields they need.

 

Another solution could be a parameter that instructs the API to give a reduced number of fields that we decide.

 

As for the People, I'm still more inclined to think that this should be a separate call to the API that just takes the ID of the movie/tv/episode. I think a /person API might not be a bad thing anyway, will be simple then to get the films/tv shows that a person has been in without having to pull down the entire film/tv list and search through.

 

Just some thoughts.

[Luke 37272]

I don't mind moving People to a separate call, but I think we'll still have the People property server-side. That means UI developers might get confused having that always be null and getting People through a different means.

 

Being able to pick the fields you want I think is tricky too. That means no strongly typed access in the UI unless you define your own object to deserialize too.

 

So you prefer all that over paging? Paging doesn't mean the UI would have to visually page. You could just retrieve more items as the user scrolls.

 

Also for my html app I put a short-term cache in the response headers for item calls. Like 5 minutes, which basically covers the situation of clicking back and forth through items. I haven't done that yet here but am considering it.

[ScottIsAFool 517]

Paging depends on whether you have an indication of how many pages there will be so you know how many calls to make. I need all the top level items for the grouping, I can't just pull them in as an when unfortunately (like in the second video I posted in the Windows Phone thread. This would also be the same for the groupings in the Windows 8 metro app.

[Luke 37272]

Yea we could add a ChildCount to the item or wrapper.

 

I'm just thinking, your proposal requires 2-3 changes that each provide some level of reduction but come with some degree of quirkiness.

 

Paging the Children has just that one quirk and would basically solve the issue.

 

Anyhow, I don't plan to take this on yet, there's much more to be done elsewhere. But I think eventually this will have to be re-visited.