I'm new to Xamarin/Android, and so far it's been a pretty frustrating experience, compounded by code/AXML changes seemingly not being built or deployed to the emulator. I often find that a change I've just made seems to get ignored when I build and run the app.
My suspicions were confirmed when it started throwing an exception on a line in MainActivity.cs that I had commented out. Cleaning and rebuilding didn't help, and in the end deleted the bin and obj folders and uninstalled the app off the emulator for good measure (not sure which of these fixed it though).
Is it just me or is this a common issue? Is there anything I can do to prevent it from happening? I'm using VS2015 Community by the way.
Go to 'Tools/Configuration Manager' and make sure that both 'Build' and 'Deploy' options are checked for 'YourApp.Android' for active solution configuration and active solution platform. Then do 'Clean solution' and 'Rebuild solution', it should always work.
It looks like this is a common issue, as yet unresolved.
One of the comments in the above thread suggested that the problem can occur if you've only changed C# code, and unless you also "touch" one of the xml or axml files then the latest version won't be deployed. This seemed to do the trick in my case but it could have been a coincidence - Xamarin seems to be a temperamental beast, and will randomly fail to build or deploy on occasion, perhaps depending on the wind direction, or colour of my underwear that day.
I'm still in the early stages of learning Xamarin/Android, but if I don't enjoy the experience then I'll be jumping ship to Android Studio (although I'd prefer to stick with C# if I can).
I have been using Notepad++ for quite sometime now. I didn't have any of the plugins installed, for all the time I used it. Some days ago, I moved on to another PC and I installed Notepad++ (v6.5.1) in it and for some reason the auto-indent does not seem to be working!! I remember it as working in my old PC without any exclusive setting.
I made sure that the auto-indent option under the MISC tab of Preferences is set. I know that I can use plugins like nppautoindent or indent by fold to achieve the desired result, but I would like to know why it isn't working and how I can set it right. Has anyone come across or heard of such an issue?
P.S. - I was coding in Ruby and I made sure that it was selected under the language menu. To make sure, I also tried Java. It didn't make any difference though!! I felt like I was using the featureless built in windows notepad!!
Being a .Net developer I've vastly worked with Visual Studio and Jetbrains Resharper.
When using Resharper and VS, autocomplete suggestions appear when suggestions contains word being typed rather that start with. I've seen similar behavior in Jetbrains AppCode.
but Xcode, with default settings, just shows suggestion when the suggestions start with the word being typed!
Just wondering if we can somehow modify this behavior to suggest words containing rather than starts with.
I've looked at Xcode >> Preferences >> Text Editing, but couldn't find anything.
P.S. Why I'm not using AppCode if I need this feature? My 30 days trial evaluation is up!
As this question come in first place in search engine, i give a solution for people want this feature:
https://github.com/FuzzyAutocomplete/FuzzyAutocompletePlugin
just go to Xcode organizer and delete Derived data.
Clean Trash.
Restart Xcode.
It will working fine.
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
Xcode comes with a lot of things that are essential to building to the iPhone and/or iPad. In fact a lot of it I am not even aware of because it is so 'behind the scenes'.
On the other hand, I have recently been exposed to the advantages of using Vim as an editor. Is there any setup which would make using Vim an efficient option when developing for the iOS platforms? Or would it be so complicated to combine the two as to make this question moot?
In other words, if you have any tips, advice or warnings when using Vim and Xcode together, I am all ears!
Developing for iOS or Mac with Vim can be really powerful and fast, especially if you use TDD or want quick feedback.
But it takes a bit of finagling to get it working. The few important things you need to know are:
Use the xcodebuild command-line tool to run your build and units from some vimscript.
Use the clang_complete plugin to give you full code completion from within vim.
Use the ios.vim and cocoa.vim plugins for navigation.
This is my preferred method of working. In fact, I wrote the ios.vim plugin to make this easier for more people.
I've been there already...
I love vim and regularly use it in my day-by-day C++ development on *nix platforms, but I also like all of Xcode's features which, specially with latest Xcode >= 4.3 and clang backend, give a real plus in terms of auto-completion and symbol referencing.
I think I've found the optimal solution with the great (although not officially supported by Apple) XVim plugin.
Hoping that future Xcode upgrades won't break it (it's still working fine with latest developers' previews of 4.5), this really allows you to keep your fingers moving as you've learned doing in Vim while working with Xcode, which as I said, is for me the optimal solution.
Vim and XCode will co-exist quite well together provided that you aren't trying to edit the same files in Vim and the XCode editor at the same time. If you do then each will give you a warning about the file being modified externally. The terminal version of Vim is a little easier to live with in this particular respect: it will only warn you when you try to save the file, asking are you sure, whereas MacVim, and the XCode editor, will warn you each time you return to the file.
XCode does allow you to select an external application when you open files, by file type. In XCode Preferences, go to the File Types tab, and then file->text->sourcecode. Preferred Editor can be set to an external program such as MacVim; note that Emacs should be already listed as a selection: when Emacs is selected XCode launches Terminal.app with Emacs in a terminal. This Preferred Editor setting has the problem that you'll get a new window with each opened file, which may not match your workflow.
Vim's remote feature might prove useful here, see :help remote. With a little work, and the above Preferred Editor preference, one should be able to send the file to be edited to any instance of Vim, including an existing Vim running within an xterm. I seem to recall that Emacs provides something similar.
But none of this precludes you from using Vim without setting Preferred Editor: just open and edit your project files in Vim as you would normally.
Your workflow might be to use Vim for editing code, and switch to XCode for building the project, but Vim can also run the same build tools that XCode uses, and with a little more work you'll even be able to jump to the lines with errors. XCode relies on gdb for debugging, which can also be used quite well with Vim, via plugin.
Of course Vim can't be expected to replace something like Interface Builder, but just about every other aspect of iOS dev can be achieved with a Vim-only solution.
Or just use Vim to edit your code faster, and continue to use XCode for the rest.
Starting with Xcode 13.0 Beta you can use Vim keybindings in Xcode. It is enabled in settings:
Preferences → Text Editing → Editing → Enable Vim key bindings
Edit (per #fangxing):
The way to toggle what is now called Vim Mode changed:
Menubar → Editor → Vim Mode
Even thought MacVim with YouCompleteMe is my main environment for development on OSX, there are tasks I prefer to do in XCode, like debugging and profiling. For these scenarios I use XVim which adds VIM editing capabilities to XCode.
On XCode 5.1 XVim crashed quite a lot. But it progressed and it now works quite well with XCode 6 so far. But you only get a subset of VIM this way, e.g. you can't split the editor to view two files at the same time. You can enable/disable it quite easy with Shift-Command-X.
(Sorry to post this as answer and not as a comment, but the reputation-system of stackoverflow did not made it possible for me)
I can't recommend YouCompleteMe enough! Beside its code-completion it also shows you syntactic errors on the fly on the affected line without the need of manually triggering your compiler (i.e. very similar to the features of the XCode editor). The description of the YCM creator is quite informative:
YouCompleteMe is a fast, as-you-type, fuzzy-search code completion
engine for Vim. It has several completion engines: an identifier-based
engine that works with every programming language, a semantic,
Clang-based engine that provides native semantic code completion for
C/C++/Objective-C/Objective-C++ (from now on referred to as "the
C-family languages")...
To get it running:
Follow the section 'Mac OS X super-quick installation'
Don't forget to add a .ycm_extra_conf.py file to the root of your project folder
Edit:
Without a plugin like YouCompleteMe, VIM can only do rudimentary word completion (Ctrl-N) which is neither aware of the programming language you're using nor of all the other files belonging to your project. You also don't get a list of the members of an object after you type '.' or '->'. So you miss on a lot of help (and therefore speed) XCode is giving you while typing. Also VIM doesn't warn you like XCode when you make typos or other errors in your code. YouCompleteMe adds exactly those missing features to VIM and makes iOS development in VIM a joy.
You could use xcodebuild to build and run your project, but personally I prefer to work with VIM and XCode at the same time. Both reload documents automatically after they have been modified by the other. Keep XCode for debugging, profiling and deployment.
Using AppCode in parallel with Xcode is just amazing. Code changes sync right away! I am so happy with this setup because I can finally use vim (as an AppCode plugin) when writing iOS apps. AppCode has additional advantages so I really recommend that you check it out. The refactoring tools are also way better IMHO. E.g. it can extract methods that Xcode can't for some reason and if it can not extract a method it will at least tell you why.
There are definitely some advantages using external editors ( however emacs is ten million times better than vim:}).
Stick with Xcode for most stuff, but when you need the power of emacs, or possibly vim ( bulk repetitive editor macros is my main reason), just edit the file using show in finder and open with, or just by switching to your editor navigating to the file from there.
XCode will realise when you switch back that the file has changed.
For plain code, I'd stick with Xcode, it's code completion is based on more knowledge of the code, so beat's emacs or vim's hands down. Continuous code checking is invaluable, and as already mentioned, the direct access to the documentation is awesome ( option click if you haven't already found it).
I like XVim for XCode. Unfortunately, it breaks for XCode 5.1 (some people got Development branch working, but I couldn't).
I ended up switching to AppCode after a trial, I really liked the tab management, refactoring, and code analysis. Code is automatically synced with XCode, so I run both (XCode for build settings, managing asset catalog. AppCode for everything else).
First day I downloaded it, I installed IdeaVim so I could still use some of the Vim keyboard shortcuts.
Though you won't get to full Vi/Vim functionality with the plugin. I find mix usage with native IDE commands is enough to compensate.
According to my opinion Xcode is better solution. It has so many features that you can not find/add in Vim. Some of them are:
Interface Builder (to create good lookin interfaces in less time)
ARC (Automatic Reference Counting—memory management)
Automated process for managing code signing and app store submission
The list is very long and Apple always encourages you to use Xcode, not any other IDE.