Exception [iOS]

[Dmitry Sazanovich]

Would be nice to make a vote bw iOS programmers who are using this library, but I'm strongly sure that lib shouldn't throw exception.

Dmitry.V.Sazanovich

[Alessandro]

Hi Dmitry,

Thank you very much for the feedback provided in this thread.

We will take one or two weeks to ponder on this and get back to you.

Cheers,

Alessandro

[Dmitry Sazanovich]

Thanks! Looking forward

[Alessandro]

Dmitry,

As anticipated, we have been working on a plan to improve the lib based on the suggestions we received.

The short-term solution is a new release of the iOS client API, which will be available very soon (hopefully before the holiday season) as part of Lightstreamer 6.0.

For every method that may throw an exception, a corresponding non-exception-throwing version will be provided. This alternative method has the same semantic, parameters and return values, except for an additional NSError pointer reference that may be used (if not nil) to store a runtime error. For example:

@try {
    [client openConnectionWithInfo:connectionInfo delegate:self];
} @catch (NSException *e) {
    // Exception handling
}

May be replaced by:

NSError *error= nil;
[client openConnectionWithInfo:connectionInfo delegate:self error:&error];
if (error) {
   // Error handling
}

Note that exceptions due to programming errors (such as out-of-bounds access to arrays, etc.) may still be thrown.

The long-term solution was already part of the roadmap. A brand new API will be released on the future, base on the "unified client api" model, which has already been rolled out for JavaScript. The other languages will follow. The unified api is fully asynchronous and throws exceptions only in case of malformed parameters, etc.

Hope that helps.

Thanks,
Alessandro

[Dmitry Sazanovich]

Hello!

Today I decided update library. But I started getting a lot of bind_session.txt - one per update. I didn't touch anything more except of library and "include" files. Strange update, isn't it?

NB: even if I set next properties explicitly it doesn't solve problem
connectionInfo.streamSenseEnabled = YES;
connectionInfo.isPolling = NO;

Also I noted that LSConnectionInfo->pollingSecs now started redefine LSExtendedTableInfo->requestedMaxFrequency (I think should be vice-versa).

Also I found seems same problem at forum (but I updated only iOS Client).
http://forums.lightstreamer.com/showthread.php?1011-Upgraded-to-LS-4-and-many-POST-bind_session-txt

I looking forward to any response. Thanks


ps: Do anybody except of me use last version of iOS library?

[gianluca.bertani]

Hello,

calls to bind_session.txt are probably due to polling mode. The library may switch to polling mode when the network conditions require it. For example, if it cannot establish a streaming connection within the interval set into LSConnectionInfo.streamingTimeoutSecs.

If you believe this should not happen with your network and library settings, please enable the following log categories:

[LSLog enableSourceType:LOG_SRC_CLIENT];
[LSLog enableSourceType:LOG_SRC_SESSION];
[LSLog enableSourceType:LOG_SRC_STATE_MACHINE];

and send us the log at support@lightstreamer.com, together with the library version and build number, so we can investigate.
Best regards,

Gianluca

[DarioCrivelli]

Let me clarify the point with LSConnectionInfo->pollingSecs.

This parameter is usually 0.
This means that, in case of polling, a pure long polling is performed.
In this case, Lightstreamer does its best effort to send to the client all available updates;
as a consequence, any frequency limit settings, like LSExtendedTableInfo->requestedMaxFrequency, will be the only limits that will apply.

On the other hand, if you set it as nonzero, it forces a client-side pause between subsequent polls, which brings you in a synchronous polling scenario.
In this case, if the frequency of polls is lower than the LSExtendedTableInfo->requestedMaxFrequency setting of some item, it takes the precedence and lowers the update frequency seen by the application.

Note that this behavior has not changed.

[Dmitry Sazanovich]

Sent with Subject: Problems with iOS Client API version 1.4.1 build 157

[Dmitry Sazanovich]

Seems we have unsupportable server version 5.x

[Alessandro]

Lightstreamer Server 5.1 is currently still supported.
Lightstreamer iOS Client API 1.4.x requires Lightstreamer Server 6.
To use Lightstreamer Server 5.x, you need to go for iOS Client API 1.2.x.
Please see the changelog for full details: http://www.lightstreamer.com/distros...TML#ios_client

Seems we have unsupportable server version 5.x