Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 22

Thread: Exception [iOS]

  1. #11
    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.


  2. #12
    Join Date
    Jul 2006
    Milan, Italy
    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.



  3. #13
    Thanks! Looking forward

  4. #14
    Join Date
    Jul 2006
    Milan, Italy

    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.


  5. #15

    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).

    I looking forward to any response. Thanks

    ps: Do anybody except of me use last version of iOS library?
    Last edited by Dmitry Sazanovich; March 4th, 2015 at 08:49 PM.

  6. #16
    Join Date
    Feb 2012
    Bologna, Italy

    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, together with the library version and build number, so we can investigate.
    Best regards,


  7. #17
    Join Date
    Jul 2006
    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.

  8. #18
    Sent with Subject: Problems with iOS Client API version 1.4.1 build 157

  9. #19
    Seems we have unsupportable server version 5.x

  10. #20
    Join Date
    Jul 2006
    Milan, Italy
    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:

    Quote Originally Posted by Dmitry Sazanovich View Post
    Seems we have unsupportable server version 5.x



Similar Threads

  1. Connection timed out on empty credentials on iOS [iOS]
    By Anatoly Gurfinkel in forum Client SDKs
    Replies: 9
    Last Post: July 6th, 2015, 04:24 PM
  2. iOS client API encoding issue
    By LS_Developer in forum Client SDKs
    Replies: 3
    Last Post: February 14th, 2013, 02:47 PM
  3. LS iOS LSCommand mode sample
    By mibrahim.youxel in forum Client SDKs
    Replies: 4
    Last Post: December 3rd, 2012, 09:49 AM
  4. Bandwidth in iOS
    By bor306 in forum Client SDKs
    Replies: 7
    Last Post: July 11th, 2012, 02:28 PM
  5. iOS Client Library Preview
    By Alessandro in forum Client SDKs
    Replies: 0
    Last Post: March 28th, 2011, 03:06 PM

Tags for this Thread


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
All times are GMT +1. The time now is 11:50 PM.