Android Studio ambiguous method call for Object.toString - android-studio

Others have seen the "Ambiguous Method Call" error in Android Studio for
getClass()
But I'm seeing it for
Object.toString()
Has anyone else seen that?
The version of Android Studio I have is 0.8.6.

First off, to answer your actual question, yes I am seeing that, and I am running Android Studio (Beta) 0.8.14, and it is an Android Studio/IntelliJ bug, as mentioned before, so your code should be fine when you actually compile. But, if you want it to stop underlining everything in red:
As you may notice on the issue of the getClass() call found at Android Studio - Ambiguous method call getClass(), you can cast the object in question to an Object to resolve it as such:
((Object) myObject).toString()
Alternatively, depending on the case you're dealing with, you may be able to rely on Java's included libraries implicitly* calling toString() on the object, as was the case with my code, where I was appending to a StringBuffer:
sb.append("Object's toString() returned: " + myObject);
Note: this will still work even if you didn't have the literal String object that I defined there, so this is also valid:
sb.append(myObject);
Or if you're simply printing to standard out,
System.out.println(myObject);
*As a side note, it is not actually being called implicitly, but rather many of Java's built-in classes have an overloaded method signature that accepts objects of type Object, which is then turned into a string via a call to String.valueOf(myObject) - see How an object will call toString method implicitly? for more about this.

Related

Android Studio - Why is this function not called?

I'm learning Android Studio & Kotlin and came across a interesting error.
Notice how the squeezeState() is in red, or says that the function doesn't exist even though its at the bottom and has been declared properly.
Why doesn't Kotlin pickup the function reference?
I realise that this isn't JavaScript and that you need to declare the function before calling it

Where is the setting for the suggestion to wrap incompatible argument for TextView's setText() method using the static method String.valueOf()?

Recently I found out that my Android Studio no longer gives the suggestion to wrap an incompatible argument for the TextView's setText() method using the String.valueOf() method.
I sometimes forget to convert the value/variable that I'm going to pass as argument to String, but Android Studio usually gives me a warning AND suggestions to wrap the value/variable, as long as it is possible. Now, for example, when I do this:
double x = 10.567;
textView.setText(double);
Android Studio will still give me a red error warning, but the only suggestion in there is "Cast parameter to 'int'".
It used to give me the option to automatically insert the String.valueOf() method call, which is very helpful.
Is it just me or this is how it is now? There was an update a few days ago.
Did I mess up some settings in my Android Studio? Can someone tell me how to fix it?
I've looked through the Inspections settings and I haven't found it, if there's even a setting for it.
Maybe the update changes the mechanism, or you can click on the "More actions" in the prompt to see if other options available.
setText() can accept String or int, if you pass in int value, compiler will expect it is String resource ("R.string.xxx"), which is int type. Just memorize this, you don't need to rely on the prompt any more.

VC++ EXE standalone has bugs that don't happen in IDE

My program has a very specific error that took me a while to track down - now I don't know how to fix it. My code is very long and in many files and I don't see much point in posting it here.
In the IDE, everything runs fine, in both Debug and Release (with the runtime library set to either /MTd or /MT, respectively, so I'm assuming all dependencies are included).
However, when I run the standalone, I get a crash. At first I thought it was a dependency problem but it doesn't seem so.
At some point in the code, I am accessing a vector via a method call: t->GetList(), where GetList is defined as std::vector<T*> & GetList() and the method simply returns a member variable (simply defined as std::vector<T*> field in the class).
It turns out, if I print out the size of the list while running from the IDE, I get 0 (which is the correct answer in this case).
However, when doing the same thing running from standalone, I get the size as 467467353.
I tried changing the method declaration to std::vector<T*> * GetList() and doing return &field; and updating the rest of the code but this didn't fix anything.
I then tried replacing the member variable field with a pointer, and in the constructor instantiating a new vector and deleting it in the destructor. Still no luck.
So I made a simple test case program that simply made a class with a vector field, and a method to return a reference to it. Then in main I would create an instance variable and getting the vector and printing the size. This worked both in VC++ and as a standalone - both returned zero.
This is driving me nuts and I can't figure out why I'm getting different behaviour. Why is the standalone running differently, and what should I be looking at to fix this?
Thanks
Okay so it was literally a bug in my code that was very well hidden. I was dynamically casting to a wrong type.
Somehow it slipped past when I was running on Windows and OSX in both Debug and Release, and as a standalone on OSX. Good thing I found it.

Mvvmlight and Xamarin.iOS unable to find default ctor

I have a project that is running fine on Android and WinPhone 8. When I attempt to run on iOS, I've getting the following error
Microsoft.Practices.ServiceLocation.ActivationException: Cannot
register: No public constructor found in x
where x is whatever SimpleIoc.Default.Register<T, TU>(); the flow hits first. I've moved the code around (as suggested elsewhere) to ensure all of the platform specific SimpleIoc calls are made in ViewModelLocator.
I've added public default ctors in the classes that are complaining about the error (I have though set the PreferredConstructor to the original, not the newly added public ctor).
I have a feeling that this error is a false positive (something else is failing, but pointing at that code).
Using Xam.iOS via a build server (the code is coming from VS2015). Xcode is running the 8.3 emulators (it may need updating to allow for 8.4 testing)
It could be that the Linker is optimising away the constructor, if it thinks it's not used. Try setting the Linker Options to "Don't Link" and see if it does it again, or even new-up an instance of the class elsewhere so that the Linker knows that the constructor is used. You don't necessarily want to leave it that way, but if it eliminates the error, you'll at least know the reason.
The [Preserve] attribute did the trick for me.
Decorate constructor with it and keep your linker settings.
This attribute is part of the Microsoft.WindowsAzure.MobileServices namespace.

Using 'auto' in for each causes C3539 - Why?

I am writing a managed DLL in VC2010 (i.e. /CLR is enabled for a VC++ DLL project). Following code wouldn't compile:
System::Collections::Generic::List<int>^ my_list;
for each(auto elem in my_list)
{
}
It raises error C3539: 'auto': a template-argument cannot be a type that contains 'auto'.
I don't understand the reason. I tried compiling the same in VS2012, and it raises same error (which is not appropriate error).
Why compiler fails to deduce the type for a colleciton? The same type of code would work in C# with var keyword.
First, the most importand point from the comments:
presented code does compile in VS2013 c++/cli dll .net 4.5 (Zee, 2014-05-03)
When you compile C++/CLI, which is the .NET binding for C++, you are using a different feature set of the Microsoft compiler. Whether something works either
when /clr is in effect
or, additionally, when you're using a "managed" construct (as in your code)
has nothing to to with if the "normal", native, MSVC compiler accepts it.
So as for "why": It would simply appear that auto type deduction did not work for the managed handle types in VS2010 and VS2012, but, according to Zee's comment, has then been implemented in VS2013. (A quick Search Engine check didn't find any official statement wrt. this, so I may be wrong.)

Resources