I am using SwiftUI to create an infinite scrolling List by:
// My data structure
struct MyData {
title: String
}
// My datasource variable
#State var datasource: [MyData]
// My List view
List(datasource.enumerated().map({ $0 }), id: \.title) { (index, myData) in
MyListRow(myData)
.onAppear(perform: {
if index == datasource.count - 2 {
fetchMoreData()
}
})
}
By this code, when I scroll to the bottom, the List automatically increases as I wish.
However, in fact, the WHOLE List was redrawn! Which means the List rows that has been previously constructed were de-inited and inited again.
My question is: How to prevent SwiftUI from redrawing the whole list, but only draw the newly added rows?
Inited is not drawn. By modifying datasource you initiated List refresh, which resulted in reconstructing row values, but redrawn (called body) only for those which differ from previous. Moreover List caches rows and does not keep more than fit onto screen, plus couple, at all. So it just cannot redraw whole bunch of rows, because ignores invisibles.
So, just don't do anything heavy in View.init, which I assume you do and complain on it's re-doing on refresh.
Related
I am showing the conversation in the view, initially only the end of the conversation is loaded. To simplify it's something like this:
ScrollViewReader { proxy in
ScrollView {
LazyVStack {
ForEach(items) { item in
itemView(item)
.onAppear { prependItems(item) }
}
.onAppear {
if let id = items.last?.id {
proxy.scrollTo(id, anchor: .bottom)
}
}
}
}
}
func prependItems(item: Item) {
// return if already loading
// or if the item that fired onAppear
// is not close to the beginning of the list
// ...
let moreItems = loadPreviousItems(items)
items.insert(contentsOf: moreItems, at: 0)
}
The problem is that when the items are prepended to the list, the list view position remains the same relative to the new start of the list, and trying to programmatically scroll back to the item that fired loading previous items does not work if scrollbar is moving at the time...
A possible solution I can think of would be to flip the whole list view upside down, reverse the list (so that the new items are appended rather than prepended), then flip each item upside down, but firstly it is some terrible hack, and, more importantly, the scrollbar would be on the left...
Is there a better solution for backwards infinite scroll in SwiftUI?
EDIT: it is possible to avoid left scrollbar by using scaleEffect(CGSize(width: 1, height: -1)) instead of rotationEffect(.degrees(180)), but in either case item contextMenu is broken one way or another, so it is not a viable option, unfortunately, as otherwise scaleEffect works reasonably well...
EDIT2: The answer that helps fixing broken context menu, e.g. with a custom context menu in UIKit or in some other way, can also be acceptable, and I posted it to freelancer in case somebody is interested to help with that: https://www.freelancer.com/projects/swift/Custom-UIKit-context-menu-SwiftUI/details
Have you tried this?
self.data = []
DispatchQueue.main.asyncAfter(deadline: .now() + 0.01)
{
self.data = self.idx == 0 ? ContentView.data1 : ContentView.data2
}
Basically what this does is first empty the array and then set it again to something, but with a little delay. That way the ScrollView empties out, resets the scroll position (as it's empty) and repopulates with the new data and scrolled to the top.
So far the only solution I could find was to flip the view and each item:
ScrollViewReader { proxy in
ScrollView {
LazyVStack {
ForEach(items.reversed()) { item in
itemView(item)
.onAppear { prependItems(item) }
.scaleEffect(x: 1, y -1)
}
.onAppear {
if let id = items.last?.id {
proxy.scrollTo(id, anchor: .bottom)
}
}
}
}
.scaleEffect(x: 1, y -1)
}
func prependItems(item: Item) {
// return if already loading
// or if the item that fired onAppear
// is not close to the beginning of the list
// ...
let moreItems = loadPreviousItems(items)
items.insert(contentsOf: moreItems, at: 0)
}
I ended up maintaining reversed model, instead of reversing on the fly as in the above sample, as on long lists the updates become very slow.
This approach breaks swiftUI context menu, as I wrote in the question, so UIKit context menu should be used. The only solution that worked for me, with dynamically sized items and allowing interactions with the item of the list was this one.
What it is doing, effectively, is putting a transparent overlay view with an attached context menu on top of SwiftUI list item, and then putting a copy of the original SwiftUI item on top - not doing this last step makes an item that does not allow tap interactions, so if it were acceptable - it would be better. The linked answer allows to briefly see the edges of the original SwiftUI view during the interaction; it can be avoided by making the original view hidden.
The full code we have is here.
The downside of this approach is that copying the original item prevents its partial updates in the copy, so for every update its view ID must change, and it is more visible to the user when the full update happens... So I believe making a fully custom reverse lazy scroll would be a better (but more complex) solution.
We would like to sponsor the development of reverse lazy scroll as an open-source component/library - we would use it in SimpleX Chat and it would be available for any other messaging applications. Please approach me if you are able and interested to do it.
I found a link related to your question: https://dev.to/gualtierofr/infinite-scrolling-in-swiftui-1p3l
it worked for me so you can implement parts of that in ur code
struct StargazersViewInfiniteScroll: View {
#ObservedObject var viewModel:StargazersViewModel
var body: some View {
List(viewModel.stargazers) { stargazer in
StargazerView(stargazer: stargazer)
.onAppear {
self.elementOnAppear(stargazer)
}
}
}
private func elementOnAppear(_ stargazer:User) {
if self.viewModel.isLastStargazer(stargazer) {
self.viewModel.getNextStargazers { success in
print("next data received")
}
}
}
you can take what you need from here
I'll keep it simple, I have a List with UUID identified items. This list is selectable, when EditMode() is entered user can tap items, and these get added to the selection variable:
And the selection variable is:
#State var selection = Set<UUID?>()
However, the issue is that I care about the order in which the items are selected. And in the selection array, the items are not updated in a FIFO or LIFO way, they seem to be random or perhaps it depends on the value of the UUID but the point is it doesn't conserve the order in which they are added.
I considered using a stack to keep track of what is added, but the List + selection combination in SwiftUI doesn't appear to have built in methods to inform of new additions e.g. UUID 1234 has been added. I can thing of "not clean" ways to make it work like iterating through the whole selection Set every time selection.count changes and add the "new item" to the stack but I wouldn't want to come down to that.
So after some research, the List constructor that enables selection in .editMode does specify that the selection variable has to be a Set and nothing but a Set:
public init(selection: Binding<Set<SelectionValue>>?, #ViewBuilder content: () -> Content)
So I decided to implement my own array that keeps track of the selection order. I'll show how in case it helps anyone, but it is quite rudimentary:
#State var selectedItemsArray=[UUID]()
...
List(selection: $selection) {
...
}
.onChange(of: selection) { newValue in
if newValue.count>selectedItemsArray.count {
for uuid in newValue {
if !selectedItemsArray.contains(uuid) {
selectedItemsArray.append(uuid)
break
}
}
}
if newValue.count<selectedItemsArray.count {
for uuid in selectedItemsArray {
if !newValue.contains(uuid) {
selectedItemsArray.remove(at: selectedItemsArray.firstIndex(of: uuid)!)
break
}
}
}
}
I've a navigation and detail view that is sending a dictionary of date (key) and array of an struct (but it's not important the struct, it contains array of string and other stuff.
If I send a very very long dictionary, the app is freezing in the selected row and the detail appears once the List finished to load each record.
struct DetailView: View {
var selectedChat: [Date: [TextStruct]]? // you can try with [Date: [String]]?
var body: some View {
List
{
ForEach(self.selectedChat.keys.sorted(), id: \.self)
{ key in //section data
Section(header:
Text("\(self.selectedChat[key]![0].date)
{
ForEach(self.selectedChat[key]!, id:\.self) {sText in
// my ChatView(sText) ....
}
}
}
}
I've tried to load some rows at the start by adding this var
#State private var dateAndText: [Date: [TextStruct]] = [:]
substitute the code above (self.selectedChat) whit self.dateAndText and on .onAppear:
.onAppear {
if let chat = self.selectedChat {
let keysDateSorted = chat.allText.keys.sorted()
self.chatLeader = chat.chatLeader
for key in keysDateSorted.prefix(30) {
self.dateAndText[key] = chat.allText[key]
}
DispatchQueue.global(qos: .utility).async {
self.dateAndText = chat.allText
self.progressBarValue = 1
}
}
}
With this solution, once I push the row, immediately I can see the first 30 records, and it is ok, but I can't scroll until all the records are loaded. I know there is a way to load the array only if the user is scrolling at the end of the list, but I want to load all the list also if the user don't scroll at the end.
So, there is a way to load the list partially (like send and update the array each 100 records) and in async way (in order to don't freeze the display for bad user experience)?
You are almost certainly running into the issues described and fixed here by Paul Hudson.
SwiftUI is trying to animate all of the changes so if you use his hack around the issue it should work but you will lost all animations between changes of the list.
Apple devs responded to him and Dave DeLong who were discussing it on Twitter, they said that it is definitely an issue on their end that they hope to fix.
tldr of the article:
Add .id(UUID()) to the end of your List's initializer.
I'm using a NavigationLink inside of a ForEach in a List to build a basic list of buttons each leading to a separate detail screen.
When I tap on any of the list cells, it transitions to the detail view of that cell but then immediately pops back to the main menu screen.
Not using the ForEach helps to avoid this behavior, but not desired.
Here is the relevant code:
struct MainMenuView: View {
...
private let menuItems: [MainMenuItem] = [
MainMenuItem(type: .type1),
MainMenuItem(type: .type2),
MainMenuItem(type: .typeN),
]
var body: some View {
List {
ForEach(menuItems) { item in
NavigationLink(destination: self.destination(item.destination)) {
MainMenuCell(menuItem: item)
}
}
}
}
// Constructs destination views for the navigation link
private func destination(_ destination: ScreenDestination) -> AnyView {
switch destination {
case .type1:
return factory.makeType1Screen()
case .type2:
return factory.makeType2Screen()
case .typeN:
return factory.makeTypeNScreen()
}
}
If you have a #State, #Binding or #ObservedObject in MainMenuView, the body itself is regenerated (menuItems get computed again) which causes the NavigationLink to invalidate (actually the id change does that). So you must not modify the menuItems arrays id-s from the detail view.
If they are generated every time consider setting a constant id or store in a non modifying part, like in a viewmodel.
Maybe I found the reason of this bug...
if you use iOS 15 (not found iOS 14),
and you write the code NavigationLink to go to same View in different locations in your projects, then this bug appear.
So I simply made another View that has different destination View name but the same contents... then it works..
you can try....
sorry for my poor English...
I have a collection view with three different cells. Each of the cells contains a table view. So, there are three table views. I've set tags for each of them (from 1 to 3).
Now, on my view controller (I set it as the table view's data source when I dequeue collection view's cells) I call table view's data source method for the number of rows. To distinguish table views I check each one's tag. Here is the code for that:
func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
switch tableView.tag {
case 1:
if unitItems1 != nil {
return unitItems1!.count
} else {
return 0
}
case 2:
if unitItems2 != nil {
return unitItems2!.count
} else {
return 4
}
case 3:
if unitItems3 != nil {
return unitItems3!.count
} else {
return 4
}
default:
return 0
}
}
The problem is, when the first cell of the collection view is shown (with the first table view) it works fine. But when I scroll to the second cell, BOTH case 2 and case 3 get executed. After that, the second table view shows data as expected, but when I scroll to the third one, the method doesn't get called.
I can't figure out why two case statements get called one after another, while everything works fine for the first cell. If you have any ideas why this happens (or maybe, you could suggested a better way of checking table view's), I would appreciate your help.
Actually, the solution is quite simple. The reason of the problem was that collectionView's data source method was dequeueing all the cells one after another, even when they weren't on the screen. Consequently, tableView's inside of each cell were getting set, too. So, their data source method was getting called, hence the problem.
UICollectionView has a property called isPrefetchingEnabled. According to the documentation it denotes whether cells and data prefetching is enabled.
The documentation says:
When true, the collection view requests cells in advance of when they will be displayed, spreading the rendering over multiple layout passes. When false, the cells are requested as they are needed for display, often with multiple cells being requested in the same render loop. Setting this property to false also disables data prefetching. The default value of this property is true.
So, to solve the problem, described in the question, I set it to false as soon as my collectionView gets set.