When I use a prototype table view, I always have to conform to the protocol TableViewDataSource. I always forget what methods I need to implement, so I have to look at the source of the protocol every time. This is really time consuming.
I think Xcode must have a feature that automatically implements the needed methods for you, right? Just like IntelliJ IDEA, Eclipse, and Visual Studio.
I want to know where can I find this feature. If there's isn't, is there a workaround for this? At least I don't have to open the source code of the protocol each time I conform to it.
If you don't understand what I mean, here's some code:
I have a protocol
protocol Hello {
func doStuff ()
}
When I conform to it,
class MyClass: Hello {
}
I often don't remember the names of the methods that I need to implement. If Xcode has a feature that turns the above code, into this:
class MyClass: Hello {
func doStuff () {
code
}
}
Now you understand what I mean? I just want to ask where to find such a feature.
Xcode 9 : you can add missing Protocol Requirements by add new shortcut to your Key Bindings Set
From the top Xcode menu (top left) choose Preferences.
Choose Key Binding.
Search about protocol. you will find Command called Refactor -> Add Missing Protocol Requirements
Press on Key column then add your shortcut. ex: cmd + shift + M
Now you can add missing Protocol Requirements by clicking on class name name (or his extension) then press your shortcut
Well if i understood your problem then here is a workaround:
try to define methods with protocol as prefix like here hello then you'll not have to remember the methods just start typing protocol name and XCODE will prompt you with all available methods see here:
And if you want autocomplete protocol try
Snippets
Xcode 9, takes care of implementation of mandatory methods of Swift Datasource & Delegates.
Look at these snapshots, with example of UICollectionViewDataSource:
Indicating warning to implement protocol methods:
By clicking on 'Fix' button, it has added all mandatory methods:
Very similar to Amjad's post, Xcode 9/10 brings the functionality to add missing protocol requirements right from within the code editor.
Just "right click" on the class name: "Refactor" --> "Add Missing Protocol Requirements"
Xcode won't do it for you.
If you look at the documentation for the protocol, it's clearly marked which functions you have to implement:
https://developer.apple.com/library/ios/documentation/UIKit/Reference/UITableViewDataSource_Protocol/
Related
Among the new features announced in Xcode 8, we can see
"Auto-generate Quick Help documentation" :
Is this the end of manual code documentation like we can learn on this article from NSHipster ?
Can someone outline the pros and cons of this new feature ? Does it replace tools like Jazzy ?
I couldn't find more information about the new feature.
This refers to Xcode 8 (and later) feature, where you can select a method like this:
func foo(bar: Int) -> String { ... }
... and then press ⌘+option+/ (or choose “Structure” » “Add documentation” from Xcode's “Editor” menu) and it will generate the following comments template for you:
/// <#Description#>
///
/// - parameter bar: <#bar description#>
///
/// - returns: <#return value description#>
It just facilitates the writing of documentation for Quick Help.
Note, while this behavior has changed a bit over time, Xcode can be particular about where the cursor must be when you attempt to do this. For example, the cursor has to be somewhere in the function name, foo in my above example, for this to work. Or just double click on the function name and then press ⌘+option+/
You asked whether this feature replaces tools like Jazzy.
No, it doesn’t replace Jazzy or similar tools. Amongst other things, Jazzy creates stand-alone HTML documentation from this inline documentation. So, it is simply a question of whether you need these stand-alone outputs from Jazzy for any reason. If so, use Jazzy (or similar tool) in conjunction with this integrated documentation. If not (i.e., you are only looking for documentation from within the Xcode IDE), then Jazzy is not needed.
This is most likely related to the fact that ALL hotkeys with a '/' don't work in the current XCode 8 build, if your keyboard requires to press shift to get it.
I.e. on the german keyboard the '/' is shift+7, pressing alt+cmd+shift-7 doesn't do a thing. If you assign i.e. cmd+shift+opt+d, it works just fine.
The shortcut '///', which unfortunately also doesn't work right now, is probably due to the old XCode plugin VVDocumenter, which used exactly this shortcut.
Great feature, lousy QA on the Apple side.
Having issues testing out the custom long look notification on the apple watch simulator. The debugger log this error:
WatchKit Extension[5230:156324] Took too long to show custom notification. Falling back to static.
How to resolve this issue?
I had exactly this problem with the default code set up by Xcode. I didn't do any operations inside didReceiveRemoteNotification, but the error still occured.
Turns out the reason it failed was that my WKUserNotificationInterfaceController subclass was not connected to the Dynamic interface Controller in my storyboard file.
Solution:
Go to the storyboard file for your watchkit app.
Click on your Dynamic Interface controller
Click the identity inspector (middle tab in the right pane)
In the Class field, select your
WKUserNotificationInterfaceController subclass (xcode had named mine
NotificationController)
Voilà!
I had the same issue before.
Inside didReceiveRemoteNotification, are you calling completionHandler(WKUserNotificationInterfaceTypeCustom); ?
Also, what are you doing inside that function? If takes too much time, it will show by default the static notification:
"Use the static notification interface to define a simple version of
your custom notification interface. The purpose of a static interface
is to provide a fallback interface in the event that your WatchKit
extension is unable to configure the dynamic interface in a timely
manner"
Try giving your custom class name as NotificationController. Xcode take it as WKUserNotificationcontroller. It worked for me.
This will happen if you take too long in your handler to setup. If it takes too long, the watch will default to the static notification.
Be sure you are calling the correct completion block:
completionHandler(WKUserNotificationInterfaceTypeCustom);
When calling the completion handler block, if you want WatchKit to display your static interface instead, specify the WKUserNotificationInterfaceTypeDefault constant.
Reference:
https://developer.apple.com/library/ios/documentation/General/Conceptual/WatchKitProgrammingGuide/CustomzingthePushNotificationInterface.html
In my case the problem was that the created WatchKit Extension was configured as Swift code, while my entire project was in Objective-C.
The Dynamic Interface never show up, always switching to the Static one printing the error of this post in the console. Once I changed the WatchKit Extension to Objective-C everything worked perfectly.
If you use a real watch, try turn off "Wrist Detection" in "Watch" -> "General".
I have a method in some class and i would like to see exactly where it is being used. Compared to Java and Eclipse you can simply tell it to show all the references and even a call hierarchy of a method. Is there anything similar in Xcode?
I know that Objective-C does not follow the same ways of identifying method signature as Java does (i.e. there is no method to a class, just a bunch of selectors mapped to an id at runtime), so i'm having a hard time trying to figure out how Xcode could even accomplish this.
Look here:
There is no equivalent menu or context menu.
In addition to callers you can access callees, superclasses, etc.
If you don't use Ctrl-1 for Spaces you can access that menu with it.
Note that you need to use the Standard or Assistant Editor:
Callers and callees are not shown if the Version Editor is selected:
Your best bet is likely string searching, but realize that you can use patterns (click the little magnifying glass in the search bar in the file browser pane).
You've hinted at one of the reasons it's so hard to do otherwise. Objective-C's runtime allows many different ways of finding and executing code.
Background: Up until Xcode 4.2, new projects created using any of the templates would contain a MainWindow.xib and therefore pass nil as the fourth argument of UIApplicationMain(). Starting in Xcode 4.2 all the templates instantiate the application delegate by passing the class string as the fourth argument and do not build the application's window in a xib.
It is trivial to accomplish this setup in 4.2, and of course it works as expected: create xib setting File's Owner to UIApplication and wire up the delegate, specify it in Info.plist, nil fourth argument in main().
Question: Why is Apple encouraging instantiating the application delegate and building the UIWindow in code now instead of the "old way?" What are the benefits?
Considerations: I would expect this new template behavior if you elect to use storyboarding as a way to manage the UI, but if you uncheck "Use Storyboards" I would have expected the old pass-nil-and-use-MainWindow.xib template.
This question was asked in a roundabout way here, but the answers are a little thin on discussion.
You're asking why Apple is doing something? There can be no definitive answer, unless Apple has spoken out explicitly, which they have not done.
Personally I find the new approach considerably more elegant, transparent, and bulletproof. As you rightly say, in the old approach the main nib was loaded automatically by the runtime in response to the Info.plist setting, and everything else that happened was done through the nib, in particular the instantiation of the app delegate and the window and the associated wiring (the app delegate must be made the application delegate, the window must be made the app delegate's window), except that then we come back to the code in the app delegate for final presentation of the interface.
This was hard to understand; it took a great deal of verbiage for me to describe it in my book. It was also easy to break. The nib has to know the name of the app delegate class, so if you didn't like those funny long names that were created by default, you could easily mess everything up when you changed them.
Now, however, the app delegate is simply named App Delegate and is instantiated in code by UIApplicationMain(), as you rightly say; and everything else is also done in code as a direct follow-on: the app delegate is instantiated and didFinishLaunching is called, whereupon we create the window in code, assign it to our property in code, load the nib if there is one in code, set the window's rootViewController in code, and show the interface in code as before.
Thus the bootstrapping is directly exposed to view because it's all code. This makes it easier to understand and to modify without breaking anything. It's almost as if previously the template designer was just showing off as to how much stuff could be made to happen magically and automatically behind the scenes; now everything happens out in the open, explicitly.
I'm working on a little macro record/replay tool which can automate a few very old Visual Basic 6 GUIs we have. To do so, I'm identifying the controls by their name (the value of the name property of a control, that is).
One part of this tool needs to determine the name of a control given its HWND. For newer Visual Basic applications which were done using VB.NET, I can use the WM_GETCONTROLNAME window message. This works nicely.
However, this message is not understood by older windows. Is there any way to do this for controls of Visual Basic 6 applications? A solution which does not require being in the process of the GUI would be preferrable, but if I had a solution which only works inside the GUI process then that would be acceptable as well (since I can do the injection myself).
UPDATE: One thing I just tried, this moderate success: I used the AccessibleObjectFromWindow to check for implementations of the IAccessible interface of the object which shows the given HWND. In case I get an implementation (it seems that many [all?] Visual Basic controls implement this interface), I use the accName property to read out the "accessible name". Sometimes this does yield a useful string, but usually it doesn't.
I believe the only way would be getting inside the process and obtaining a pointer to the Form object, yet I have no idea how to do it from outside.
Is it possible you add support for the WM_GETCONTROLNAME to those older applications?
Or maybe, you could identify the controls by some other, natively-available properties?
Other that that, as Raymond is saying, there isn't much you can do.
Can you modify the vb6 apps? if so in each form load event you could iterate me.controls and use the SetProp(ctrl.hwnd, "MYNAME:" & ctrl.name, 0) api to add the name to the window's own property list, then in your other app you can EnumProps(ctrl_HWND) looking for the one that begins with MYNAME: and parse out the value.