Develop Reference

GradleDetector: `checkDslPropertyAssignment` isn't executed

I'm writing some custom lint and decided to add a detector for the Gradle files.
So I've extended the GradleDetector(), overridden checkDslPropertyAssignment method, and added some test to check the logic inside checkDslPropertyAssignment. So far all works well.
However, if I name the gradle file differently in the test case, checkDslPropertyAssignment doesn't get executed. For example:
lint().files(
gradle("test.gradle", gradleFile)
)
If I skip "test.gradle", everything seems to be working.
Am I misusing something here, or is there a bug in the GradleDetector?
Thanks!

Various questions #NonNull, #NotNull and #ParametersAreNonnullByDefault

I'm an Android dev who is using AndroidStudio or IntelliJ IDEA.
I tend to trust my IDE and I'm annoyed with next facts:
In android project when IDE autogenerates a method in java that extends Kotlin class then both IDE uses #NotNull instead of #NonNull, is there setting for this? This
We have #ParametersAreNonnullByDefault but when I override the method from the point 1 and I don't put any annotation IDE warns me, but why?
Am I wrong in my assumptions?
Are there solutions?

Which annotations to use for null/not-null is set under Configure annotations... in the Compiler page of the Settings/Preferences dialog. Select the one you want and press the checkmark button. See https://www.jetbrains.com/help/idea/nullable-notnull-configuration-dialog.html for documentation.
I can't test right now whether IDEA/AS use the default annotations from there when overriding a method which already uses another, but if they don't you'll need to file a ticket.

Android Studio not recognizing Espresso/Hamcrest static method names without prefacing with the classname

I wasn't sure exactly what headline to give this question because I'm not sure what this is technically called. In Android Studio while typing out Espresso tests I noticed that it refuses to accept something like this:
onView(withId(R.id.someId)).perform(click());
and instead will only accept this:
Espresso.onView(ViewMatchers.withId(R.id.someId)).perform(ViewActions.click());
even though every example that I've seen online shows the first example as correct code. Why is Android Studio forcing me to preface every ViewMatcher/Espresso/ViewActions/etc. method with the classname even after the imports are included in my class?
To clarify - trying to use the first example shows "cannot resolve method" and using autocomplete on it (which I have to do several times before it will work) invariably autocompletes to the second example. In all the "regular" code for my project autocomplete works correctly and short method names are recognized. I've tried doing a "clean" and "invalidate cache and restart" but no change.
Example of Google doc that shows usage according to the shortened code:
https://developer.android.com/training/testing/ui-testing/espresso-testing.html

You can try to check out your Android Studio Preferences for imports. Just go to Preferences -> Search "imports"
Here are the settings that I use and I don't have that issue:

What fixed the issue for me: just removed red withId in one place. Then just re-entered "withId": after that all the other red withId were replaced with black text color withId and now it compiled successfull!

Rendering issues: The following classes cannot be instantiated

I am converting a Eclipse project to work in Android Studio and have got all issues fixed except some layout xmls are showing the following issue in the drag and drop view
Rendering issues: The following classes cannot be instantiated
X.X.X.myclass.
I checked my class and it seems ok, i changed the latest API i have from the little dropdown; 22 (i guess this is the compile API). I havnt changed my Gradle setup, could it be something in there?
I havnt posted any code as im not sure what would be helpful - any ideas?

First of all: that's just a layout preview. You can edit the XML and carry on with your project and it won't affect anything on it.
The layout rendering thing literally runs your Java classes to create the preview with some mocked implementation or an actual android device, similar to testing mocked implementations.
So this message is just telling you that this mocked system failed to render the preview.
But if you really want to see the preview, you must check where in your class are you relying on variables, or objects that are inherent from your app that the mock system will not have access to.
An example, if your custom view does some special stuff during onLayout:
#Override onLayout(...){
int value = MyLayoutDetailsCalculation.getExtraPadding(getContext());
}
that is a code that is calling to a static method on a separate class that is using the context (probably getting values from system resources or from the display manager) and this will not execute well in a mocked environment and the preview wouldn't be able to render it.
luckly it's an easy fix:
#Override onLayout(...){
int value;
if(isInEditMode()){ // that returns true if this code is being executed by AndroidStudio mocked system.
value = 0; // any value that makes OK for your custom class to properly show a preview
} else {
value = MyLayoutDetailsCalculation.getExtraPadding(getContext());
}
}

Unittesting AsyncTaskLoader with getLoaderResultSynchronously

I am trying to create unit tests for a REST client that does some API calls. The client works fine in the live application, but I can't get it to run in the test case.
Apparantly, LoaderTestCase.getLoaderResultSynchronously() could be used here (at least according to Android reference, but it will not accept my loader. The code:
public void testGetEventInfo() {
// Init some vars
...
// Create & execute loader
RESTLoader loader = new RESTLoader(getContext(),
RESTLoader.HTTPVerb.GET, action, params, LOADER_GET_NEWS);
getLoaderResultSynchronously(loader);
}
This yields the error getLoaderResultSynchronously(Loader) in the type LoaderTestCase is not applicable for the arguments (RESTLoader).
RESTLoader extends AsyncLoader. Note that I'm using the supportlibrary, maybe the Loader in there is incompatible? The documentation gives no information on this.
I've tried to solve this in several ways, though none seem to work:
Registered a listener to loader. However, the callback never triggers
Using CountdownLatch (also with a listener). Again, no trigger/countdown timeout.
Playing around with the type template (), without success.
Similar solutions on SO, though again failing to reach the listener.
Does anybody know why getLoaderResultSynchronously will not accept the loader? Or another clean way of testing the Loader, including a way to test return data? I can test handling the return data in a separate case, but I would also like to test the actual data.
Sincerely,

Have you taken a look at the source code? You'll find the following import statements:
import android.content.Loader;
import android.content.Loader.OnLoadCompleteListener;
It doesn't look like Android offers a support version for LoaderTestCase. The easiest solution would be to temporarily change to the non-support LoaderManager (that is, have your class make use of the android.content.Loader instead), test your app, and then switch back to the support implementation. You might also consider copying the testing source code into your project, import the support LoaderManager, and execute it directly. I'm not familiar with the test libraries for Loaders but it doesn't seem outwardly obvious that this would cause any major issues.

You can get sources from LoaderTestCase here, create SupportLoaderTestCase class from that sources in your test project and modify all namespaces to support library namespaces (e.g. change android.content.Loader with android.support.v4.content.Loader). Than you can extend your test case from SupportLoaderTestCase (not from LoaderTestCase) and use it without problems

The method you are trying to call (getLoaderResultSynchronously) accepts an object of type android.content.Loader. If your RESTLoader class is not of that EXACT type then you will get this error. I suspect your class directly or indirectly extends android.support.v4.content.Loader, which would explain the error.
I am not aware of a back-port of LoaderTestCase that would support testing of this type of class.