Learn how to save your strings and NSData to disc.
This is a companion discussion topic for the original entry at https://www.raywenderlich.com/3761-saving-data-in-ios/lessons/2
This is a companion discussion topic for the original entry at https://www.raywenderlich.com/3761-saving-data-in-ios/lessons/2
I had an hard time following the challenge because most of the functions have changed since the publication. It would be nice to actualized those.
There is a typo in the Challenge.pdf in the version of March 2017.
It tells you to define a class implementing FileManagerDelegate.
In the code example it is called SceneFolderDeletionDelegate, but in the rest of the text it is called SceneDeletionDelegate.
Being a beginner, I was assuming the challenge was to write my own SceneDeletionDelegate class that would fit in and streamline things.
I loved the challenge 
2 Likes
I personally really dislike the ridiculous Jim Carrey like style of these videos. Very hard to watch. Sorry. Ugg. Also we’re skipping over some issues very quickly, not explaining things clearly, presenting things in an incoherent and unsystematic order. For instance, instead of introducing the Filemanager class we jump straight to iCloud. It’s not even really clear why we’re talking about iCloud.
1 Like
At the end of the lesson if you find that only the “1 scene” folder has been created try closing and reopening your playground to solve the issue. Worked for me.
Fixed! Thanks very much for alerting us. Sorry about the delay; I hadn’t been getting notifications as I had expected I would be.
Please someone listen to this, this is a hard topic, getting hard to understand in this updated course.
The code writing style is hard to read.
No clear explanations about some of codes, the topic jumps around, very fast to follow.
the old version of this course is so much better
Please let me know what do you actually find hard to understand exactly in this version of the course after all. Thank you - much appreciated! :]
1 Like
I am just starting learning this course, and I am already overwhelmed in the second video.
For example starting min 9:25 when explaining this code:
let fileSize =
try URL(resolvingAliasAt: aliasURL)
.resourcesValues(forKey: [.fileSizeKey])
.fileSize!
....
it is so fast, the writing style is confusing, why even .resourcesValues & “.fileSize!” have an indentation, and why could be called just using dot .<name>
and instead explaining important things, I keep being reminded about the challenge, I think 3 times.
Thank you for replying my message.
@jessycatterwaul Do you have any feedback regarding all of this? Thank you - much appreciated! :]
1 Like
Thank you for your feedback!
In the code you mention, both the URL initializer and resourcesValues require try, but fileSize does not. We don’t have an official style guideline on this, but I’m thinking that it might be clearest to always match up each throwing method or initializer with its own try, so that it’s clearer what exactly might throw an error. This will require more intermediate constants, but that might help with clarity anyway. What do you think about this?
let originalURL = try URL(resolvingAliasFileAt: aliasURL)
let resourceValues = try originalURL.resourceValues(forKeys: [.fileSizeKey])
let fileSize = resourceValues.fileSize!
In general, I’ve found that I use more lines (and corresponding indentation) in my own code that I see most people using. I find wrapped lines of code very hard to read, and when we create our tutorial videos, we have our text size large enough that lots of wrapping occurs if rules are not employed to mitigate it. I document all the stylistic choices I make so that I can work towards 100% consistency, and I’m always interested in anything that will add clarity to my code.
Let me know if you have any other specific feedback. We’re working on an update to the course this week, so I might be able to improve things for you very soon!
1 Like
Hello Jessy,
Thank you for your explanation. And Thanks for the videos too!!
Here is my suggestions as a beginner.
-
Please explain briefly the codes that you write, for example, in File Manager Video, min 4:00, you mention “for searchPathDirectory, we want, document directory”, then you continue to the next parameter. As a beginner, which I assume most people who watch the video, probably if you explain a bit about what it is and why we want that ( like you do in the next two parameters). I believe that is a trivia for you, but it’s not for people who read it for the first time. If there are so many things to explain, please put the priority on the basic and fundamental first. And also, I think it’s better before writing explain what we’re going to write. For example in File Manager Video min 3:38: “store a reference to its URL…” this is not clear enough for newbie like me about what we are going to do… instead you can use: “we’re going to make a document Directory URL…” so it’s easy to understand about what we’re gonna do.
-
Please give 2-3 sec pause so before you jump into writing the next code after writing and explaining a code. Some people prefer to write a block of code right after the code explained, so the pause will let us know that we can pause at that time to read the code and to write it before we continue the lesson. I feel sometime this transition between writing a code to the next code is too fast, and, frankly, there is some moment, that when you are explaining the code, the code was blocked in the screen, for example in File Manager Video min 10:17. So I have a hard time to listen, while looking for the code section you are mentioning.
-
I know that you code writing style is easy to read, however, while I am watching the video, I am not only reading the code, but also trying copy what you write on the screen. And to be honest, it’s really hard to copy that style with the fast forward code writing. I have to account pressing tab, if it’s wrong it will look messy. I understand there are sometime long strings that will look ugly if we don’t create it on other lines, but sometime there are code easier to understand without using new lines, for example in File Manager Video min 10:58. The
"\(fileSize)" + (fileSize == 1 ? "scene" : "scenes")is easier to understand in 1 line rather than in 4 lines or more. -
And lastly, co-explaining with partner I believe it’s really hard. Because you have to make it flow, catch the previous flow from your partner, etc. A discontinuity makes learning confusing. I have an example for File Manager Video min 4:27, after Catie writes and explains a
documentDirectoryURLblock, there is an error, but the error is explained by Jessy. It’s subtle but, the experience that I get is confusing. There are two voices, while focusing on reading the code and understanding it. My suggestion for explaining the code is, just use the same person explaining the code until finish a chapter, then the other person could explain the other chapter, so the explanation will flow and easier to understand. I like the voices though, the tone is engaging.
I hope there is something that could be use from my suggestions.
I am really looking forward for the updated version.
P.S: Pardon my poor English
Best
1 Like
I have a few suggestions.
You probably already know that Xcode 9 beta doesn’t like the stickerscene files. There is something going wrong with file literal rendering between 8 and 9 that I’m unable to identify and work around.
I find teasing what awaits in the challenge distracting. Its okay at the very end, but the context switch from the current topic to a future topic back to the current topic is tough when I’m barely holding on to the narrative thread in the first place. Temporal jumps like this in the narrative feel disorienting, like jump cuts in a film. Same with switching between one another sentence to sentence. Perhaps a smoother ride might be had by switching speakers for each idea. This already happens often, and its very smooth. Even short, three sentence switchbacks are more gentle than single sentence jumps.
Lastly, I wish code examples included short single line comments that very briefly summarize the code block. I add these manually as a form of note taking when listening to the video on the second run though. But I think adding them to the video would act as anchors for each idea. Just to be clear, I’m suggesting comments that would be redundant in production code, but adds a breadcrumb trail that makes it easier to follow each new idea as its demonstrated.
I really like this course and found it very helpful. Thank you!
Bob