New 'ValidFragment' check in Lint

[Roman Mazur]

Currently 'ValidFragment' check produces an error if default fragment constructor in implicit.

To be honest, I'm not satisfied with such a behaviour because it makes me add an empty constructor explicitly to a bunch of classes...

[Roman Mazur]

Another complain :)

Is "AppCompatMethod" check run regardless I do not use AppCompat library?

I checked dependencies report on my project and did not find a dependency on appcompat library. I get AppCompatMethod warnings though.

On 6 May 2014 11:48, Roman Mazur <mazur...@gmail.com> wrote:

Currently 'ValidFragment' check produces an error if default fragment constructor in implicit.

To be honest, I'm not satisfied with such a behaviour because it makes me add an empty constructor explicitly to a bunch of classes...

--
You received this message because you are subscribed to a topic in the Google Groups "adt-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/adt-dev/aKRNyi8OSBM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to adt-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Best regards,
Roman Mazur 

Software engineer at Stanfy (http://stanfy.com.ua)
Skype: roman.mazur.f

LinkedIn: http://ua.linkedin.com/in/romanmazur
Twitter: http://twitter.com/roman_mazur

[Roman Mazur]

Also I cannot figure out how 'InflateParams' warning can be suppressed.

Annotating method with @SuppressLint("InflateParams") does not seem to help.

[Tor Norbye]

On Tue, May 6, 2014 at 1:48 AM, Roman Mazur <mazur...@gmail.com> wrote:

Currently 'ValidFragment' check produces an error if default fragment constructor in implicit.

To be honest, I'm not satisfied with such a behaviour because it makes me add an empty constructor explicitly to a bunch of classes...

That's a bug. I discovered it myself yesterday and fixed it:

https://android-review.googlesource.com/#/c/93424/

The reason this happened is that I've recently rewritten a bunch of lint checks which *used* to analyze the bytecode to instead analyze the parse tree of the source files itself. That has a number of advantages - more accurate source positions, works inside Studio/IntelliJ without compiled sources, etc.

But in this case it had an unexpected regression: When you have a class which doesn't specify a constructor, the compiler will automatically insert one, so it's always there -- and the lint check didn't have to worry about that scenario. When I rewrote it to an AST check I didn't think about that, and there was no unit test covering that scenario.

The above fix has already been cherrypicked for the next 0.10.x release of the Android Gradle plugin.

-- Tor

 

--
You received this message because you are subscribed to the Google Groups "adt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to adt-dev+u...@googlegroups.com.

[Tor Norbye]

Do you have a menu XML file which specifies app:showAsMenu rather than android:showAsMenu? If so, did you create an attribute named showAsMenu yourself?

That lint check is detecting the (rather common) bug which happens when you take a project which used to have an app compat dependency, and you delete appcompat and the various activity superclass definitions, but forget to update the menu file.

(In 0.10.0 there was a bug where the appcompat dependency was not recognized, which was fixed in 0.10.1, but it sounds like you're dealing with a different problem).

--

You received this message because you are subscribed to the Google Groups "adt-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to adt-dev+u...@googlegroups.com.

[Tor Norbye]

Suppressing with an annotation was broken for that lint check. Should be fixed by 

https://android-review.googlesource.com/#/c/93553

As a workaround you can suppress by comment instead:

        //noinspection AndroidLintInflateParams

        convertView = mInflater.inflate(R.layout.your_layout, null);

-- Tor

You received this message because you are subscribed to the Google Groups "adt-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to adt-dev+u...@googlegroups.com.

[Roman Mazur]

Thanks Tor for all the comments and especially for fixes :).

As for AppCompatMethod (not AppCompatResource) check I get the warning for the line

getActionBar().setCustomView(customView, new LayoutParams(MATCH_PARENT, MATCH_PARENT));

I use version 0.10.1 of gradle plugin, appcompat library is not used in the project.

[Tor Norbye]

On Wed, May 7, 2014 at 12:36 AM, Roman Mazur <mazur...@gmail.com> wrote:

Thanks Tor for all the comments and especially for fixes :).

As for AppCompatMethod (not AppCompatResource) check I get the warning for the line

getActionBar().setCustomView(customView, new LayoutParams(MATCH_PARENT, MATCH_PARENT));

I use version 0.10.1 of gradle plugin, appcompat library is not used in the project.

Aha. I see the problem. That lint check was written as a custom lint rule to be shipped with the AppCompat library (AAR libraries can supply lint rules) so that code assumed it always applies. I recently put that rule into lint itself, since building lint.jar files as part of android libraries isn't done yet (requires a bit more lint API stability), so I'll need to add a check for this. (There are two separate app compat checks; I forgot about this one when I mentioned the showAsMenu issue yesterday). Should be fixed by https://android-review.googlesource.com/93627.

-- Tor

[Christopher Orr]

On 06/05/14 19:20, 'Tor Norbye' via adt-dev wrote:
> On Tue, May 6, 2014 at 1:48 AM, Roman Mazur <mazur...@gmail.com
> <mailto:mazur...@gmail.com>> wrote:
>
> Currently 'ValidFragment' check produces an error if default
> fragment constructor in implicit.
> To be honest, I'm not satisfied with such a behaviour because it
> makes me add an empty constructor explicitly to a bunch of classes...
>
>
> That's a bug. I discovered it myself yesterday and fixed it:
> https://android-review.googlesource.com/#/c/93424/

I don't think that was a bug.

AFAIK, Android explicitly requires an empty *public* constructor for
Fragments. I believe Java implicit constructors have default visibility.

From the Javadoc:
"Every fragment must have an empty constructor, so it can be
instantiated when restoring its activity's state." (though here it
doesn't actually say "public")
http://developer.android.com/reference/android/app/Fragment.html#Fragment()

The Android Studio "blank activity with fragment" creates a Fragment
with empty public constructor, and various code samples on the Android
site show explicit public constructors, e.g.:
http://android-developers.blogspot.de/2012/05/using-dialogfragments.html

If you don't provide a public constructor, at some point when the system
attempts to re-instantiate your fragment after restarting your process
from the background, you'll likely run into this ClassNotFoundException:
https://github.com/android/platform_frameworks_base/blob/android-4.4.2_r2/core/java/android/app/Fragment.java#L596-599

Regards,
Chris

[Mazur Roman]

AFAIK implicit constructor visibility reflects the owner class visibility. Hence, constructor is public if fragment class visibility is public.

--
You received this message because you are subscribed to a topic in the Google Groups "adt-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/adt-dev/aKRNyi8OSBM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to adt-dev+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

---