Cards Display Large Portions of Text As Blank (Aplite)

[gitgud-software]

The above screenshot should say everything. Basalt builds handle large amounts of text just fine, but Aplite has trouble with the same load and just serves the card as blank if it can't handle that amount of text.

[dnschneid]

I'm running into this issue too, which brings up a point that could use some documentation/changes:
Is there a limit to the amount of text that can/should be passed to Card? Is that limit different on aplite vs. basalt? Will the answer change once pagination comes into the mix for chalk?

I feel kinda weird throwing a lot of text at Card without knowing these things (Menu nicely streams items, but I don't know what Card does). If there was a callback when hitting the bottom or top of a scrollable window, I'd implement some pagination, but as far as I know, that doesn't exist in pebble.js at the moment.

[Meiguro]

Hmm, yes, this was major issue when getting it to work on Aplite 3.x. The 2.x variants of all the Pebble C UI elements were simpler so they actually used less space. Now with 3.x there is less space left since Pebble.js uses many of the elements to be configurable. It looks like I'll have to make it leaner to hit a target.

Card doesn't stream text, but that's a pretty good idea, I should keep that in mind. Without streaming, what target sizes would you like supported? I'll try to hit that target and document limits. I don't know the limits offhand, but I would hope it could show at least 1K of text. I wouldn't be surprised if it's not able to on Aplite 3.x as of now.

[dnschneid]

In my app, the limit is somewhere between 768 and 1024 characters before Aplite stops rendering.

I also have noticed that even on the Time, doing much more than 1024 characters really kills rendering performance on the watch (noticeable when scrolling), so targeting 1K characters seems reasonable.

I think what the API needs is an event that fires when attempting to scroll past the start or the end; that way we can trivially implement our own pagination (or advance to the next set of data, etc).

[gitgud-software]

Yeah off-hand 1k characters should allow for most reasonable sized messages to display fully while truncating larger comments automatically. I'd like for this to be a temporary hack while you make the code a bit leaner on memory, but I can understand the recent shift from the 2.x to 3.x SDK making this difficult.

[Meiguro]

Thanks, I'll try to hit the 1KB target. I have a few ideas, but it'll take quite a bit of work. In the mean time, I have added truncation behavior on the C-side on master, so current 1KB strings that were successfully sent over but are too large to be used will at least have half or less retained instead of displaying nothing. This isn't meant to solve the solution, but I thought it was worth to have while a solution is being made.