Subcategories in /categories.json

(David Liaw) #1

I’m not sure if this is the right category, so feel free to close/move as needed.

As per the title, it would be rather helpful for subcategory details to come in /categories.json rather than going to each categories’ /show.json to fetch simple details like the category name and its text/background colour.
I’m thinking of a similar method to how relevant users can be found in a JSON Array like in /latest.json.

The reason for doing so (as sort of mentioned above) is to cut down the need to call and parse /show.json to fetch the category name and the colours. I’ve included a short video which demonstrates the difference between just using /categories.json and /show.json (the last post is posted in a subcategory (Video Downloads) and hence it’s the example being used).

In the video the subcategory details loaded slightly faster than normal (which is strange, recorder probably skipped a few frames?) but normally it takes quite a number of seconds (enough for it to be annoyingly noticeable).

Now, this is just one post so it’s not a big thing, but in the future there will be a lot more posts and scrolling through them with quite a number ‘loading’ categories would seem rather annoying.

Of course this is probably a bit nit-picky and is probably on the roadmap already (since it sort of already looks like it’ll be added in the future), but it’ll be really helpful to both myself and anyone else facing a similar sort of thing when dealing with subcategories.

(Jeff Atwood) #2

You are running into the Android performance problems, which are severe. Search for Android and you will find exhaustive detail, data, and videos.

(David Liaw) #3

Performance is not an issue, if anything it could be network performance. But I’ve tested this on quite a number of devices (both physical and emulator) with different network connection conditions, and those with a faster connection obviously were slightly faster but you could still see the issue shown in the video.
I’m not really sure what else to tell you, but I’m fairly certain performance is not a factor here.

(Jeff Atwood) #4

OK, fair enough, just letting you know that Android perf is literally 3x - 4x worse than iOS and desktop perf.

I am not exaggerating, and this is still true today even on the Nexus 5. You can watch the video if you like:

(David Liaw) #5

It seems we must have misunderstood each other, since I’m guessing that you assumed that I was talking about the web app of discourse, but I was actually referring to the API since I’m implementing a more native solution for our forum.
Sorry for the misunderstanding, I probably should have made it a bit more clearer in the OP.

And yes, in my experience UIWebView (iOS) is a bit faster than WebView (Android) but hopefully Google’s decision to use chromium (or blink, when the time comes) in Android will pay off.

(Sam Saffron) #6

Care to try a PR that show exactly what you mean here.

Have you tried to time these endpoints with mini profiler to see what is going on, I have not seen any endpoints that are regularly longer than 300ms, categories being the slowest probably.

(David Liaw) #7

As mentioned above I should have made myself more clearer. But, it isn’t the response time which is the problem, that’s fine as it is. I’m not quite sure how to explain it, but I’ll try my best:

The app calls to both /latest.json and /categories.json and passes both results to a ListView adapter (handles the overall listview functionality) to display the results. When it comes time to display the category name and colours, it finds the relevant data from the categories JSON and displays it. But the problem is that if it can’t find it there it then calls to /show.json to fetch the relevant data and then display it, which causes the supposed delay (due to the extra step needed).

Hopefully that makes some sense…
So the problem isn’t related to the timings in response or performance, but the way in which the data is presented. All I’m asking is if it’s possible to remove the extra step of calling to /show.json, by putting sub categories in /categories.json.

Again, sorry for the misunderstanding, I wrote the OP at something like 3 in the morning which was probably a poor decision.

(Sam Saffron) #8

Can you trace what it is your app is doing? Are you running a loop through JSON calls?

I don’t mind amending the API if you are clear on the change you need (ideally a PR)

(David Liaw) #10

Not the solution I suggested, but it accomplishes the same goal.