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

[Romano]

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

Agreed. I use iOS client version 1.4.3 build 163 but it is still throwing Exceptions even for NSError version methods, which sounds like a blasphemy to me.
Exceptions should be caught at a lower level in the Lighstreamer code and converted to NSErrors.

On another topic, I tried a quick integration test of the pod version, not to actually use it, just for future integration when it will be time to move to it.
The thing is the pod is holding a static library, which makes it difficult/impossible to integrate in development pods:
https://github.com/CocoaPods/CocoaPods/issues/3267
https://github.com/CocoaPods/CocoaPods/issues/3346
https://github.com/CocoaPods/CocoaPods/issues/3583
https://github.com/CocoaPods/CocoaPods/issues/3985

[gianluca.bertani]

Hello Romano,

in client libraries version 1.x, there are some exceptions that we still throw from NSError methods because they are due to programmer errors. E.g. unsubscribing a table twice. Apple itself resorts to exceptions in such situations, to make the developer aware of the problem quickly.

Anyway, as stated before, since client library 2.0 the APIs have been redesigned and error handling is now fully asynchronous. No more exceptions or even NSErrors.

Regarding difficulties with our pods, a dependency we rely upon is distributed exclusively as a static library. As far as we know, to distribute a framework linked to a static library requires distributing the static library too, so that would not make any improvement. If you have better information to share with us, regarding these issues, we will surely consider them and take any appropriate step to improve our product.

Best regards,

Gianluca

[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