Hi,
I am transitioning to Swift UI and just learning persistence. I just bought the book and its really old. Is there plans to write it for SwiftUI?
Hey @mazurick! The book is actually updated every year, but we decided to not include any SwiftUI this last update just because of how experimental it was closer to WWDC. Iām sure when we update the book again this year weāll reconsider how much SwiftUI the book should have covered!
1 Like
How do you recommend one proceeds if he has mastered SwiftUI and wants to gradually create apps that satisfy needs and outcomes? I need to handle persistence? How would you approach learning that until you do the update? Just work with the books as it is? Its not bad, I got the first project working. The higher-order concepts make sense and I am handling fetch requests fine.
@mazurick My suggestion would be to go through the book, but use SwiftUI to implement the apps instead of copying the sample code. Make it your own!
And definitely report back some of the pain points or unknowns! That could help inform on on how to approach adding in consideration for SwiftUI and Combine. I havenāt had the opportunity to use SwiftUI in a production environment yet, so I donāt have all the answers yet. 
1 Like
I am using CoreData with SwiftUI by implementing an ObservableObject. All the heavy data lifting lives in there. There are ways to do simple fetches with CoreData. Check out this article for more details.
Thank you @briansipple @astralbodies @fweissi I am extremely thankful for your help. My background is in Human-Computer Interaction and Computer Engineering. I am a Python guy by education and trade. I have been working with Swift developing the front-end for several years first in UIKit and then in Swift UI. Iāve spent the last few days after work going through Chapter1.
Two questions.
- Do my annotations look correct? I sometimes prepare annotations for code I write from the book. I challenge myself to describe line by line what is happening. I want to make sure I understand what is happening. I donāt really use tables that much in Swift.
- As developers, is it uncommon to spend this much time looking at a small block?
- Returns the number of people in the array (not the number of names)
- The function returns a UITableViewCell
- āletā person defines a *constant stored property" whoās value is initialized with a copy of people[indexPath.row]. The value is not being assigned to the array. Also, note the difference between an IndexPath, IndexPath.section, and IndexPath.row.
Thank you so much. FYI, I too have a German Shepherd. Nice pic @billm. On point 5, my bad, I meant to write constant. Ok perfect. thanks again.
From what you wrote, I would conclude that you really donāt understand the DataSource pattern. I am not trying to be harsh, but instead give you a better mental model of what is going on.
When you instantiate a UITableView, you get a lot code that just works. However, the table view has no idea of what it will present. That is the purpose of the UITableViewDataSource protocol. The protocol is a contract with you, the developer, to tell it how many items it will display and fill its cells with something meaningful for the end user.
So the first method is actually call tableView:numberOfRowsInSection. The method is providing you the table that is requesting the number of rows for a specific section in the table view. For example it is telling you that a specific table in the view hierarchy is ready to display a specific section. It needs for you to tell it how many rows you need to display. In your specific example, there is only one section and the number of rows corresponds to the number of elements in the people array.
The next callback from UITableView will be to ask you to fill a row of data into a special container called a UITableViewCell. Remember that UITableView has no idea how you want to lay out your data. Therefore, you must do that for the tableview. Again, the method provides you with a table view and an index path. The index path tells you which section (in this case the only section,) and the row that will be displayed. This is where you are using the indexPathās row attribute to figure out what row you are providing data for. Then you ask to re-use a table view cell so you are not creating one for each row in your people array. On small screened devices, you can only show a few rows at any given time. Therefore, when a row leaves the visible range of the table view, that cell can be reused. If there is no cell ready for reuse, the table view will create a new cell based on the reuse identifier you have provide. That allows the table view to pick exactly which cell ārecipeā you want to use.
Now that you know what cell you are putting data into, it is up to you fill the labels in that cell with data. That is what you are doing when you tell the cell.textLabel?.text to take on the value in the peopleās array at some row. Again, I think you need a different mental model. The thing in the array is actually a Managed Object. The people variable is not the Managed Obect. A managed object is just like a Swift struct or class that has variables (var) that store data. These are also called stored properties. Stored properties are the attributes your data model. They are the things you care about.
If you were to write:
let personInFocus = people[indexPath.row]
that would mean that you are focusing in a specific Person inside the people array. Now that personInFocus can be the data source for any labels in your table view cell you need to display to the end user. In this case, you could have more simply written:
cell.textLabel?.text = personInFocus.name
Since the Swift compiler handles type safety for you, it knows that text (inside a UILabel) requires a String value. It knows that a Person object has an attribute named ānameā and that name is a String. These are all defined in your CoreData model. The reason it is called a ManagedObject is that NSManagedObject knows how to populate your instances of a ManagedObject with data that it retrieves from an external data store like SQLite.
I know I have introduced a lot of vocabulary, but vocabulary really helps you understand the documentation. Without that, you will find it hard to read Appleās or any other sourceās CoreData documentation. There are all kinds of class on this site that deal directly with Swift vocabulary. Take a look at Programming in Swift: Functions and Types and Fundamental iOS Design Patterns. These courses will help with vocabulary and your mental models so you can better understand how Apple thinks you should write code. Thinking like Apple Developers makes you an Apple Developer. And, it will help you solve future problems more easily.
I hope what I have written helps you become an Apple Developer, and enjoy Swift a little more.
1 Like
When you get a response like the one you provided, oneās knee jerk reaction might be to feel a little hurt. In my case, I re-read your comment several times. I could tell that it was a) factual and b) well-intentioned.
I temporaily put-aside persistence to revisit a tableViews. I have been studying them since Monday.
I believe I understand persistence in Chapter 1, but I had the wrong mental-model of tableViews and how they recycle cells and of how that data is structured.
I studied this all week and I think I am better for it.
I believe the problem I had was as you mentioned āthe wrong mental modelā
I am so happy my explanation helped. In my experience working with beginners, most donāt comprehend just how much is happening in a Table View. UITableView is very complex class. It did not really make sense for me when I started too. I apologize if my tone was too critical. I was not trying to be. I was just trying to be succinct, which can come off as being critical or cold. Spend some time with UITableView and experiment with the many DataSource and Delegate methods. If you are using UIKit, you really need to master this view.
Keep on coding!
1 Like
I am incredibly thankful for your honesty. If you did not write that statement, I would have gone on thinking I had a handle on UITableViews when I do not.
I am trying to release an app ASAP that involves two critical things.
- Organizing data into a tableView.
- Keeping the data in a persistent store like the SQL Lite container that comes with Core Data.
After reading your message, I realized I needed to learn tableViews more deeply if I want to achieve my goal above.
4 days later I realized my mistake was as you said, thinking the class was simple. I found myself totally understanding persistence, it was the tableView class that was confusing me. I underestimated it.
Simply stated, I had the wrong mental model of UITableView. I didnāt know the following two things, and this messed with my understanding of what was going on.
A) Reuse identifier - I didnāt know that iOS/Swift was elegantly recycling cells to ensure they fit on the screen. It took several re-reads of the tutorial to really understand this. I was like, āWTF are we recycling?ā
B) IndexPaths - I previously thought data was structured in some way similar to a collection or structure. I thought there is likely aa particular method or syntactical sugar that I use to access values that are contained in certain column locations.
This ^^ is a big mistake.
There is just one column which is the tableView. If we need to customize the cell, we use a custom cell style. Then there a limited number of cells, and depending on your app you could have thousands of rows of data.
An index path just refers to a section and a row.
numberOfRowsInSection just gives us the number of rows in a section.
Thatās not enough though, we still need to provide the cell and thatās what the second callback is for. The method is called everytime TableView needs a cell.
The tutorial that helped me is thisā¦
https://www.raywenderlich.com/5995-beginning-table-views
Thank you once again. My only concern is that my goal was to build the app entirely in SwiftUI, however, Iām finding that documentation is still being written. I guess I will learn TableViews and Persistence using UIKit and then refactor my app at a later stage when I have learned how those UIKit basics apply to SwiftUI.
1 Like
This topic was automatically closed after 166 days. New replies are no longer allowed.