LSExtendedTableInfo Index Error [iOS]

cipd

Hi Everyone,

Has anyone else encountered the following error when using the iOS client library?

"didReceiveDataError->Data error: No item with index 1 can be found in an LSExtendedTableInfo with just 1 items"

This error appears to occur only when utilising the iOS client. When replicating the same functionality with the dot net library, all appears to work as expected.

Is there an easy way to debug the library to determine what is triggering this error?

Many thanks

gianluca.bertani

Hello,

this error may happen when the adapter sends updates for more items than what the client is expecting from the declared LSExtendedTableInfo. In this particular case, your LSExtendedTableInfo contained just 1 item (i.e. it was initialized with an array of 1 element as first argument) but the client received an update for item n. 2 (which is reported as index 1, as internally they are 0-based).

LSExtendedTableInfo adds the capability to refer to fields by name, and have the item name filled at each table update, but requires a metadata adapter derived by or equivalent to a LiteralBasedProvider (as stated in the docs). You may use an LSTableInfo to avoid the error above, but in that case you cannot refer to fields by name, and the item name argument of table updates will always be nil (i.e. you have to refer to fields and items by position only).

Hope this helps.
Best regards,

Gianluca

cipd

gianluca.bertani Hello,

this error may happen when the adapter sends updates for more items than what the client is expecting from the declared LSExtendedTableInfo. In this particular case, your LSExtendedTableInfo contained just 1 item (i.e. it was initialized with an array of 1 element as first argument) but the client received an update for item n. 2 (which is reported as index 1, as internally they are 0-based).

LSExtendedTableInfo adds the capability to refer to fields by name, and have the item name filled at each table update, but requires a metadata adapter derived by or equivalent to a LiteralBasedProvider (as stated in the docs). You may use an LSTableInfo to avoid the error above, but in that case you cannot refer to fields by name, and the item name argument of table updates will always be nil (i.e. you have to refer to fields and items by position only).

Hope this helps.
Best regards,

Gianluca

Hi Gianluca,

Thanks for the quick response.

I have tried to use LSTableInfo to no avail.

Regarding what you wrote: "the client received an update for item n. 2". Is it possible to check how many items for update do I have in this moment?

Many thanks again

dollar8

Hello,
I have changed logic to start using LSTableInfo. And got the following:
now this delegate is called:

-(void)table :Smile_Ac: LSSubscribedTableKey *)tableKey itemPosition :Smile_Ac: int)itemPosition itemName :Smile_Ac: NSString *)itemName didUpdateWithInfo :Smile_Ac: LSUpdateInfo *)updateInfo

But for some "Problem" markets I got itemPosition with value as "2" and for some "1".
where "itemPosition" is setted or who change it?
How can I catch when it changes?
(I think this is the main problem)

Thank you in advance.

gianluca.bertani

Hello again,

let's enter a bit more in the details. When you subscribe a table with LSTableInfoyou send a group name , its meaning may be anything from a single item to a whole list. Consider the case when you subscribe a list from a stock exchange: a group name like “NASDAQ_TOP_100” may actually indicate a list of 100 items.

The point where this conversion is done is in the Metadata Adapter: its method getItems(user, sessionId, groupName) receives a group name and returns the list of items it contains. This list is then passed to the Data Adapter for the actual subscription, and when it then sends updates they are marked as item 1, 2, etc. based on their position on the item list returned by getItems .

What the LSExtendedTableInfodoes is simply take a list of item names and patch them together with a separator (i.e. ["APPL", "MSFT"] becomes "AAPL MSFT") and send the result as the group name, knowing that the Metadata Adapter (that has to subclass LiteralBasedProvider ) in its getItems will split the group name in its original components (i.e. "AAPL MSFT" becomes again ["AAPL", "MSFT"]), thus providing updates for the exact number of items originally specified.

So, what is happening in your case is that there's a mismatch between the client and the Metadata Adapter on how to interpret the group name. The Metadata Adapter considers it a group of two items, while the client expects a single item. You should check with the Metadata Adapter developer. If you have access to the Server’s log, setting subscriptionsand pump loggers to debug should show the problem.

Best regards,

Gianluca

cipd

Hi Gianluca,

Thank you for the additional information, it definitely helped.

I eventually made progress by using the LSTableInfo, but am keen to use LSExtendedTableInfo so I will endeavour to find the discrepancy.

Thanks again!