While some of them are built into the IntelliJ IDE as standard, those which are Android specific are enforced by lint. If you have used Android Studio you should already be familiar with these inspections. However lint is only a command line tool, it is further integrated with the IntelliJ inspections via the Android plugin for IntelliJ. From what I understood the annotation check was enforced by the lint tool, which is a static code analysis tool developed by the Android team to help inspect your code. For those of you not using ButterKnife I would advise you to take a look at it, although it may replaced by data binding in the future.Īfter I realised annotation processing wasn’t the way to go, I decided to try and emulate the functionality of the annotation (which I discussed in my last post). The ButterKnife library is a good example of this use case. This was not useful for my purposes as the standard annotation processing mechanisms from the API are more geared towards code generation, being used in conjunction with a code generation library like JavaPoet. The standard Java API provides you with only one way to make use of annotations, which is the annotation processor. You need to write more code to search for the annotations and perform some action.
An annotation does nothing in and of itself, it only serves to annotate your code. The only similar mechanism available in the standard API is the annotation, but this was not suitable as implies you shouldn’t use the method at all, whereas I simply wanted to warn anyone calling the method to be careful.Īll this does however is fix the compiler error. This annotation indicates the caller of the method should be careful when invoking it and raises a warning inside the IDE at the call site.
Following this methodology I annotated the culprit method with a new annotation called which does not yet exist. It is a method of programming by which you work backwards from what you want to where you are. Coding by wishful thinking is something I do quite often. If a future developer cannot immediately understand which method is the source of the issue it may take them a long time to even find the JavaDoc which explains the problem.Īt this point I decided to use the power of wishful thinking. This is because the StackOverflowErrordoesn’t originate from any one particular method call, it’s just the result of too many method calls executed by the infinite loop. The stacktrace produced by the StackOverflowError is not helpful in pointing you to the source of the problem. This may be enough, however due to the nature of the bug it is not obvious it arises from calling this method.
0 kommentar(er)
