Complications - string length - AW hangs

Hello,


I noticed a very interesting behaviour of complications containing strings. When the content of a complication exceeds a number of signs, the device hangs and the only way to make it work again is to hard reboot it. This applies to both templates and current timeline entries. The number of signs depends on the complication family - for modular small it is about 6 signs when the font is set to bold. I didn't check the exact numbers for other families as it takes a lot of time to generate a string, reboot, etc. But it happens in all families.


Has anyone noticed such a behaviour? How did you cope with that?


Is it a bug or feature? I don't think it should be treated as a feature. The strings should get trimmed so that the string is chopped at the end. It should not lead to hanging the entire device...

Answered by CobraPA in 88117022

Interesting, this sounds like a bug with textProviderWithFormat: then, as I have passed longer strings and not seen crashes, but I was not using textProviderWithFormat:.


If you use the NSString creation with format, then pass it to:

[CLKSimpleTextProvider textProviderWithText: (yourstring) ]


Does that work for you? I have passed longer strings on the watch and they are just cut off using this method.

Sounds like a bugreport for sure. I haven't seen that one, as most long strings I tried just cut off in the complication field. When you say 'number of signs' what do you mean? Do you mean in a string formatter? How are you building the strings?


Are you using the text complication templates that have long and short strings, or just long strings?


textTemplate.textProvider = [CLKSimpleTextProvider

textProviderWithText: string /* shortText: shortstring */ ];

I found that passing a nil argument to a CLKTimeTextProvider will crash the watch. It does not freeze for me though, it looks like the watch reboots when the template is submitted. I've submitted a bug for that case.

Thank you for your response. I build strings in the following way:


NSString *numberOfNotesInString = [NSString stringWithFormat:NSLocalizedString(@"%i REC", nil),number];
complication.line2TextProvider = [CLKTextProvider textProviderWithFormat:@"%@", numberOfNotesInString];


If I change the REC to RECS for instance, the device will hang (when you turn on bold fonts; regular fonts will hang the device when you set %i RECORDINGS). I tried providing the NSLocalizedString directly to textProviderWithFormat but the result was the same (i.e. the device hangs). I keep preparing the string this way just for better readability of the code.

I'm no expert in NSLocalizedString, but from a quick look I suspect your usage is a problem. Are you using it and then running 'genstrings' to generate the table? Are you running 'genstrings' every time after you change from REC to RECS, for example? Also, I don't believe it meant to be used with a formatter string like that, but that's just from a quick read of the doc here: https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Miscellaneous/Foundation_Functions/#//apple_ref/c/macro/NSLocalizedString

Hello,


Thank you for your reply. I don't think it has anything to do with NSLocalizedStrings. I have both REC and RECS in my Localizable.strings and they are properly recognized within the app. When I change the translations to, e.g., R RS respectively, everything works flawlessly.


For testing, I also changed the line to:


complication.line2TextProvider = [CLKTextProvider textProviderWithFormat:@"%@", @"wabakutimbu"];


So there are no localized strings, but the problem persists. If I put it in the getPlaceholderTemplateForComplication, it hangs even the simulator.

Accepted Answer

Interesting, this sounds like a bug with textProviderWithFormat: then, as I have passed longer strings and not seen crashes, but I was not using textProviderWithFormat:.


If you use the NSString creation with format, then pass it to:

[CLKSimpleTextProvider textProviderWithText: (yourstring) ]


Does that work for you? I have passed longer strings on the watch and they are just cut off using this method.

Thank you! That did the trick - strings get trimmed properly. I will report the bug with textProviderWithFormat.

Glad it helped. Thanks for the warning about the broken one as well!

Complications - string length - AW hangs
 
 
Q