New answers tagged swift
1
They're not being too nit-picky. DataTask's completion handler will return nil for data when it couldn't get the data, like when the network is offline. Force unwrapping 'data' means you deliberately crash the application when that happens. That would be bad.
"separate the business logic from the view controller": They expect you to make a data ...
-1
updated my code to use a deferent approach and apply collection pipeline
update my code
I use collection pipeline refactoring for more information about the
topics look
https://martinfowler.com/articles/refactoring-pipelines.html
I use stride function instead of filter to generate even Integer array
Sidenote: I don't know if I will save a couple of ...
1
Code review:
1. use a guard statements to transform optional values to values.
private var x: Int?
private var y: Int?
@IBAction func startButtonPressed(_ sender: UIButton) {
guard let numberOfRooms = selectedRooms.text, !numberOfRooms.isEmpty else {
return selectedRooms.placeholder = "type it, dude"
} //if user typed ...
1
Yes, force unwrapping is ok if you're 100% sure the value won't be nil, but this should only be used when, for code structure reasons, you can't do otherwise. The thing is, most of the times, you can do otherwise, so using force-unwrapping should rarely happen. In your case, I think most of it can be refactored.
For example: why are your variables x and y ...
1
Your code is perfectly fine. Just a couple of comments:
It is bad-to-impossible to have any internal state in a View.
Actually SwiftUI was designed to handle state changes directly in a view. For simple cases you can easily do:
struct PageIndicator: View {
@State private var currentPage = 0
let numPages: Int = 5
private let spacing: CGFloat = ...
2
I need to ask a question when I break up my player into usable
components. How should I take this approach
The idea is to break a long and not so readable code into smaller parts. Also, each individual part needs to access variables etc.
For this you can use a private extension (unless it's in another file, then skip private):
struct ContentView: View {
...
0
Yes, this isn't the canonical way. My solution is to not use Self and to instead focus on shared.
That is:
protocol ImageCacheProtocol {
func getCache() -> NSCache<AnyObject, UIImage>
}
final class ImageCache: ImageCacheProtocol {
var cache: NSCache<AnyObject, UIImage> = NSCache<AnyObject, UIImage>()
static var shared = ...
1
It sounds like you're on the right track, but the cache key needn't be so specific. Unless you're storing to the same cache/dictionary as other code is using, there won't be collisions.
Since Fibonacci numbers build on the previous 2 numbers, recursion is a natural solution, but obviously gets slower for larger numbers. This post details a recursive ...
Top 50 recent answers are included
