Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
![](/static/devrant/img/pipeless-devrant-banner-white.png)
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
Server side, if you want pagination, filtering and all the cool stuff for data ;)
-
RTRMS37928yServer side, you cannot rely on the end users performance.
Whatever you can do on the server, do, as you control that hardware, you control that logic, if things start getting slow you can boost the api, you cannot make a guys 6 year old phone faster. -
chrisx841698yWhat @RTRMS said plus servers tend to have better computing power than mobile devices. Also less work on the Android cpu means less battery cunsumtion.
-
Are you all insane? If it's only 50 rows you can do whatever you want on the client side with less code, less complicated queries to the database, no need to implement filter/sort/count on the database. The UI will be much quicker (no need for a round trip for every simple sort/filter) and your server will use less resources (less calls means more supported clients on the same server). This is all true if the data is 50 rows, if it can grow to thousands I guess it's not feasible.
Also a network roundtrip takes more power than a small UI sort of 50 items -
@solocoder The data will be growing soon. Also note that it's 50 HTTP Request I am making to get the data. Will your comment be the same?
-
@PoweredByCoffee do you have a limit on how large the data can grow (is it logical to impose one)?
Why fetch them one by one, this is pretty bad. It's simpler to implement a "get list" server endpoint then to fully implement paging surely if the page size is 1. The question is how big is the data in the rows? If it's just a few numbers/small text it can be fine, images you can always lazy load. -
@solocoder no I didn;t make the API, the client did and we are just implementing. We have already informed them that it''s bad and fucken slow but they just don't care yet.
-
@PoweredByCoffee hmm... so if the server is not something you can change anyway you can't implement sort/filter/paging in the server so the question is should you implement it (on the client side) or not (at all) and tell your client to fuck off. The answer to that probably depends on how important is this client to you.
-
Assuming '50 rows' means a database, then I'd make the database order my result set before the server even touched it
-
Also, if it's not your data, how can you expect the data owners to know how you want it sorted? Is it internal or a public service? What if another consumer wants it ordered by a different column?
If you're super worried about performance, set up your own server to make the calls to their API (and do what you need with it, sorting, caching, etc), then expose better APIs to your app? -
@linux-colonel No they exclusively provide the APi for me only to make their android and ios app.
-
@PoweredByCoffee
Oh, well in that case have them all shot for designing terrible APIs!
Related Rants
!rant
Question: If you are making an API for your Android App. Let say you have total of 50 rows currently and you have to sort a table column by price in ASC order.
Will you do the sorting in the Android App or Server side?
undefined
android
fml
sort