Skip to main content
A
Anonymous
December 6, 2006
Question

onSync not chronological

  • December 6, 2006
  • 3 replies
  • 322 views
I've set up a basic chat app. I'm adding a new property for each message to a persistent remote SO called "chat_so". A message consists of a few sub properties(icon, color), as well as the message text. (The project requires each message to have these properties unique.) When a new user logs on, all the messages are successfully fetched by the onSync. However, the order of the properties is not chronological. Its almost like its in chronological chunks, but mixed together randomly. I haven't been able to dertimine any pattern in the chunks that are together(ie if they are all from the same user, etc). In my onSync I'm looping through from the first property to the last property.

What is the solution here to ensure that the message history is fetched in chronological order? I could put all the messages in an Array, but then each new message would require the entire message history to be re-downloaded, and I'll get write concurrency problems, as pointed out to me in another thread.
    This topic has been closed for replies.

    3 replies

    A
    Anonymous
    December 8, 2006
    tbh it's pretty UNcommon to use a persistent chat-history since you don't want people to read what you said before they connected. Imagine a gossip chat:

    Jenna: have you heard about Melanie ?
    Chris: No, wassup ?
    Jenna: she crashed her dad's car yesterday
    Chris: omg, that's nasty
    Jenna: yeah she can't drive
    Chris: yeah indeed she drives so bad

    Melanie joins the chat and gets the whole history.

    That's enough content for a nice soap :-)



    A
    Anonymous
    December 8, 2006
    Send the messages as objects:

    so.data["1"] = {txt:"Hi", icon:"smiley", misc:"foo"};
    so.data["2"] = {txt:"Bye", icon:"frown", misc:"bar"};

    ...to sort, you can simply create an Array on the client which you populate by looping through the synched data and adding:

    localMessageArr[parseInt(propertyName)] = propertyValue;

    ...after that, you loop through the array and handle the messages in the correct order.

    If you have holes in the numbers or a non zero index (for example, the messages range from 957 to 1026), you can create an Array populated by the numbers ([957, 958, 959...1026]), use numeric sort on it and then loop through it and use the values to pick messages out of the so.data.

    If you have 99999999 messages in an SO, no one will use your chat since the first connect would take all weekend. You have to clear out old messages every now and then.

    /Johan
    A
    Anonymous
    December 8, 2006
    > tbh it's pretty UNcommon to use a persistent chat-history since you don't want people to read what you said before they
    > connected
    You're right; I didn't want it to load because of the initial loading/rendering hit, but this is a highly specialized chat app for a small closed group of predefined people, and they require it that way.

    > If you have 99999999 messages in an SO, no one will use your chat since the first connect would take all weekend.
    That's a good point. Each chat has a relatively short lifespan and will be cleared afterwards(never longer than a day), so like I said, it should not ever get even close to that amount. But still, if a user logs out and comes back for some reason, near the end of the day, I hadn't thought about what a bandwidth & CPU strain it will initially cause to sync to the entire day's chat so far. Hm.

    > localMessageArr[parseInt(propertyName)] = propertyValue;
    This is actually a great idea, I like it. Still a slight performance hit on the client side, but the design sits much better with me. :-)

    Thanks both.
    A
    Anonymous
    December 8, 2006
    So apparently its alphabetical. (There was a flaw in my logic that was overwriting messages when a user logged out and back in, which was part of the confusion).

    The only solution, as much as I hated it, seemed to be to make sure all messages start the same, with a number. ex: m1, m2, m3, m4. But then you get the problem of alphabetical order not actually being numeric order, ex:
    1, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 2, 20, 21, 22 (notice position 1 and 2)
    And it gets worse as the numbers get higher. So, the incredibly ugly hack-around I used was to add leading zeros(ex. 001, 002, 003) up to 8 positions(ex. 00000001). Which, of course, means there can only be a finite number of messages, because after 99999999 messages, the same problem occurs. Now, that's a lot of messages, it seems impossible that at this stage an app instance would ever get near that, but its architecturally just nasty.

    Anyone have any better solutions? I can't think of any, apart from assigning a date to each message, and re-ordering them when received--which I don't want to do due to poor Flash sorting performance and bloating the message size with a date.
    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices