Recently I've noticed a couple of projects on github that extend the functionality of Xcode 4 via plugins.
Two projects as examples by #olemoritz:
MiniXcode changes the main toolbar.
ColorSense provides overlays to help pick colours.
Both projects are installed into ~/Library/Application Support/Developer/Shared/Xcode/Plug-ins and Xcode just picks them up.
Are there any sources of documentation (officlal or user generated) on extending Xcode?
Edit: ping #olemortiz ;)
As I wrote those plugins you mentioned, here are some pointers:
There is no official documentation from Apple, so while Xcode does have a plugin infrastructure, it is entirely private API. (but hey, no one wants to submit Xcode plugins to the App Store, right? ;)) – The usual warnings apply: You should code very defensively, and it's possible that Xcode updates break things. Any plugin can bring Xcode down entirely, so be careful.
There is a seemingly abandoned effort to document the plugin interface here.
There are some open source projects that allow you to see what's needed to get a plugin loaded at all, e.g. mine and there's CLITool-Infoplist (I think that's where I got the basic structure from, but I can't really remember, because I've been doing this without publishing anything for quite a while).
You can use class-dump to generate headers from Xcode's private frameworks, e.g. IDEKit and IDEFoundation (in Xcode.app/Contents/Frameworks). Reading those gives you quite a bit of information on how Xcode is structured internally. DVTKit and DVTFoundation (in Xcode.app/Contents/SharedFrameworks) can also be useful to class-dump.
You can observe all notifications that are sent in Xcode by registering an observer for nil. I initially just logged all those notifications to get an idea of where I might be able to hook into.
Good luck!
There is no formal API or documentation.
Having said that nearly all community plugins are open sourced, use http://alcatraz.io to discover new plugins, then follow their github source code to learn how people are implementing them.
Here are some useful resources:
Use https://github.com/edwardaux/XcodeExplorer to discover the API hook point you need to be poking around.
Look at http://www.blackdogfoundry.com/blog/creating-an-xcode4-plugin/ for a series of posts about building Xcode plugins.
Check https://github.com/kattrali/Xcode-Plugin-Template for a Xcode 6+ template for creating new plugins.
Look at https://github.com/zats/AdjustFontSize-Xcode-Plugin as a good Xcode 7.1+ starting point
See http://www.blackdogfoundry.com/blog/debugging-your-xcode-plugin/ for debugging aid
Related
Recently added Firebase Storage and Authentication to my Unity project. I work on Windows, have a single Unity Pro License, and want to export my App for iOS, as I have done many times before in this dev process.
However, since the addition of Firebase, I'm told I apparently can't export my Firebase-Enabled Unity project for iOS without swapping Unity to an OSX device (which I don't have in comparable quality).
I've noticed a singular thread here where a supposed workaround was discussed, but can't seem to pull it off myself:
"The plugin that comes with firebase depends on cocoapods to handle
transient dependencies. If you look at the Assets ->
PlayServicesResolver -> IOSResolver -> Settings
You can configure it to generate the podfile but not do the remaining
steps." - from user johnb003, March 18th 2017.
Can't seem to find the configuration settings described here. Scoured the forums/communities for solutions, but no results elsewhere.
So, that said, any other Firebase user have a workaround for this issue? I adore the collective Google has put together with their product, but I can't really afford to invest in another Unity Pro License just for the sake of working off of my sub-standard Macbook. Thoughts?
Looks like there's a Google Github project, Unity JAR resolver, describing how the Unity Play Services Resolver works for each target platform.
The documentation is pretty extensive, and solutions are use-case specific, so I can't give you much help on specific podfile settings, but hopefully you can sift through it yourself.
i am new to Unity and i am try to understand plugins. I have got the difference between a managed plugin and a native plugin, but what is not very clear to me is:
what is the difference between a plugin and a dll? what should i expect to find in an sdk to make it usable in my unity project?
Thanks a lot
To expand on #Everts comment instead of just copying it into an answer, I'll go a little into details here
What is a plugin?
It's a somewhat vague word for a third-party library that is somehow integrated with the rest of your game. It means that it neither is officialy supported by Unity, nor is it a part of your core code. It can be "plugged" in or out without altering its internals, so it must provide some kind of API that can be used by the game code.
For example, you'll find many plugins that handle external services like ads, notifications, analytics etc. You'll also find a couple of developer-tools that can also be called plugins, like tile-based map editors and such.
Plugins come in many forms - DLL files are one example but some plugins actually provide full source code for easier use. And of course, other plugins will provide native code for different platforms, like Objective-C for iOS or .jars for Android.
So to answer your first question:
DLL is simply a pre-compiled source file that can be a part of a plugin
A plugin is a whole library that can consist of multiple files with different formats (.cs, .dll, .jar, .m etc)
What do you need to use an sdk?
First of all - documentation. Like I said before, and like you noticed yourself, not all plugins give you access to the source code. And unfortunately, not many sdks have extensive and developer-friendly documentations so it can be a tough task to actually understand how to use a given sdk.
Secondly - the code. Many sdks give you some kind of "drag & drop" library, a single folder with all the neccessary files inside that you simply add to your Unity projects. I've also seen sdks that use Unity packages that you have to import via Assets > Import Package > Custom Package.
Once you have the code and documentation it's time to integrate it with your game. I strongly recommend using an abstract lyer in your game as, in my experience, you often have to change sdks for various reasons and you don't want to rewrite your game logic every time. So I suggest encapsulating sdk-related code in a single class so that you have to change only one class in your code when switching from, say, one ad provider to another (and keep the old class in case you need to switch back).
So you basically need three things:
Documentation (either a readme file or an online documentation)
The code (precompiled or source)
A versatile integration
We are doing some work around sharing UI across apps, both entire views and also individual controls, so the structure we end up with is (on Android):
Android App
View (Activity + Layout) pulled in from a NuGet package
Control (Layout) pulled in from another NuGet package
So the app pulls in the view and the view pulls in the control.
The problem we’ve seen is that resource IDs defined in the control’s layout don’t end up in the Resource.designer.cs of the app such that when the app runs we see a crash when FindViewByID is called.
Interestingly we have implemented the above in three different apps, it works in two and not the other, so I’m left thinking it is ever a difference in the build config somewhere or its pure chance and we can’t rely on this pattern working.
Has anyone seen this before?
Update:
Having paid closer attention to the build output I can actually see warnings being generated for the missing controls:
Warning XA0106: Skipping MyControl.Resource.Id.myId. Please check that
your Nuget Package versions are compatible. (XA0106)
Old question I know, but in case anyone needs it:
I experienced very similar problems after updating to Xamarin.Forms v4.1.0.581479, and followed James Esh's comment above, and JimmyGarrido's response here to get a resolution: https://forums.xamarin.com/discussion/89661/a-lot-of-warnings-appear-in-a-new-empty-xamarin-forms-xaml-project
The simple answer in my case was to remove the PCLAppConfig Nuget package. There may be other packages in your project which were built using an old version of the Xamarin.Android.Support* packages. Unfortunately I haven't found a way of diagnosing which package specifically causes the problem, so updating, then removing and retesting one-by-one led me to the solution.
I need to know if I can do Continuous Integration with XCode server. In example: set run the tests every night or when someone commit changes, and more..
I am trying to decide one iOS Ui Automation tool to integrate with my Xcode server
Thanks
There are a few problems here:
UIAutomation has no built in support in Xcode Server. I've filed bugs, I've chased down people at WWDC. Most I've ever gotten on this problem is basically "shrug." I'm not sure UIAutomation is a priority for Apple right now. So you're not going to get any official support.
As was noted, you might be able to use a trigger. The trigger won't be able to add anything to the Xcode Server report, besides possibly the error logging. But you're not going to get anything added to the nice report table.
Running on actual devices has traditionally been a problem (if you care about that.) The loading the app part has been a problem for us, but Xcode Server might be able to preload the app for you. In addition, it seems like this might have changed in the iOS 8 SDK.
There is just a lot of uncertainty around this sort of workflow. I'm hoping Apple eventually makes an announcement or adds a new tool, but the best answer I've gotten is if you want to go down this path, use UI Unit Tests. That's a shame because it requires knowledge of Obj-C or Swift, and means interacting with the app at an API level instead of an abstract level, but if you're looking for the direction Apple wants to see people go, that's it.
Edit 7/4/2015: As of WWDC 2015, there is a new UI Testing component as part of Xcode 7 that, in my experience, seems totally supported, and is promising Xcode Server support. I would very strongly recommend using that, and not using the Instruments UIAutomation tool.
With Xcode6 right around the corner they are adding some features to XCode Server specifically it looks like "Triggers" will be helpful for running iOS UIAutomation tools. Since you can run UI automation scripts from cmd line it should be possible to utilize triggers to run your scripts post builds. This along side the logic for when a bot should run will let you decide if it should be nightly or on every commit.
https://developer.apple.com/library/prerelease/ios/documentation/DeveloperTools/Conceptual/WhatsNewXcode/Articles/xcode_6_0.html#//apple_ref/doc/uid/TP40014509-SW1
I wrote a framework around UIAutomation called Illuminator to handle tasks like nightly test runs, pull request tests, and other automated conveniences.
It provides a flexible and extensible command line that can execute any particular subset of tests that you'd like, and produces reports in JUnit format (used by Jenkins).
I'm a novice iOS developer with a basic knowledge of Xcode. I have one app in the app store that I made myself with Titanium. For a next project I've enlisted the help of two more experienced programmers in another city. I have a question in two parts about the collaboration between us:
I want to propose a work routine that gives me access to the project as they are working on it, so that I can device test builds during the development process - without interfering with the coding. What is the best way to do this? Is sharing the project or codebase via Dropbox an option? Does anybody have any experience with this?
Are there any pitfalls I should be aware of when pursuing this kind of work routine?
Thanks!
Use a source control system like Subversion, Git, Mercurial.
XCode has built in support for Subversion/Git.
Use source control. Github is a great place to start. (private repositories will cost money though.)
I used to use DropBox to share code between my two machines, but DropBox would routinely ruin work if I wasnt careful. DropBox is NOT version control. If you do insist in using Dropbox, don't open your code on more than one machine at once. Nuff said.