This is one of your best videos ever! It never occurred to me that the slowdown was in the List comparison for animation and not in the sorting/filtering itself. Bravo!!
Love your videos. 👍🏻 Just one more thing to point out is memory. The Issue code started at 14mb then up to 64mb and stayed there. Never moved up/down for the repeated shuffles. Why the jump? The solved code it too started at 14mb but then increased 2mb every button click it seemed and never came down, ended at 24mb after your last click. Is that a system memory leak? I did noticed this week myself while testing, if I had a list of 2million “rows” of simple strings, the memory goes way up on startup. Is the swiftui list drawing all the “rows” and not doing like uikit, reusable rows for rows on display??
It is not really a fix but more of a trick. SwiftUI is really excellent to manage animations and effects. To make detailed views or manage fixed lists of items it is also very good. But when it comes to manage large/dynamic lists of items it lacks basic mechanisms such as infinite scroll. I hope with the next version of SwiftUI Apple we will add this kind of feature builtin.
Great video as always! However, won't adding id modifier with a new UUID every time the body function is evaluated create a new list even if there is another piece of state that's changed that's not the list state? And if so, will this cause any issues?
Hi Paul, that was an amazing tutorial. Thanks. Could you please help me with this issue. I am building an app where after several steps, on a button press, the user needs to be sent back to the main view. The solutions mentioned in stacktrace, using isdetaillink=false and dismissing each intermediate view is really not a clean code. Is there really no provision of popping to the first view in SwiftUI, like it used to be in objective-C with popToRootViewController?
On some devices I found this to make the app crash when navigating back to the list from another view (only observed on iPhone 7 & 11, works fine on the rest for me)..
I don't think this is workable solution for anything other than very simple cases like in your example. Mainly because it breaks MVVM. If you select a row and push to a new view, using your method, updates to the model will not be reflected in the pushed view. Also you will lose animations and scroll position. There are so many things that break in a proper MVVM design by doing this. I would strongly advise against using this approach.
please include the tags for time profiler to this video. As this explains small info about how to use instruments to find the delay. I really can't find nice videos that explains instruments options. So it may help someone.
This is a pragmatic fix, but it seems like the wrong thing to be doing. The diff logic is there for a reason. I would guess that this hack won't be needed after SwiftUI matures and some of its bugs are fixed.
Watch next: How to use neumorphism in SwiftUI - ua-cam.com/video/z3tJdxwlo_Y/v-deo.html
Questions? Comments? Tweet me @twostraws.
This is one of your best videos ever! It never occurred to me that the slowdown was in the List comparison for animation and not in the sorting/filtering itself. Bravo!!
Incredible series of Paul! thanks for everything you give to the community.
Is there a way to do this with a ForEach in a scroll view as opposed to with a List?
Love your videos. 👍🏻
Just one more thing to point out is memory.
The Issue code started at 14mb then up to 64mb and stayed there. Never moved up/down for the repeated shuffles. Why the jump?
The solved code it too started at 14mb but then increased 2mb every button click it seemed and never came down, ended at 24mb after your last click. Is that a system memory leak?
I did noticed this week myself while testing, if I had a list of 2million “rows” of simple strings, the memory goes way up on startup.
Is the swiftui list drawing all the “rows” and not doing like uikit, reusable rows for rows on display??
It is not really a fix but more of a trick. SwiftUI is really excellent to manage animations and effects. To make detailed views or manage fixed lists of items it is also very good. But when it comes to manage large/dynamic lists of items it lacks basic mechanisms such as infinite scroll. I hope with the next version of SwiftUI Apple we will add this kind of feature builtin.
but i want to do this in swift code in storyboard not in swiftui
Great video as always! However, won't adding id modifier with a new UUID every time the body function is evaluated create a new list even if there is another piece of state that's changed that's not the list state? And if so, will this cause any issues?
no. since the new list will be identical to the last list
Hi Paul, that was an amazing tutorial. Thanks. Could you please help me with this issue. I am building an app where after several steps, on a button press, the user needs to be sent back to the main view. The solutions mentioned in stacktrace, using isdetaillink=false and dismissing each intermediate view is really not a clean code. Is there really no provision of popping to the first view in SwiftUI, like it used to be in objective-C with popToRootViewController?
Thank you Mr Paul Hudson
This is brilliant. Thanks for sharing!
Exceptional! Thanks!
Love your videos! 🤩
On some devices I found this to make the app crash when navigating back to the list from another view (only observed on iPhone 7 & 11, works fine on the rest for me)..
I don't think this is workable solution for anything other than very simple cases like in your example. Mainly because it breaks MVVM. If you select a row and push to a new view, using your method, updates to the model will not be reflected in the pushed view. Also you will lose animations and scroll position. There are so many things that break in a proper MVVM design by doing this. I would strongly advise against using this approach.
Brilliant Video Paul!
Great explanation!!
Many thanks.
Please do you have a new book on SwiftUI ? If so can you send me link to buy
I have two books: Hacking with iOS and SwiftUI by Example, both of which cover SwiftUI extensively.
Link please?
Awesome explanation. Thanks!
Hit the “Film” setting in FCPX.
Thank you, Paul. That makes sense
please include the tags for time profiler to this video. As this explains small info about how to use instruments to find the delay. I really can't find nice videos that explains instruments options. So it may help someone.
Great info! Thanks!
it'd be nice if you can make videos on how to use each instruments tools,.
Welcome back in 2020 🍾
Waw that’s so cool
You saved our carrier
Thank you so much 😊
انت بتعمل ا هنا يا زميل :D
Thank you, sir.
Why is swift so slow? Obj. C was never this slow
This is a pragmatic fix, but it seems like the wrong thing to be doing. The diff logic is there for a reason. I would guess that this hack won't be needed after SwiftUI matures and some of its bugs are fixed.
perfect
Awsm content
Great
🤮🤮🤮🤮