Happy to complete another module today! Although, much of the navigation within views still confuses me. I read in here that a few people struggled with backend/ database stuff, while I’m the opposite. I find the front-end UI stuff more confusing, especially as it comes to tracking tags/ selections in tab views and all of the different State properties that bounce you left and right.
Also, I’m confused, because my Learning App’s questions don’t work. I’m going to post about it for some more details.
Was happy today to finally learn how to save data locally within an app! It is a bit complicated, but I love the way Chris breaks it down. Plus, because you can access the contextView needed to interact with Core Data anywhere in the app by passing it down via an environment variable it is simple to save data locally.
Today, I learned how to sort and filter core data. Much simpler than I would have thought!
You can’t beat the way Chris explains these concepts… I would love to find a similar course-set for Kotlin or how to develop Android apps.
This piece of code sorts the people by age as well as filters only for users named Joe:
@FetchRequest(sortDescriptors: [
NSSortDescriptor(key: "name", ascending: true), // Sort by name first
NSSortDescriptor(key: "age", ascending: true) // Then sort by age
], predicate: NSPredicate(format: "name contains 'Joe'"))
var people: FetchedResults<Person>
Day 16 - Finished M5L4/ Started M5L5 - Filtered Data & Entity Relationships
Wednesday, January 12, 2022
Today, I learned how to better search/ filter data through requests to the Core Data model. In particular, I was impressed by the .onChange modifier. This modifier, allows you to run a piece of code as soon as one of your binding variables change. So as soon as the person types a character, it searches for all Core Data person values that match.
// Whenever the filterByText value changes, it will retrieve the data from the database
.onChange(of: filterByText) { newValue in
// Fetches core data
fetchData()
}
I also learned about relationships between entities. The terms graph data still confuse me that Chris mentions, but this will make more sense with time.
I was happy to finish the last Core Data lesson! It’s easier than I thought to save information locally. Honestly, I wish I had learned this prior to all of the Firebase stuff. Still, there were some confusing components to it like the viewContext that must be used in order to access the Core Data. I’d love to see this code combined with that with Firebase or other things.
Also, I was dissapointed, but it seems like both this module and the one before it, lack wrap-up challenges. Those reinforce the concepts the most for me, and ensure I learn it. Therefore, I will likely create my own demo project to try out many of the concepts in this.
Today, I finished my first Apple Watch app! I went through the Apple tutorial thanks to @mikaelacaron found here: Apple Developer Documentation. Highly recommend others to try this, if your curious at all about building a watchOS app! It’s much easier than you might think, and you can likely build it for many of your iOS apps right away.
Yeah, absolutely, it was a little daunting at first. I almost gave up after getting stuck on a simple problem for 20 minutes (how to open Apple’s demo code), but am glad I pushed through. It seems like any iOS app could also have a simple watchOS companion app as well with a little more effort! Let me know, when you give it a shot
I was disappointed to not find any challenges for modules four and five in the iOS databases course. Therefore, at least for the Module five all about Core Data, I created my own challenge based on the unusual trade of buying un-delivered packages/ pallets, or lost baggage. I plan to post the challenge/ also the solution here:
After many hours, and some confusion, I got a working Model View View-Model (MVVM) app with Core Data. I like this pattern of working with Core Data better in contrast to passing in the viewContext as an environment object to the Views. Apple’s docs and Chris’s videos teach this way, but I prefer the way described by Matt Righetti here: SwiftUI and Core Data: The MVVM Way | by Mattia Righetti | Better Programming
I plan to finish this app, then go onto the next lesson/ module in the iOS Databases course. Once again, I find that I learn the most through challenges, and this one was no exception.
I’m thrilled with the progress I’ve achieved in Swift. I can write my own code, and most importantly debug it. It was such a challenge to get here. I’m so grateful for this platform, the staff at CWC+, and the community that taught me so much! This is perfect for learning a new language, and wish similar ones existed for many other languages as well.
Thought I had a good understanding of SwiftUI/ the transitions between the View states, but I am still struggling to get everything working as they should. I’m even tempted to return back to the Foundations courses at times, because I don’t understand some of this stuff on my own.
Congrats on completing Core Data Andrew!! Your consistent progress is impressive
Don’t worry about it! It’s easy to forget stuff
During our Foundations journey, Flo and I used Notion to document the lessons and track our progress. That was June/July 2021 and I’ve been coding almost everyday since then, yet as of this day I still need to come back to it every now and then!
The CWC+ videos provide a clear understanding of the concepts, but sometimes you just forget stuff like syntax. Most of the time, a quick read at old code (especially from Challenges) should do the trick. The times it doesn’t, it’s worth watching the video again!
I gave up on having a separate ViewModel for each View as professed in the Design of Matt Righetti here: SwiftUI and Core Data: The MVVM Way | by Mattia Righetti | Better Programming. I like the goal of having separate Models/ Views/ ViewModels for Core Data, but the implementation can be rough. Through this other design pattern, it was a lot more difficult to transition between Views.
Also, the biggest disadvantage of it, is that instead of initializing an object once, reading the data from the Data Store once, an often expensive and slow task, in this pattern (or at least in Righetti’s example), each object’s initialization caused it to re-read the same data from the data store. This is the biggest disadvantage to this. It is the biggest reason to keep a bigger ViewModel, if it means that you do not need to read multiple times from the Data Store.
Today, I completed lesson two in the final iOS Databases Module. It is tedious, but important work. I’m so happy to learn how to add Core Data support to an existing app. My next thoughts/ what I’m curious about is how to blend Core Data with an external database as well. Still, very glad to get through this, even if it took me nearly two hours to watch/ type along to this half-hour video!
Day 24 - iOS Databases M6L3 - Preloading Core Data
Sunday, January 23, 2022
Unfortunately, I was not able to code as much as I would have liked! Again, started coding in the day too late, then not able to continue later. Thankfully, was able to start the iOS Databases Module 6 Lesson 3 about pre-loading data from JSON into Core Data.
Day 25 - iOS Databases M6L3 Finished Preloading Core Data
Monday, January 24, 2022
Today, I finished loading JSON into my Core Data store on its initial load. It’s a tedious and somewhat redundant task, but thankfully does not seem too tricky!
I would love to see Core Data combined with a project that uses an external database like Firebase as well!
Happy to code earlier today, and am watching Chris’s videos at normal speed. Previously, I would watch them sped up to 1.5 or 1.75 times the normal speed, but on second-thought maybe that stopped me from learning as much. I’m not sure. Anyways, I’m going through the videos a little slower now, but am still going forward
Day 26 - iOS Databases Finished M6L4 Featured View
Tuesday, January 25, 2022
Today, I finished creating the feature view of the app with Core Data.
I love how using Core Data can actually makes things faster already! We can take advantage of the predicates in order to query the data store for specific attributes, like returning all of the featured recipes. This is more efficient in contrast to looping through all seven recipes, or pulling all seven from the data store as well.
Day 27 - iOS Databases Recipes app List View with Core Data
Thursday, January 27, 2022
Today, I finished the Module 6 Lesson 5 list view lesson The fastest part was the Core Data part. While the longest part was the Search button part. I also made my search button, so it could search for any text in the recipe’s name or description, and match any case with the following code. Interesting to use a filter as well:
private var filteredRecipes: [Recipe] {
// Check the filtered text without extra space or new lines. If no text used, then return all the recipes
if filterBy.trimmingCharacters(in: .whitespacesAndNewlines) == "" {
// Used to catch the FectedResults as an array
return Array(recipes)
}
// Return a subset of the list, if it contains any of the keywords in the name or in the highlights
return recipes.filter { r in
// Compares the uppercased versions of the strings
if r.name.uppercased().contains(filterBy.trimmingCharacters(in: .whitespacesAndNewlines).uppercased()) {
return true
}
// Loops through the highlight words, e.g. Spicy, Easy to cook, to see if it contains the text the user typed
for highlight in r.highlights {
if highlight.uppercased().contains(filterBy.trimmingCharacters(in: .whitespacesAndNewlines).uppercased()) {
return true
}
}
// If it doesn't contain the string, then this subset isn't returned
return false
// If it contains part of the name, then include this element/ as a subset, returning true
// return (r.name.contains(filterBy.trimmingCharacters(in: .whitespacesAndNewlines)))
}
}
Day 28 - Adding Form for new Recipes to Recipe app
Friday, January 28, 2022
Today, I started the iOS Databases, Module 6, “Lesson 6: Add Recipe View and Form” lesson. I’m still troubled by how much code that would normally be in the ViewModel seems to seep into the Views with Core Data. For example, when interacting with Firebase, you would think to place all those methods into the ViewModel. Instead, with Core Data, you’re placing many of the methods into the View itself directly. I don’t like this…
However, today, I got bogged down more chasing the root of an alias popping up in my GitHub commits that I’m not sure where the root comes from…
