isEqualToString:<\/code> method to compare strings which does indeed clearly state:<\/p>\nThe comparison uses the canonical representation of strings, which for a particular string is the length of the string plus the Unicode characters that make up the string. When this method compares two strings, if the individual Unicodes are the same, then the strings are equal, regardless of the backing store. \u201cLiteral\u201d when applied to string comparison means that various Unicode decomposition rules are not applied and Unicode characters are individually compared. So, for instance, \u201c\u00d6\u201d represented as the composed character sequence \u201cO\u201d and umlaut would not compare equal to \u201c\u00d6\u201d represented as one Unicode character.<\/strong><\/p><\/blockquote>\nWhoops! \u00a0I\u2019ve switched over to using localizedCompare:<\/code> so you can expect the app to properly check document names from version 2.2.6:<\/p>\n![\"\"](\"https:\/\/naganashi.com\/kanjiflow\/wp-content\/uploads\/sites\/2\/2017\/03\/lecon-1.png\")
<\/p>\n
It\u2019ll also check when renaming documents:<\/p>\n
![\"\"](\"https:\/\/naganashi.com\/kanjiflow\/wp-content\/uploads\/sites\/2\/2017\/03\/lecon-2.png\")
<\/p>\n
I\u2019m really sorry for any trouble this may have caused anyone and I\u2019m greatly appreciative of the user that reported the issue.<\/p>\n
Please do continue letting me know if you notice any strange behavior and I\u2019ll continue improving things.<\/p>\n
Happy studies!<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":"A user reported that he inadvertently overwrote one of his documents because he accidentally used the same name when creating a new lesson. He was wondering why there wasn\u2019t some sort of warning to prevent this. I clearly remember writing quite a bit of code in order to stop this very scenario from occurring so … <\/p>\n