New answers tagged

3

A couple of thoughts: You are conceiving the band as being something derived from the frequency. While this may be technically correct, from a user perspective, you generally choose a band and then choose a frequency within that band. So, I might have a model that reflects this: typealias RadioFrequency = Decimal enum RadioBand { case am case fm } ...


2

As a general rule, you want to use the narrowest possible scope for all variables. We do this so that: The declaration is close to where we use it, making it easier to reason about why the variable exists. It minimizes the chance of unintended consequences where the variable is accidentally updated somewhere else. In this case, it’s so trivial that it ...


3

You are doing double force-unwraps, twice. This is really just asking for trouble 😬 As others have pointed out in their comments, there are a few edge cases you should guard against. Good thing is you can do both at the same time. Additionally, you should avoid using shortened names for your variables. In Swift, we usually type everything out. I've ...


2

You should separate concerns whenever possible. Since BLE & HTTP requests are quite different, you could write the following protocols: protocol Request { associatedtype Provider var provider: Provider { get } func execute() } protocol BLERequest: Request { typealias Provider = BLEProvider var code: UInt { get } var ...


1

Make use of Weak self inside closures to avoid memory issues. Also, provide memory referencing for optimal memory handling. Please update to the latest swift version


Top 50 recent answers are included