Saving Data in iOS

May 31 2022 · Swift 5.5, iOS 15, Xcode 13

Part 1: Files & Data

07. String

Episode complete

Play next episode

Next
About this episode

Leave a rating/review

See forum comments
Cinema mode Mark complete Download course materials
Previous episode: 06. Saving & Loading Data Next episode: 08. Challenge: String Data

Get immediate access to this and 4,000+ other videos and books.

Take your career further with a Kodeco Personal Plan. With unlimited access to over 40+ books and 4,000+ professional videos in a single subscription, it's simply the best investment you can make in your development career.

Learn more Already a subscriber? Sign in.

Notes: 07. String

Apple’s String and Text documentation

This course was originally recorded in April 2020. It has been reviewed and all content and materials updated as of November 2021.

Heads up... You've reached locked video content where the transcript will be shown as obfuscated text.

Now, it's time for the big reveal. What exactly is stored in favorite bytes? Time to write the data again but this time with a file extension. You can open the favorite bytes URL to go to the document directory and there, you can see the favorite bytes file rendered as emoji. A bunch of happy cat faces, very nice use of 16 bytes of data I'd say. The TXT extension let's Finder know that the file you wrote just represents a string, which is why you get to see it in the Finder sidebar or via quick look. The same data without an extension, Finder doesn't know what to display for you. Now, let's read back the Safe Cats in Swift. In the last video, you read back the file without an extension into saved favorite bytes data. You can tell Swift that you're actually working with a string by using the string initializer that takes a data object and a string encoding. The mystery bytes represent the happy GetString using the very common UTF eight encoding. Also, the initializer is fallible but I know it's going to work so I'll force unwrap it. And now, your favorite bytes array is starting to make sense. Each one of the four rows is one of the cat faces and each one of them requires four bytes to be represented. But how was it known that putting together an array like this would result in four emoji faces? This is where the Unicode Standard comes in. Unicode, or Universal Coded Character Set is a standard that specifies the representation of text. UTF stands for Unicode Transformation Format and it's a set of standards for encoding the Unicode Character Set into bits of data. UTF eight or Unicode Transformation Format, a bit, is one of the encodings available. It is a variable with encoding that can be used to represent all characters in the Unicode Character Set UTF eight can use one to four eight bit bytes or an octet. There are other available encodings you can use like UTF 16 or UTF 32 but the main reasons why you can rely on UTF eight or that, one, it's backwards compatible with the ASCII character set. Two, it uses fewer bytes of data when storing things in memory or to a file and three, you don't need to think about or specify the byte order when using UTF eight. Now, I sure don't have all the cat emoji codes memorized, so maybe there's a less cryptic way to deal with the same string data of cat emoji?