I need to check two values and set conditions based on these two values, return a NS_ENUM value.
From ReactiveCocoa github readme, I find this
RAC(self, createEnabled) = [RACSignal
combineLatest:#[ RACObserve(self, password), RACObserve(self, passwordConfirmation) ]
reduce:^(NSString *password, NSString *passwordConfirm) {
return #([passwordConfirm isEqualToString:password]);
}];
It check two value, the password and passwordConfirm together. I tried to modify it a bit to observe two BOOL property, it shows me "Incompatible block pointer types" error..
RAC(self, showButtonOption) = [RACSignal
combineLatest:#[ RACObserve(self, setting), RACObserve(self, billing) ]
reduce:^(NSSet *setting, NSSet *billing) {
if ([billing containsObject:kBillingExpired]) {
return DialerShowButtonPurchase;
} else if ([setting containsObject:kSettingEnableRecord]) {
return DialerShowButtonRecord;
} else {
return DialerShowButtonCall;
}
}];
I don't know what went wrong and what should be the right syntax to serve the purpose?
Well, let's see what the signature of that method is:
+ (RACSignal *)combineLatest:(id<NSFastEnumeration>)signals
reduce:(id ( ^ ) ( ))reduceBlock
You're trying to return an enum value, a primitive, from the reduceBlock -- which must have return type of id.
This is an annoying but sadly unavoidable aspect of ReactiveCocoa: you need to box. A lot. If you return #(DialerShowButtonPurchase) (etc), you'll actually be returning an NSNumber *, which is an id, so it'll compile.
The RAC macro will automatically unbox it so that showButtonOption doesn't need to be declared as an NSNumber *.
Related
I know that in the latest version of dart we can use if else statements inside the build method. Does anyone know if we can use also if else statement when we setting class parameters? I know I can do inline statement there but inline is a bit hard to read when there are multiple conditions
const int i = 0;
class Person {
// NewClass n = NewClass(a: i == 0 ? 'a' : 'b'); //<- inline statement working
NewClass n = NewClass(a: if(i == 0) 'a' else 'b'); //<- if statement doesn't
}
class NewClass {
final String a;
const NewClass({this.a});
}
Edit:
Basically in my case I've got an TextField widget where I set its's type parameter from enum (Type.text, Type.numeric...) According to this parameter I want to set The textField parameters (textCapitalization, maxLength and so on)
As per your comment, you are already creating an enum for specifying the type of the fields.
enum Type {text, numeric}
Now for specifying the properties of that particular type, you can add an extension on this enum, as shown below:
extension TextFieldProperties on Type {
int get maxLength {
if (this == Type.text) {
return 10;
}
return 12;
}
}
So in your field class you already have a type defined, you can use that type variable to get the properties of that particular type of field.
Type type = Type.text;
print(type.maxLength); // Will print 10
type = Type.numeric;
print(type.maxLength); // Will print 12
Note: It will work only in Dart 2.7 and above
You want the conditional expression (?:), not the conditional statement or literal entry (if), as you have already discovered.
The reason if doesn't work is that if only works as a statement or as a collection literal entry. It doesn't work in arbitrary expressions.
The reason for the distinction is that the if syntax allows you to omit the else branch. That only makes sense in places where "nothing" is a valid alternative. For a statement, "doing nothing" is fine. For a collection, "adding nothing" is also fine.
In an expression context, you must evaluate to a value or throw. There is no reasonable default that we can use instead of "nothing", so an if is not allowed instead of an expression.
Doesn't work because this syntax doesn't exist in Dart. The only way to do what you would like to do is to use the ternary operator.
If you try it in the DartPad you will get an error.
I suggest you to use a function to return the right value.
Is it bad practice to change my getter method like version 2 in my class.
Version 1:
public String getMyValue(){
return this.myValue
}
Version 2:
public String getMyValue(){
if(this.myValue == null || this.myValue.isEmpty()){
this.myValue = "N/A";
}
return this.myValue;
}
I think it is actually quite a bad practice if your getter methods change the internal state of the object.
To achieve the same I would suggest just returning the "N/A".
Generally speaking this internal field might be used in other places (internally) for which you don't need to use the getter method. So in the end, the call to foo.getMyValue() could actually change the behaviour of foo.
Alternatively, the translation from null to "N/A" could be done in the setter, i.e. the internal value could be set to "N/A" if null is passed.
A general remark:
I would only add states such as "N/A" if they are expected by some API or other instance relying on your code. If that is not the case you should rely on the standard null types that are available to you in your programming language.
In my opinion, unless you are doing lazy-loading (which you are not in that case), getters should not change the value. So I would either:
Put the change in the setter
public void setMyValue(String value) {
if(value == null || value.isEmpty()){
this.myValue = "N/A";
} else {
this.myValue = value;
}
}
Or make the getter return a default value if value not set properly:
public String getMyValue() {
if(this.myvalue == null || this.myvalue.isEmpty()){
return "N/A";
}
return this.myValue;
}
In the case of lazy-loading, where I would say that changing your members in a getter is fine, you would do something like:
public String getMyValue() {
if (this.myvalue == null) {
this.myvalue = loadMyValue();
}
return this.myValue;
}
No. You're doing two things here. Getting and setting.
Yes. It's a bad practice.
Why?
When the value is set (in a constructor or setter method), it should be validated, not when a getter method is called. Creating a private validate* method for this is also a good idea.
private boolean validateThisValue(String a) {
return this.myValue != null && !this.myValue.isEmpty();
}
public void setThisValue(String a) {
if (validateThisValue(a)) {
this.myValue = a;
}
else {
// do something else
// in this example will be
this.myValue = "N/A";
}
}
And, in the getter method, never ever change the state of the object. I have worked on some projects, and the getter often must be made const: "this method cannot change internal state".
At least, if you do not want to complicate things, in the getter method, you should return "N/A" rather than change internal state and set myValue to "N/A".
I usually define a specific getter.
Never alter original getter:
public String getMyValue(){
return this.myValue
}
And create a specific getter:
public String getMyValueFormatted(){
if(this.myvalue == null || this.myvalue.isEmpty()){
return "N/A";
}else{
return this.myValue;
}
}
I think it's better to initialize this.myValue = "N/A". And subsequent calls to setMyValue should modify the this.myValue according to your business conditions.
The getMyValue shouldn't modify in any way this.myValue. If your needs are to return a certain value, you should return that value (like "N/A") and not alter this.myValue . Getters must not modify member's value.
I would change better the setter method so, if the value is null or empty, the N/A is assigned to the attribute. So, if you use the attribute in other methods inside the class (v.g. toString()) you will have the intended value there.
Alternatively, change the setter method to launch an exception when the value being set is not right, so the programmer is forced to improve its handling prior to setting the value.
Other than that, it is ok.
I do feel this is a bad practice unless and until you explain the reason why it is so necessary for you modify the object inside the getter method instead of doing it inside the setter method.
Do you feel this cannot be done for some reason? Could you please elaborate?
Do what ever you like. After all getters and setters are just another public methods. You could use any other names.
But if you use frameworks like Spring, you are bound to use those standard names and you should never put your custom codes inside them.
absolutely yes, it's a bad pratice.
Imagine you communicate accross network with a third party (remoting, COM, ...), this will increase the round-trip and then hit application performance.
A setter could modify as part of validation, but a getter should return the value and let the validation be done by the caller. If you do validate, then how should be documented.
This actually highly depends on the contract you want to enforce with your get()-method. According to design-by-contract conventions the caller has to make sure that the preconditions are met (which means doing a validation in a setter method often is actually bad design) and the callee (I do not know if that's the correct english term for that, i.e., the called one) makes sure that the post conditions are met.
If you define your contract so that the get()-method is not allowed to change the object then you are breaking your own contract. Think about implementing a method like
public isValid() {
return (this.myvalue == null || this.myvalue.isEmpty());
}
Advantage of this approach is that you do not have to check wether the return of your get() is "N/A" or something else. This also can be called before calling set() to validate that you do not insert illegal values into your object.
If you want to set a default value you should do that during initialization.
State changes in getters should be a hanging offence. It means that client code must be careful about the order in which it accesses getters and setters and to do this it must have knowledge of the implementation. You should be able to call the getters in any order and still get the same results. A related problem occurs when the setter modifies the incoming value depending on the current state of the object.
You can use some value holder for this purpose. Like Optional class in guava library.
I saw this post: How to sort an NSMutableArray of objects by a member of its class, that is an int or float
And had something similar, but I wasn't sure how it all works and was hoping for some guidance. I have an Array of Marker objects that have a Type ivar that takes on values of 0, 1, 2. I want to have a check box that says what to order by, 0, 1, or 2.
I started off by trying to doing something similar in my own method:
- (NSComparisonResult)Type:(id)otherObject {
if ([self Type] > [otherObject Type]) {
return NSOrderedAscending;
}
else if ([self Type] < [otherObject Type]) {
return NSOrderedDescending;
}
else {
return NSOrderedSame;
}
}
In my .h file:
NSInteger _type;
#property NSInteger Type;
I get the two warnings:
Ordered comparison between pointer and integer ('id' and NSInteger')
Method - Type not found (return type defaults to 'id')
I don't think I understand what is happening when you call the sort method. Thanks.
What happens if you're explicit about the input type being a YourObjectType * (or whatever your object is called) rather than id? To be completely safe you should check the type of the incoming object anyway (as it may not respond to 'Type' at all, or may return something else with the same selector), so you'd end up with:
- (NSComparisonResult)Type:(YourObjectType *)otherObject {
if(![otherObject isKindOfClass:[YourObjectType class]]) return NSOrderedSame;
if ([self Type] > [otherObject Type]) {
return NSOrderedAscending;
}
else if ([self Type] < [otherObject Type]) {
return NSOrderedDescending;
}
else {
return NSOrderedSame;
}
}
I'm basically making the same guess as highlycaffeinated, that the compiler is failing to correctly determine the return type of 'Type', but my guess is that it's because of an incorrect compiler prediction about the incoming object.
To explain the whole process:
When you ask NSArray to sortUsingSelector, it'll apply some sorting algorithm that requires it to be able to compare any two objects within it. When it needs to compare two objects, it'll send the selector you supplied, then use the result you return — so with Ascending/Descending you're specifying the order that the two objects would appear in if correctly sorted.
For example, if you had an NSArray filled with objects of type SillyObjectType and you issued a sortUsingSelector:#selector(compare:) then NSArray would apply some unspecified sorting algorithm that involved sending the selector compare: to instances of SillyObjectType. Each SillyObjectType is being asked "should you come before, after, or at an equal place to this other object?". It replies with NSOrderedAscending, Descending or Same.
This is one place where ObjC's dynamic dispatch gives a slightly different way of writing the thing than you'd use in e.g. C++. The selector will be sent to the objects in the array, so you should implement it on those objects. In each case the normal rules apply, so self will be that instance of that class.
It looks like you've defined Type as an ivar and not a property, therefore it won't be visible in otherObject. Expose it as a property and your comparison should work.
Is there a return type for "any primitive" similar to the way you can use NSObject as the return type for any object? I tried using id, but the compiler was giving me an error that it was trying to convert a primitive to a reference.
Here's what I'm trying to do. :
-(void)setObject:(NSObject*)obj forKey:(NSString*)key {
[sharedInstance.variables setObject:obj forKey:key];
}
-(NSObject*)getObjectForKey:(NSString*)key {
return [sharedInstance.variables objectForKey:key];
}
-(void)setValue:(???)value forKey:(NSString*)key {
[sharedInstance.variables setValue:value forKey:key];
}
-(???)getValueForKey:(NSString*)key {
return [sharedInstance.variables valueForKey:key];
}
The alternative that I have though of is to use separate methods (getIntForKey, getFloatForKey, etc.) to access the values.
1) Read Key-Value Coding Article in XCode documentation - all answers are there
2) There's an object NSValue, which resembles your "NSObject". NSValue can store plain-old-data inside itself.
PS
"Scalar and Structure Support
Key-value coding provides support for scalar values and data structures by automatically wrapping, and unwrapping, of NSNumber and NSValue instance values.
Representing Data as Objects
The default implementations of valueForKey: and setValue:forKey: provide support for automatic object wrapping of the non-object data types, both scalars and structs.
Once valueForKey: has determined the specific accessor method or instance variable that is used to supply the value for the specified key, it examines the return type or the data type. If the value to be returned is not an object, an NSNumber or NSValue object is created for that value and returned in its place.
Similarly, setValue:forKey: determines the data type required by the appropriate accessor or instance variable for the specified key. If the data type is not an object, then the value is extracted from the passed object using the appropriate -Value method."
I would have thought id is the perfect candidate here too... could this just be a casting issue you're seeing?
i.e. the id implicitly implies a pointer so in my mind I see id as an objective c equivalent to the c void*
In other words where you have a NSObject* you could replace this with id such as
-(NSObject*)myMethod1
{
}
so can be done for any returned primitive with
-(id)myMethod1
{
}
i.e. not an id*
Also I expect this was just a copy/paste thing but incase it also causes issues
-(void)setValue:(???)value forKey:(NSString*)key {
[sharedInstance.variables setValue:num forKey:key];
}
should probably be
-(void)setValue:(???)value forKey:(NSString*)key {
[sharedInstance.variables setValue:value forKey:key];
}
I eventually worked through this. The ultimate solution was to have separate accessor/mutator methods per type. So now I have setIntForKey, setBoolForKey, getIntForKey, getBoolForKey, etc. The drawback is quite obvious, in that I can't call one method to set values and another to retrieve them. The advantages are numerous, however. Because the compiler knows what object or primitive type the method is expecting at compile time, I gain compile time checking for all of these methods. Additionally, I don't have to worry with casting the retrieved values to their primitive types (obviously the returned NSObjects are a different story).
i'm an objective-c newcomer.
im trying to compare a core data entity attribute value and having trouble with the syntax.
i just want to know the best way way to write the if statement to compare values.
in this example, the someAttribute attribute is a boolean, and its default is NO.
NSString *myValue = [NSString stringWithFormat:#"%#", myObject.someAttribute];
if ([myValue isEqualToString:#"1"]) {
// do something
} else {
// do something else
}
is this the right way? i've tried other flavors, like below, but the results aren't accurate:
if (myObject.someAttribute == 1) {
if (myObject.someAttribute) {
If you look in the generated header for this entity, there's a good chance that the actual type of the property is not BOOL, but NSNumber, which is how Cocoa boxes numeric types into objects. Assuming I'm right, you might try:
if ([myObject.someAttribute boolValue]) { ... }
If your attribute is of BOOL type, this code will work fine
if(myObject.someAttribyte){
//so smth if someAttribute is YES
}
You can't convert a BOOL directly to a string.
Predicates are the preferred method of comparing CoreData values. It's more complicated to start but works better in the long run. See NSPredicate programming guide