Conversation
| ); | ||
| inputPaths = ( | ||
| "${PODS_ROOT}/Target Support Files/Pods-BlockEQ/Pods-BlockEQ-frameworks.sh", | ||
| "${SRCROOT}/Pods/Target Support Files/Pods-BlockEQ/Pods-BlockEQ-frameworks.sh", |
There was a problem hiding this comment.
Yeah - it's weird that this would change. No reason to commit it along with the PR.
Does your project build with them being the old format: ${PODS_ROOT}?
I recently updated our podfile to specify cocoapods version 1.6.0 beta 2 format, so I'm wondering if the format for environment variables changed between the last release and the one we're using now...
| @@ -0,0 +1,8 @@ | |||
| <?xml version="1.0" encoding="UTF-8"?> | |||
| } | ||
|
|
||
| @IBAction func textFieldEditingDidChange(_ sender: Any) { | ||
| let text = sendAddressTextField.text! |
There was a problem hiding this comment.
I like to explicitly avoid force-unwrapping values. Whenever a nil value is unwrapped like this, the app will be forced to crash. For something like a text field having no text, it's not worth it.
Usually force unwrapping is used when you need to tell the compiler that you are absolutely sure the value you're about to use will always be present, like if you were to do the following:
if textField.text != nil {
print("I'm sure 100% this is not nil: \(textField.text!)")
}But Swift gives nicer tools to handle things like this, such as:
guard let text = textField.text else { return }
// Now we either return from this method if there's no text, or everything
// below this line has a locally scoped, non-optional `text` constant you can use.There was a problem hiding this comment.
I would rather use the last way of handling nulls. Developer should never be forcing the no-null using '!'.
|
|
||
| @IBAction func textFieldEditingDidChange(_ sender: Any) { | ||
| let text = sendAddressTextField.text! | ||
| if (text.contains("*") && text.contains(".com")) { |
There was a problem hiding this comment.
This would be better as an addition to StellarAddress.
See
That object has rules that takes an optional string (so you can directly pass the value of a text field into it), and constructs a usable Stellar address from it.
I've been planning to use it to be able to determine if an address is raw, or a federated address with the
public enum AddressType { ... }object. In that case, this federation logic can be re-used throughout the app by checking the address 'kind':
public var kind: AddressType {
/* Your logic to determine if an address is federated or not, returning .normal or .federated */
}| @IBAction func textFieldEditingDidChange(_ sender: Any) { | ||
| let text = sendAddressTextField.text! | ||
| if (text.contains("*") && text.contains(".com")) { | ||
| Federation.resolve(stellarAddress: text) { (response) -> (Void) in |
There was a problem hiding this comment.
I try to keep this type of logic at the coordinator level so that my view controllers can stay dumb and can be updated at any time with any data. That way, I don't need to worry about asynchronous code in my view updating.
It requires a lot more delegation back to the parent coordinator, but is worth the testability.
There was a problem hiding this comment.
You might do something like: delegate?.requestedAddressLookup(self, address), and then have a delegate implementation method that updates the appropriate text field with the account ID.
| PODFILE CHECKSUM: a20b2a55a46db8619698bfc60bab052b3593e01e | ||
|
|
||
| COCOAPODS: 1.6.0.beta.2 | ||
| COCOAPODS: 1.5.3 |
There was a problem hiding this comment.
Yeah here we go... It looks like all the pod file and project file changes are coming from the fact you're using cocoapds 1.5.3, and I've bumped us up to 1.6.0. Getting up to the beta release version and re-running pod install should resolve these issues.
ndizazzo
changed the title
2 participants
No description provided.