Skip to content
This repository has been archived by the owner on Mar 16, 2021. It is now read-only.

Feature: Lint Checks #158

Merged
merged 26 commits into from
Sep 24, 2018
Merged

Feature: Lint Checks #158

merged 26 commits into from
Sep 24, 2018

Conversation

jreehuis
Copy link

@jreehuis jreehuis commented Aug 27, 2018

Description

This implementation adopts and updates #111.
Fixes #100

The updates include:

  • Using the now stable Lint version to use UAST
  • Bundles the Lint checks with TI
  • Fixing the detection scope so Android Studio will report the error in the editor
  • Creating an own TI Lint Category
  • TiIssue is now a sealed class
  • some Kotlin tweaks

How to Test

Play with the following scenarios:

  • Remove the implements HelloWorldView in the HelloWorldActivity of the sample app
  • Remove the implements HelloWorldView but override provideView() in the HelloWorldActivity of the sample app
  • Use TI v0.9.1-SNAPSHOT of this branch in another project and have an TiActivity which does not implement the given TiView subclass

Copy link
Contributor

@StefMa StefMa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Haven't testet it yet.
But code looks good so far 👌

// According to https://github.com/googlesamples/android-custom-lint-rules/tree/master/android-studio-3
// the lint version should match to the used Android Gradle Plugin by the formula "AGP Version X.Y.Z + 23.0.0"
// E.g. "AGP Version 3.1.3 + 23.0.0 = Lint Version 26.1.3"
lintVersion = '26.1.3'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could also calculate this by ourselfs, right? 🤔
Just extract the AGP version and "add" the values to 23.0.0 ...

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, we can calculate this ourself. But I would prefer to change that still manually:

  • It is stated "should" and so the actual version might differ from the formula
  • Google recently just decoupled the Support Lib Versions and so it might be that this version gets uncoupled from the build tools version aswell

@@ -0,0 +1 @@
# ThirtyInch - Lint
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No one of our modules have its own README.
Even if this brings no value I prefer to remove it

compileOnly "com.android.tools.lint:lint-api:$lintVersion"
compileOnly "com.android.tools.lint:lint-checks:$lintVersion"

testImplementation "org.jetbrains.kotlin:kotlin-stdlib-jdk8"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This dependency is already implement as a implementation dependency.
Because testImplementation extends implementation there is no need to declare it again


sourceCompatibility = 1.6

defaultTasks 'assemble'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is that really needed? 🤔
I prefer to remove it.
Running gradle without any specific task is not that common...

}
}

sourceCompatibility = 1.6
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need this?

"com.pascalwelsch.compositeandroid.fragment.CompositeFragment"
)

class MissingViewInCompositeDetector : BaseMissingViewDetector() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't know if it make sense because we wanted to drop the support vor CompositeAndroid anyway, right @passsy?
But as long as it is implemented now and work we could leave it like it is...

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct, as long it is still present we should support it.


override fun applicableSuperClasses() = TI_CLASS_NAMES

override val issue: Issue; get() = ISSUE
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is here an semicolon?
Should be removed. See also this style guide.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This semicolon is needed to keep it all in one line. But I removed the getter overriding completely.

companion object {
val ISSUE = MissingView.asLintIssue(
MissingViewInThirtyInchDetector::class.java,
"When using ThirtyInch, a class extending TiActivity, TiFragment or CompositeActivity " +
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This issue don't catch the issues for the CompositeActivity.
Please adjust the comment

@jreehuis
Copy link
Author

@StefMa I addressed all your comments. Would be great if you could have another look on this PR. :)

@jreehuis jreehuis added the lint label Sep 12, 2018
@StefMa
Copy link
Contributor

StefMa commented Sep 12, 2018

Hey, sure.
After I am back from my sick leave I will take a look into it 👍

private const val PROVIDE_VIEW_METHOD = "provideView"
private val TI_CLASS_NAMES = listOf(
"net.grandcentrix.thirtyinch.TiActivity",
"net.grandcentrix.thirtyinch.TiFragment"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have a TiDialogFragment which will not be noticed as issue.
Please add it 👍

@StefMa
Copy link
Contributor

StefMa commented Sep 17, 2018

Works 🎉
bildschirmfoto 2018-09-17 um 10 23 26
bildschirmfoto 2018-09-17 um 10 23 45

@StefMa
Copy link
Contributor

StefMa commented Sep 17, 2018

What does not work:

abstract class GalleryDetailsActivity : TiActivity<GalleryDetailsPresenter, GalleryDetailsView>()

class CameraGalleryDetailsActivity : GalleryDetailsActivity() {

No Lint issue will be shown :(

@StefMa
Copy link
Contributor

StefMa commented Sep 17, 2018

Works also with Java 🤘
bildschirmfoto 2018-09-17 um 10 31 16
bildschirmfoto 2018-09-17 um 10 31 46

@StefMa
Copy link
Contributor

StefMa commented Sep 17, 2018

Something like this shouldn't be an issue:
bildschirmfoto 2018-09-17 um 10 33 05

Ok, maybe this is not an issue because it will never happen in real world

from(configurations.lintChecks) {
rename { String fileName -> 'lint.jar' }
}
into 'build/intermediates/lint/'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it common to move the lint check into the final AAR? 🤔
What about to publish a separate jar/artifact and make this optional? 🤔

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having custom lint checks for a library is only really possible since AGP v3.0. Before you had to manually copy a lint.jar to specific folder and so on.
So not a lot libs ship their own lint checks with the AAR atm.

But in my view it is way more convenient if you have them out-of-the-box. If you do not want them, you could deactivate them in the Android Studio preferences anyway.

@StefMa
Copy link
Contributor

StefMa commented Sep 17, 2018

Other than that it looks great 🎉
Thanks @jreehuis

@jreehuis
Copy link
Author

Thanks for the extensive tests! 😃
Especially the abstract class scenario will get complicated... 😡
I will see to solve it. But definitely a real world case. Thanks for pointing to it.

@jreehuis
Copy link
Author

Something like this shouldn't be an issue:
bildschirmfoto 2018-09-17 um 10 33 05

Ok, maybe this is not an issue because it will never happen in real world

In my view this is correct. StuffActivity could be also used separately and so we should highlight this error.

@jreehuis
Copy link
Author

What does not work:

abstract class GalleryDetailsActivity : TiActivity<GalleryDetailsPresenter, GalleryDetailsView>()

class CameraGalleryDetailsActivity : GalleryDetailsActivity() {

No Lint issue will be shown :(

OK, wasn't that hard than expected. This scenario should also be covered now.

@jreehuis
Copy link
Author

All done.

@StefMa
Copy link
Contributor

StefMa commented Sep 24, 2018

Issue created as discussed.
Merged ✅

Thank you @jreehuis 🤘

@StefMa StefMa merged commit d761dbe into GCX-HCI:master Sep 24, 2018
@jreehuis jreehuis deleted the feature/lint_checks branch February 19, 2019 09:01
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Development

Successfully merging this pull request may close these issues.

3 participants