Fixed
Status Update
Comments
da...@google.com <da...@google.com> #2
Hi, sorry for the trouble. I am working on improving our radio HAL. Unfortunately, it will take a while because it is very large. Please do not send non-ASCII characters in SMS.
ae...@gmail.com <ae...@gmail.com> #3
Hi, I don't know if it may be implemented as quick fix on the actual code, but looks like Ñ is the only alphabet letter having the issue (at least between ones widely used within GSM 03.38 GSM 7-bit).
I've tried with ÄÇÖÜà èéìòùäñöü and all of them are correctly sending only one SMS and not two concatenated.
I've tried with ÄÇÖÜà èéìòùäñöü and all of them are correctly sending only one SMS and not two concatenated.
da...@google.com <da...@google.com>
da...@google.com <da...@google.com>
ap...@google.com <ap...@google.com> #4
I've tried with ÄÇÖÜà èéìòùäñöü and all of them are correctly sending only one SMS and not two concatenated.
I see, maybe we missed that one Unicode somewhere then. Could be easier to fix then. I will take a look this week. Thank you for pointing this.
na...@google.com <na...@google.com> #5
Just to get the full picture, I've tested with all characters included here https://en.wikipedia.org/wiki/GSM_03.38 both in Basic Character Set (they should take 1 char of the 160) and Basic Character Set Extension (they should take 2 char, first is ESC prefix) and the only one causing the issue is Ñ
Sending a character outside that set, like á, message it's correctly split into 2 parts, first one of 70 chars as expected.
Sending a character outside that set, like á, message it's correctly split into 2 parts, first one of 70 chars as expected.
Description
In this block :
After wrapped in here , data flow couldn't receive any change, neither any invalidation observer.
immediateTransaction
, which mentionedIn pure Room without KMP, multiple DAO operations normally wrapped in
database.withTransaction
block. How to do in KMP?