Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rx_observe can be more intuitive as rx_observe<AnyObject?> #60

Closed
mbalex99 opened this issue Jul 17, 2015 · 5 comments
Closed

rx_observe can be more intuitive as rx_observe<AnyObject?> #60

mbalex99 opened this issue Jul 17, 2015 · 5 comments

Comments

@mbalex99
Copy link

rx_observe for KVO compliant objects is a little confusing

For example. I may want to store my apiToken in

  NSUserDefaults.standardDefaults().setObject(apiToken, forKey: "apiToken")

I should be able to subsequently observe this like so

 NSUserDefaults.standardUserDefaults().rx_observe("apiToken")
        >- subscribeNext{ myApiToken -> Void in
            println(myApiToken)
        } 

However the compiler doesn't understand this syntax.
It would be helpful if rx_observe was generically typed with

  rx_observe<AnyObject?>
@kzaher
Copy link
Member

kzaher commented Jul 18, 2015

Will try to figure out how to make this more user friendly. Have some ideas.

@kzaher
Copy link
Member

kzaher commented Aug 2, 2015

Hm, I've tried to play with some ideas, but I don't right now I don't see a way to trick Swift compiler into some kind of default return value.

@mbalex99 Do you have some ideas?

I've documented everything here https://github.com/kzaher/RxSwift/blob/master/Documentation/GettingStarted.md#kvo

Don't see we can do anything else. I've thought about adding rx_observeAnyObject -> Observable<AnyObject?> but it seems ugly, and it doesn't really solve the original issue.

Let me know what do you think.

@mbalex99
Copy link
Author

mbalex99 commented Aug 4, 2015

I think rx_observeAsAnyObject or yet rx_observeKVO

You can't easily cast generic's types. It's not good practice. So I think explicitly having rx_observeAsAnyObject makes it clear that you'll have to cast it yourself. It should be okay in the mean time.

Maybe an option is to transform the KVO object into a Variable then just make rx_observe as an alias to that value.

@kzaher
Copy link
Member

kzaher commented Aug 5, 2015

Hm,

I guess I can add rx_observeAsAnyObject(...) -> Observable<AnyObject?>, and write it in front of other overloads to allow users to more easily express that they want AnyObject as return type. I understand that people have different backgrounds, and I don't want to make more confusing then the problem requires.

I would really like to maintain current api because correctly unwrapping CGPoint and other structs is not so trivial as one might think :)

This is the code needed to correctly unwrap CGRect, it's not just as! :)

#if arch(x86_64) || arch(arm64)
let CGRectType = "{CGRect={CGPoint=dd}{CGSize=dd}}"
#elseif arch(i386) || arch(arm)
let CGRectType = "{CGRect={CGPoint=ff}{CGSize=ff}}"
#endif
// rx_observe + CoreGraphics
extension NSObject {
    public func rx_observe(keyPath: String, options: NSKeyValueObservingOptions = NSKeyValueObservingOptions.New | NSKeyValueObservingOptions.Initial, retainSelf: Bool = true) -> Observable<CGRect?> {
        return rx_observe(keyPath, options: options, retainSelf: retainSelf) as Observable<NSValue?>
            >- map { value in
                if let value = value {
                    if strcmp(value.objCType, CGRectType) != 0 {
                        return nil
                    }
                    var typedValue = CGRect(x: 0, y: 0, width: 0, height: 0)
                    value.getValue(&typedValue)
                    return typedValue
                }
                else {
                    return nil
                }
            }
    }

Do you think that adding rx_observeAsAnyObject(...) -> Observable<AnyObject?> would solve your concern?

Any other opinions/suggestions on this?

@bontoJR
Copy link
Contributor

bontoJR commented Sep 21, 2015

I guess this has been addressed in the development cycle of RxSwift 2.0.

I will close this issues, if anyone has something interesting to say about this, please consider opening a new issue referring to this one. :)

@bontoJR bontoJR closed this as completed Sep 21, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants