MultiDynaMetapushTable ebullient

Hello,

Is there a equivalent class in J2se client api for MultiDynaMetapushTable and DynaMetapushTable class as available in java web api?

If it is not how we can achieve the same for J2SE client?

Suppose we had subscribed a group of item with a schema, now we want to add one more item to this group, Is it possible to update this group or we have to make subscription call again for this item separately?
Can we use the same listener object as we used first time to subscribe the group?
Is it efficient to make subscription request for individual item?



I was going through the portfolio demo on web, would you please explain me these lines " Each added row automatically provokes an underlying subscription to a sub-item in MERGE mode"
Is there something sub-item concept? Or it simply subscribing individual item?

Quote:

---

Is there a equivalent class in J2se client api for MultiDynaMetapushTable and DynaMetapushTable class as available in java web api?

---

no, only the Flex API offers something similar to those javascript calsses.

Quote:

---

If it is not how we can achieve the same for J2SE client?

---

the J2SE client library does not offer visual widgets that you can use, so you have to subscribe to your items in COMMAND mode and handle the updates accordingly to show them on monitor.

Quote:

---

Suppose we had subscribed a group of item with a schema, now we want to add one more item to this group, Is it possible to update this group or we have to make subscription call again for this item separately?
Can we use the same listener object as we used first time to subscribe the group?
Is it efficient to make subscription request for individual item?

---

I leave those to Dario

Quote:

---

I was going through the portfolio demo on web, would you please explain me these lines " Each added row automatically provokes an underlying subscription to a sub-item in MERGE mode"
Is there something sub-item concept? Or it simply subscribing individual item?

---

The table is made by a main "portfolio" item subscribed to the PORTFOLIO_ADAPTER that provides the data you can see in the basic version of the portfolio demo

Each time a new row enters the COMMAND table a new subscription is made to the QUOTE_ADAPTER (that is the adapter that feeds the StockListDemo). This is a single item subscription.

HTH

I assume you are using the com.lightstreamer.ls_client package interface.

In the java client interface, the concept of "group" or "table" is not as important as, for instance, in javascript interface,
because there is no library-provided widget to which your groups can be associated.

In order to provide a simpler answer, may you please clarify which interface method and which of the available overloads are you currently using to perform your subscription?

Anyway, doing subscription requests for individual items is not less efficient, if you mean using subscribeItems in place of subscribeTable.
On the other hand, if you mean issuing multiple calls to subscribeItems to manage a single item for each call, then this may be a little less efficient than using a single aggregated call to subscribeItems. So, if the subscriptions have the same schema and can be aggregated, it is worth doing it.

Hello Dario,

We are using "subscribeItems" method to subscribe. We want to confirm that after subscribing some items (say 10 items),and after some time if we need to subscribe one more item, should we make a separate call to subscribe this item? in this case every time we make separate call, we have to handle it's update in separate instance of handler (HandyTableListener) or Is there some other way to update subscribed item?

Calling subscribeItems for a list of items is just a more efficient alternative to calling subscribeItems, in a cycle, for each item in the list and supplying the same listener instance for all the calls.
The only difference is that, in the former case, the itemPos parameter used by various listener invocations has a meaningful value, whereas, in the latter case, it is always 1.

So, unless you really need the itemPos parameter to identify the item involved in each invocation (that is, itemName is not enough because duplicated subscriptions are possible),
you can provide the same listener instance to multiple calls to subscribeItems, each of which, in turn, can manage either single items or lists.