I'm using a
LXReorderableCollectionViewFlowLayout library.
I had implement the required methods of the delegate, but one of methods called collectionView:canMoveItemAtIndexPath: is not called.
and i want to know how gesture methods are being called?
Seems this library is deprecated. You can use DraggableCollectionView
which is written by the same developer/team and easy to implement.
It serves the same purpose.
Make sure you have added draggable key of type boolean to YES in run time attributes of collection view.
and you have added DraggableView delegate to your interface for example.
Related
I'm not sure the title makes much sense, I'm having problems asking (and google searching) for a solution to the below question in a single coherent sentence.
I've created a custom class with the sole intention of subclassing it. I have a single method that I'll need to override when writing a new subclass. What I'm looking to do is, when I create a new file, and choose my custom class to subclass I'd like for the new implementation file to already have an empty version of the method. Similar to how an init method, or a drawRect method (when appropriate) is already in the implementation file when creating a new class.
Does that make sense?
You can define a template in your editor to do that. But there is no mechanism in Objective-C language that can do exactly that.
However, you could create a protocol with a required method and implement that (instead of subclassing an existing class), if that fits your need. This gives you a compile error if you forget to implement the method.
this question is about "style", because i think this is a very common problem and i'm looking for an elegant solution.
I have created some "advanced" UIView and i try to make them very customizable.
Usually i create the UIView structure inside a custom init method, but i need to know the value of all customizable parameter inside init method so sometimes i need a very long init method like:
initWithFrame:color:font:verticalspace:verylonglist:
I tried to use delegate design pattern but i need also to pass delegate inside init method.
My actual best solution is to leave empty the init method and move everything about layout inside a "configure" method. everytime i chance a property like background color or font i will call this method and i will rebuild the view.
I think there is a best way to solve this problem...
I'd be curious to see the code of UITableView Class, because with that class you can pass a delegate outside init method.
Check out something like a UIButton or UILabel. They both have tons of configurable aspects, however to simply create an instance of one of those objects, they need very little information.
In general, provide init methods that allow the consumer of your class to specify the least amount of information for the class to work.
If you do want to give the consumer a way to initialize the class with a bunch of values, consider using some sort of initWithDictionary: method that takes an NSDictionary of parameters. This keeps your method names short and allows the user to customize an arbitrary number of settings for your class.
You could also consider providing a way for the consumer to request an instance with some standard set of values. UITableViewCell, for example, has an initWithStyle:reuseIdentifier: method. The important part is the style - UITableViewCell provides several default styles like UITableViewCellStyleDefault and UITableViewCellStyleSubtitle.
I don't know if it is the standard/best practices way but I use a dictionary in cases like this and pass that to an initWithDictionaryinitializer. Would be possible too to create a class method that returns a 'default settings' type dictionary which can then be customized (and delegate set), so that not every param needs to be specified whenever the class is used.
So this may be a really dumb question, but is it possible to create a new delegate object at runtime without having to create an entire class interface/implementation for it? I basically wanna spawn off a new webview and make a delegate for it that just implements webViewDidFinishLoad so I can do some size manipulation then. It seems like a lot of overhead to create an entirely new class just for one method.
You can implement the delegate methods in your existing class. Just set the delegate to self and implement the methods you want.
Hey guys, I currently have a root table view which has a toolbar at the bottom and has labels and a refresh button within it, much like the Mail app's toolbar. This root table view controller obtains data from a server by allocating and initializing a DataUpdater class. Within this class are the NSURLConnection delegate methods that are called while communicating with the server.
As you can probably guess, I need to know when certain (delegate) functions are called within the DataUpdater class and the values of the parameters passed to these delegate functions so that I can update the labels on the toolbar accordingly (i.e. Connecting..., Updated, etc).
The problem I am having is determining how to notify the root table view controller of what is going on in these delegate methods. Would I use protocols, if so how? I have been skimming the documentation and don't quite see how I would get this effect. Or would you suggest I implement my program another way?
Thanks in advance!
A protocol is a kind of contract that says: I promise to provide the non-optional methods defined in the protocol, and maybe even the optional ones. It's purpose is like Java interfaces: to work around missing multiple-inheritence.
The delegate pattern in Objective-C normally works like this: you define a protocol, and then in your class, you define a variable like id<MyProtocol> myDelegate; and define a setter and maybe getter (either via normal methods, e.g. - (void)setDelegate:(id<MyProtocol>)aDelegate; or via properties.
Note that the delegate is not retained ! So if you work with a property, you need the assign option, not retain.
Now back in your class, you check whether myDelegate is nil and if not, you can directly call its non-optional methods. If you want to call an optional method, you first need to verify its presence via respondsToSelector:.
So if you decide to use the delegate pattern, you need to define a protocol, add that protocol to your root table view controller, implement the necessary methods there, and make sure to call [foo setDelegate:self]; or something similar to inform your other class that the root table view controller is the delegate. And of course implement the delegate calls in your class.
Edit:
An alternative might be to use NSNotifications, BTW. The advantage of notifications is that you can have multiple objects listen and react to them. The disadvantage is that you cannot (directly) pass values back. For example, you can define a delegate method that asks the delegate whether to do something or not. That's not possible with notifications, it's more like shouting into a room instead of having a one-to-one conversation.
DarkDust's answer about protocols is fine but I would like to add some things to it.
One underlying thing that is often forgotten when it comes to delegation is object ownership. When a program is running it creates a tree of objects. Its root object is the application delegate and for example it owns a navigation controller, which owns the individual view controllers, which own the view and the view owns its subviews and so on.
Often the question comes up: "Why is the delegate not retained, just assigned?" The problem is that if you send a message to a deallocated object the program crashes. So how do you make sure the delegate stays around? The answer is object ownership.
I give you an example: a UITableView and its data source which is the TableViewController which is nothing but a delegate. The TableViewController holds a reference with its view property to the UITableView, so it owns the TableView. That means when the tableView is alive there must also be its parent object present, which is the UITableView's delegate. So there is no danger that the delegate goes away somehow.
In the end it is again all about memory management.
Take home message is: think upfront about object ownership will make your program mode modular, easier to maintain and will lead to a looser coupling between individual objects.
Is a delegate in Objective-C defined as a class full of event listeners for an object?
A delegate is merely an object that another object can use to query or customize behavior; nothing more, nothing less. No event handlers involved. It is a pattern that is used to avoid the massive tangle of subclassing that you often see in other object oriented UI kits.
For example, instead of subclassing NSWindow to provide custom behavior on resize, you merely implement a few methods on a class somewhere and use an instance of that class as the delegate. Since such implementation is typically dependent on control or model layer information, it is much more natural to use a control layer class as the delegate, not subclass NSWindow, and not pollute the view layer objects with control layer functionality.
Under the covers, delegates are dead simple. When resizing, an NSWindow merely asks the delegate "Do you respond to the method windowWillResize:toSize: and, if it does, calls it at the right time; nothing beyond straight objc_msgSend() about it.
That may be one way to think of it, though not completely accurate. A delegate is responsible for handling callbacks for a given object. These may be events, they may not be.