[TIMOB-23390] TIAPI: Cannot paginate Ti.Contacts.getAllPeople()
GitHub Issue | n/a |
---|---|
Type | Improvement |
Priority | Critical |
Status | Closed |
Resolution | Won't Do |
Resolution Date | 2016-07-21T03:22:49.000+0000 |
Affected Version/s | n/a |
Fix Version/s | n/a |
Components | TiAPI |
Labels | n/a |
Reporter | Kiley Williams |
Assignee | Ashraf Abu |
Created | 2016-05-14T18:55:06.000+0000 |
Updated | 2016-07-26T06:55:58.000+0000 |
AC-3628 is a potential temporary workaround for TIMOB-20279
Hello, Thanks for creating the ticket. Our engineering team will look into it. This need to be cleared by our selection committee. Please understand that the processes is time-consuming and lots of variables in play. We will let you know if and when we will be including this feature in our platform. Regards
Any update on this? The Ti.Contacts.getAllPeople() functionality is 100% blocked if a device has more than 512 contacts. Pagination would be a viable workaround, but this ticket indicates that it is not currently possible, even though the documentation states that it is. Please advice what needs to be done on our end to avoid continued blockage. Thanks.
Any movement here? We either need this to be resolved, or TIMOB-20279 to be resolved so that we can be unblocked when retrieving more than 512 contacts...
PR: https://github.com/appcelerator/titanium_mobile/pull/8112
Closing this issue as won't do as this was initially thought as a remedy for the getAllPeople method. There's a proper fix for this now in TIMOB-15765.
Thanks @ashraf. Should this be removed from the documentation as well, for uniformity?
This was not merged. Which docs are you referring to?
It's marked as "Won't Do", but the documentation still says that it is possible to set a limit on the number of people retrieved by the
getAllPeople()
method. You can see it here: http://docs.appcelerator.com/platform/latest/#!/api/Titanium.Contacts-method-getAllPeople Currently, that is not possible (I believe), or I must be mistaken, but I opened this ticket originally because it was not possible as a workaround for the other (now fixed) issue. So I just figured it would eliminate confusion down the line to remove the "limit" parameter if it was not going to actually be properly implementer. @ashraf, I thought you had implemented a fix for it already in one of your PRs anyway... but maybe not. Either way, if it's going to be a "Won't Do" resolution, then that means the documentation is describing functionality that does not exist, which might confuse some people down the line.