I'm working on a class similar to UIControl and I would replicate some of its behaviours.
I wonder how Apple has implemented the UIControl structure that stores the relations between actions, targets and UIControlEvents.
Looking at the UIControl class I saw that UIControlEvents (documentation) defines a list of options that we can use to create a bit mask.
In my opinion there is something like a dictionary that uses as keys the event type and stores structure with the target and selector as value.
I can create something similar and probably it works :P but I'd like to have your opinions to
be sure to move head straight for the right direction.
For example... the first big doubt that I have is how can I convert a UIControlEvent type into a valid key for a dictionary? (or any other structure if you think that the dictionary is not the solution) have I to convert it to an NSString??? It seems a buggy solution.
Related
I am trying to call a method of a class that I only know by name as a String. Now therefore I would need a ClassMirror of that class that allowes me to instantiate an instance. However, creating ClassMirrors seems to be only possible by entering a type using reflectClass(Type) or by passing an already existing instance of that class into reflect(dynamic). So these aren`t helping if I only have a String.
In Java you can do this pretty easily, by calling Class.forName(String). Then you would get a Constructor instance, make it accessibly and call it.
Does anyone know if this is even possible in dart? What seems weird is that once you have a ClassMirror you can access fields and methods by passing symbols, which can be created by Strings.
You can put a specific list of strings to map to a specific list of closures to create a new object with specific parameters.
But you can't get a reflection without using dart:mirrors, which is being deprecated, and also had a negative impact on tree shaking to get the payload size down.
In general, you're invited to look at the package:reflectable to achieve most of what you'd want out of dart:mirrors, using source-to-source builders.
When I'm looking for a method of an object that I don't know, I used Xcode's autocompletion. The problem for me is that there are tons of methods that appear and most of them are inherited methods that make it harder for me to find methods proper to the object I'm working on.
Is there a way (other than going to the declaration code of the object) to make it clearer like an option to sort the methods first by inherited/locals and then alphabetically?
i'm starting with Swift by developing a simple application with a tableView, a request to a server and a few things more. I realized that every method inside UITableViewDelegate protocol is named in the same way (i guess it might be the same with other protocols) and the differences are made by changing the parameters passed to those methods (which are called "tableView" by the way).
I was wondering why Apple would do something like this, as it's a bit messy when i try to implement method from this protocol, as i can't start typing "didSele..." just to autocomplete with "didSelectRowAtIndexPath"; instead i have to type "tableView" to get a list of all available methods and manually search for the one whose second parameter is "didSelectRowAtIndexPath".
Everything's working fine, but just trying to know WHY could this be done this way.
Thank you so much in advice :)
PS: There's a screenshot about what i'm saying:
Swift is designed to be compatible with Objective-C. After all, almost all existing OS X and iOS APIs are in Objective-C and C (with a bit of C++ code here and there). Swift needs to be able to use those APIs and thus support most Objective-C features one way or the other. One of the most important features of Objective-C is how method calls are made.
For example, in C, a function with 3 arguments is called like this:
foo(1, "bar", 3);
You don't know what the arguments are supposed to be. So in Objective-C, the arguments are interleaved with the method name. For example, a method's name might be fooWithNumber:someString:anotherNumber: and it would be called like:
[anObject fooWithNumber:1 someString:#"bar" anotherNumber:3];
Swift now tries to be compatible with this Objective-C feature. It thus supports a form of named arguments. The call in Swift would look like:
anObject.foo(number:1, someString:#"bar", anotherNumber:3)
Often Swift method definitions are written so that you don't need to explicitly name the first argument, like:
anObject.foo(1, someString:#"bar", anotherNumber:3)
If you look up the UITableViewDelegate protocol documentation and select Objective-C you can see that all of these methods start with tableView: to designate the sender, but from then on they are very different. The list you've cited is the result of the conversion from Objective-C to Swift naming convention.
It is just naming conventions. It is the same in Objective-C. You can have a look to this page. Without these conventions it would be a complete mess.
The method name is not only the first word but also the public names of the parameters.
E.g. it the method name is not tableView() but tableView(_:didSelectRowAtIndexPath:).
I am aware (and have found several posts here on SO) that one cannot pass along any additional parameters for a selector. For example whenever someone taps on my image view, I have the following taking place:
imageView.addGestureRecognizer(UITapGestureRecognizer(target: self, action:Selector("tapImage:")))
This works correctly, and many solutions say that if you wish to pass a parameter, simply assign the tag of the view to something, and then reference that as the sender within the tapImage function. The thing is i'm actually using the tag value for something else, so would need to somehow store another value somewhere else.
What are some recommended ways I can pass a true/false (or 0/1) value into my TapGestureRecognizer action "tapImage" such that I can evaluate an expression? I also need to pass a collection of classes as well.
I think the only solution is to use a different selector in this case (for example "tapImageFunctionA" vs. "tapImageFunctionB" which is fine, but before I go this route is there another way? Even with this way, I would need to access a collection of objects. Maybe I set a global variable in the view controller and access it that way?
Thanks so much!
Use some tag formatting - for example bitmasks, like 16 lower bits for one kind of info / 16 higher bits for second kind of info
Use associative references. Here's some answers on these on stack overflow: How do I use objc_setAssociatedObject/objc_getAssociatedObject inside an object?, Any gotchas with objc_setAssociatedObject and objc_getAssociatedObject?.
Personally i would use the first solution with tags, to reduce performance overhead on associative references (it's VERY minor, but it exists). Also, tags seems like more "programming" solution, when associative references - more technical and implementation-dependent.
I'm currently working on a Rails project, and have found times where it's easiest to do
if object.class == Foo
...
else if object.class == Bar
...
else
...
I started doing this in views where I needed to display different objects in different ways, but have found myself using it in other places now, such as in functions that take objects as arguments. I'm not precisely sure why, but I feel like this is not good practice.
If it's not good practice, why so?
If it's totally fine, when are times that one might want to use this specifically?
Thanks!
Not sure why that works for you at all. When you need to test whether object is instance of class Foo you should use
object.is_a? Foo
But it's not a good practice in Ruby anyway. It'd much better to use polymorphism whenever it's possible. For example, if somewhere in the code you can have object of two different classes and you need to display them differently you can define display method in both classes. After that you can call object.display and object will be displayed using method defined in the corresponding class.
Advantage of that approach is that when you need to add support for the third class or a whole bunch of new classes all you'll need to do is define display method in every one of them. But nothing will change in places where you actually using this method.
It's better to express type specific behavior using subtyping.
Let the objects know how they are displays. Create a method Display() and pass all you need from outside as parameter. Let "Foo" know to display foo and "Bar" know how to display bar.
There are many articles on replacing conditionals with polymorphism.
It’s not a good idea for several reasons. One of them is duck typing – once you start explicitly checking for object class in the code, you can no longer simply pass an instance of a different class that conforms to a similar interface as the original object. This makes proxying, mocking and other common design tricks harder. (The point can be also generalized as breaking encapsulation. It can be argued that the object’s class is an implementation detail that you as a consumer should not be interested in. Broken encapsulation ≈ tight coupling ≈ pain.)
Another reason is extensibility. When you have a giant switch over the object type and want to add one more case, you have to alter the switch code. If this code is embedded in a library, for example, the library users can’t simply extend the library’s behaviour without altering the library code. Ideally all behaviour of an object should be a part of the object itself, so that you can add new behaviour just by adding more object types.
If you need to display different objects in a different way, can’t you simply make the drawing code a part of the object?