messagegui: refactor the messages scroller and use it more (WIP)

[thyttan]

WIP

Initializes the scroller with three messages loaded. When scrolling to the top/bottom new messages are loaded.

This is far from merge ready and I'm not sure it should ever be merged. Should be implemented as a setting if to be merged I think.

With that said it can be tried from my app loader: https://thyttan.github.io/BangleApps/?id=messagegui

[thyttan]

I'm testing/developing this by generating test messages from the WebIDE console field by pasting:

let i = 0;
let msgInterval = setInterval(
  ()=>{  
    print(i);
    GB({"t":"notify","id":1575479849+i,"src":"Hangouts","sender":"sender"+i,"title":"A Name"+i,"body":"message contents that are very similar to one another. in that they are somewhat long, and exactly the same. Let's have it go on and on and so forth for a while to make sure we overflow properly."});
    i++;
    if (i == 9) {clearInterval(msgInterval); delete i; delete msgInterval;}
  }, 500
);

[thyttan]

@bobrippling If you'd help me by testing this a bit I'd be interested to hear your thoughts!

[bobrippling]

@bobrippling If you'd help me by testing this a bit I'd be interested to hear your thoughts!

Sorry I missed this the first time round - taken a look, I like it, very nifty feature to have! And it's quite easily discoverable too. Means I have less cause to dig my phone out, works really well.

I do have two thoughts:

• The scrolling direction makes sense on the message overview but then on returning to the router the direction is then the opposite. Maybe we swap that around, or add an option for it? (happy to leave this to another PR)
• When scrolling down there's a bit of a yank/lag as it loads in the next message, but oddly not if I go up and load in the previous. Do you see that?

[thyttan]

very nifty feature to have! And it's quite easily discoverable too. Means I have less cause to dig my phone out, works really well.

Thanks! I wanted the bigger font of the scroller for what pops up for legibility's sake.

I do have two thoughts:

• The scrolling direction makes sense on the message overview but then on returning to the router the direction is then the opposite. Maybe we swap that around, or add an option for it? (happy to leave this to another PR)

Yeah, this feels a bit unfortunate to me as well.

• For the scroller it feels right to me how I've made it so the newest message is the one furthest to the top (similar to the list menu screen).
• For the overview screen (the function renamed from just "showMessage" to "showMessageOverview") that comes to the discussion of what is up/and down motions w r t swipes. People have different interpretations based on previous experiences as discussed here. When implementing the swipes I went with the style I believe Gordon uses for swipe interactions.
  • My thinking is that a relatively good solution to the different intuitions people have regarding this is to develop the Swipe inversion app more (initial PR: swipeinv: new app #3217).

• When scrolling down there's a bit of a yank/lag as it loads in the next message, but oddly not if I go up and load in the previous. Do you see that?

Yes, that is partly a limitation of the implementation. But I also find it a bit convenient that the scrolling stops at the end (or start, depending of if you scroll up or down) of the current message. So I don't scroll past the message by accident (I use kinetic scroll for my scrollers). The yank happens when another message is added to the array of wrapped strings and the scroller is reinited with that updated array. The yank (currently actually a 40ms timeout) also makes sure there are not other graphical glitches while loading in the next/previous message.

The yank doesn't happen when you go back because those messages are already part of the array of wrapped strings.

On another note, I'm a bit unhappy with how involved the code for processing, passing around and updating the alreadyProcessed data in showMessagesScroller is now. It feels like it's not super easy to read at first glance?

[bobrippling]

Thanks! I wanted the bigger font of the scroller for what pops up for legibility's sake.

Nice idea, I've not been using my watch with GB for a little while but this might bring it back. And your podcast controls I've recently spotted too - in that other thread

• The scrolling direction makes sense on the message overview but then on returning to the router the direction is then the opposite.
  Yeah, this feels a bit unfortunate to me as well.

• For the scroller it feels right to me how I've made it so the newest message is the one furthest to the top (similar to the list menu screen).
• For the overview screen (the function renamed from just "showMessage" to "showMessageOverview") that comes to the discussion of what is up/and down motions w r t swipes. People have different interpretations based on previous experiences as discussed here. When implementing the swipes I went with the style I believe Gordon uses for swipe interactions.

Yeah that's reasonable, I hadn't actually clocked the order of the messages, I think that works well. I suppose we could always try it for a while, perhaps invert it ourselves and see if that feels more "natural". Or yes - try with swipeinv

• When scrolling down there's a bit of a yank/lag as it loads in the next message, but oddly not if I go up and load in the previous. Do you see that?
  Yes, that is partly a limitation of the implementation. But I also find it a bit convenient that the scrolling stops at the end (or start, depending of if you scroll up or down) of the current message. So I don't scroll past the message by accident (I use kinetic scroll for my scrollers). The yank happens when another message is added to the array of wrapped strings and the scroller is reinited with that updated array. The yank (currently actually a 40ms timeout) also makes sure there are not other graphical glitches while loading in the next/previous message.

That's a good point about halting in fact - I think with kineticscroll especially it'll stand out as a clear and intentional stop. I think like above, we could try this for a while and see how it feels

On another note, I'm a bit unhappy with how involved the code for processing, passing around and updating the alreadyProcessed data in showMessagesScroller is now. It feels like it's not super easy to read at first glance?

Yes I haven't fully got my head round it - I jumped in with a live test of it instead! I can have a go at suggesting some alterations (if I can come up with any), if you would find it useful to have another point of view?