Develop Reference

Xamarin Forms Android This type of collectionView does not support changes to its sourceCollection from a thread different from the dispatcher thread

Here is the error I'm getting when trying to archive my app for deployment.
This error doesn't show up at any other time. The project builds and runs on emulators and devices without issue. This error has zero context or direction as to where to look to fix it. It also just randomly showed up out of nowhere, last time I built/archived (with zero functional changes) this error did not happen.
Main difference between this archival and the previous one is a newer version of VS 2017. Don't remember exactly the version from before, but am currently on 15.9.4 (stable).
Looking around on the interwebs, I've found that this error seems to have something to do with ObservableCollection's, which there are probably 10-ish in my app. Not really sure what to do here, because this has never been an issue previously, and I'm coming up on a deadline and with the structure of the app, am not in a good position to start making functional changes.
EDIT
I have also cleaned and rebuilt my solution, as well as deleting all bin/obj folders in my xamarin projects. Even tried deleting the .vs folder which can sometimes help. But still no go.
Going to try updating VS to 15.9.5 and see if maybe it was fixed in a release.
EDIT 2
Updating VS 2017 to 15.9.5 made no difference.
EDIT 3
I had my coworker try archiving the exact same project on his machine (running VS 2017: 5.9.3, and it archived fine for him. So far that's the only difference we've been able to find between our environments.

I saw the same problem using VS2017 15.9.9. Even the same code that could be archived a week ago threw the above mentioned error. It seems related to local data in the solution. A "clear" build was not sufficient. However manual deletion of the local obj and bin folders followed by archiving (build is done implicitly) solved the problem for me.

For my part closing Visual studio and deleting the .vs hidden folder did it.
It's actually a fix for many issues using Xamarin.
I had this other issue where I couldn't archive because the build process would just hang and never end. Deleting the .vs folder did it too.
https://github.com/xamarin/xamarin-android/issues/1760

Just go to project property then go to Android options-> Select Advanced then increase the Java Max heap size to 2G/3G -> it's working for me.

Leon Lu's suggestion worked. I don't particularly like it, as it took forever and repairing basically restores you to a base install (no extensions or personalizations). Took about 1.2 hours to complete, but once done I was able to again archive my android application. I guess something went wrong in vs at some point, perhaps during an update. There's no way to tell.

I tried ALL of the ideas above, but had no consistent reliable luck with any of them.
I found that Microsoft has had the problem reported to them (see link below). After a ton of time burn on this, I posted at the link below one way that I've been able to get around this archive-build issue.
Like the other fixes, it's not exactly logical, and nothing that you would think would work, but I've found the process to be repeatable, which is golden for me with tight timelines and having no time for this.
MS Visual Studio Developer Community Problem 507708
Posted on a Saturday morning, a sign of really needing to get around this urgently. I hope it helps you too.

How to avoid the "User Operation is Waiting" dialog come out in Eclipse/ADT

As shown in the image, when I'm developing Android applications with auto build, sometimes this dialog will show. Is there any way to avoid this and make it just go through the process in the background?
It does not always show, but when it does, I need to wait for it for 5-10 seconds. That's annoying, especially considering that when the project gets bigger, it will go much slower.
UPDATED:
I did some researching:
Android compilation is slow (using Eclipse)
Android: eclipse workspace takes a long time to build?
http://groups.google.com/group/android-developers/browse_thread/thread/a16202975510de39
http://oae9.wordpress.com/2011/03/22/android-workaround-for-slow-building-workspace-problem-in-eclipse/
http://www.androidengineer.com/2010/06/using-ant-to-automate-building-android.html
Is it there any easier solution that is not using ANT?
Or any other best ANT script that can be applied easily?

How about you just uncheck the "Build Automatically" option. This doesn't speed the build process, but doesn't do it everytime you save a file.
You will still need to do a build that takes a bit of time - but you will only do it when you really want to compile your project (not everytime you make a change to the code).

IntelliJ Android cache build with drawables ignores changes

I have a minor issue with the way IntelliJ caches files or builds (not sure about terminology here).
Situation Abstract:
Library module
DrawableA
DrawableB
App module
DrawableA
Assume library images are black and white, App ones are color.
The app shows (correctly) the colorful A.
The app shows (correctly) the black and white B (means its missing).
Now I add an image to App project, Drawable B, in color.
If you simply press "run" he will keep using black and white B
If you "rebuild project" he will use the correct one
If you try "Make" and "Compile" manually on Lib and App NO EFFECT
To clarify, this issue is really special. It only occurs if the DrawableB is NOT present in the App module. If you have it, but the WRONG one, and you update it, it works. I assume its an internal caching of IntelliJ, and he does not recognize that I added a drawable (and he has to use it from the App now, not the LIB). Perhaps its something in the google build of Android projects, not enough info about the internal here...
I know, the obvious tip is "do a rebuild of the whole project" - that said, I have 18 App modules, each for one App. The rebuild takes forever (on one of our machines without SSD), and its not neccessary. If I change something in e.g. AppX, I only need to rebuild AppX and the Library. But there seems to be no option for it.
Does anyone know a workaround, like deleting BIN or other cache folders via script? Cant split up the modules in different "projects", would loose refactoring capabilities.
Crosspost here, check before wasting time to answer (this site here is more frequented and faster, but this issue is so specific, cant hurt to ask the developers too)
http://devnet.jetbrains.net/message/5446674

Try to rebuild project. Smtm i have same problem and it helps me.

Can you try it with the new IntelliJ Idea version 12? It seems to handle cached resources pretty well.

Android non-Eclipse command line projects viable?

Let's say that I'm doing an Android project at the office, and that it is not just a hobby project, and that it is actually intended to be released and mass distributed. Would there be anything crippling about using the Android command line tools to manage the project, and just ignoring Eclipse? They describe here how to manage projects on the command line:
http://developer.android.com/guide/developing/projects/projects-cmdline.html
However, I can't get a feel for if those tools are production quality or not. Basically, I'm afraid that if I use the command line tools then somewhere down the line I'll have to do task "X", only to find out that task "X" is basically impossible or insanely difficult without Eclipse. Are there any such task X's? Or are the Android command line project tools actually viable for commercial projects?
I already know that you won't have a GUI designer, but I'm not that crazy about the GUI designer in Eclipse anyway. I constantly find myself pressing "Run Project" to debug my GUIs on the actual device anyway (layout preview be damned).
As for debugging, for the limited amount of debugging I do command line jdb is adequate, even if not always completely pleasant. And I bet I could set up a GUI debugger if I really had to.
The question is, are there any problems that would be considered effectively insurmountable without Eclipse? Or are there just minor annoyances that can be easily worked around (like the two I just mentioned above).
I realize that stack overflow isn't meant for discussion questions, and this question might seem like just that, but I think it doesn't have to be. If there really is something gigantically terrible about not using Eclipse, someone will mention it, and I'll give them the green check mark. If there isn't, then perhaps someone can point me to examples of existing large projects that use the command line tools instead of Eclipse, and I'll give that the green check mark instead.

Many people use Ant to build Android projects from the command line. Actually, in my opinion this is the preferred way, since it allows you to check everything that you need into a source control system and get predictable and repeatable builds every time.
So, the answer is "Yes"! Take a look at Using Ant to Automate Building Android article for more in-depth explanation how you manage this. Of course, using Eclipse is very convenient, but you don't really need it to build Android applications.

I use Maven for all of mine. See android-maven-plugin.

Building workspace is taking a lifetime

I'm developing a game that has a lot of drawables. Now I'm designing the levels, and it makes me refresh my project very often after making minor changes. And every time workspace is building very slowly, it makes me lose very much time on just waiting for it to build. Are there any hints on making it faster? Or how can I disable rebuilding of all those resources that do not change from build to build? Thanks in advance.

Depending on your environment and version of eclipse, it could be setup to use a small amount of memory on start up. Try tweaking the memory you use and see if that helps. You can do this by starting it from the command line or editing the .ini file (on windows). This blog post touches upon it: http://blog.xam.dk/?p=58

you can disable "Build automatically" in "Project" then you can manually build your app after your changes by "Build project".