I created an app which runs without any problem
But it contains lot of warnings
Here my question?
What problem will arise when app contains a warning
Thanks in advance
I usually use the warnings to clean up my code in the following manner:
They tell us which variables are never used locally. Hence, DELETE them.
Use of deprecated stuff in android, hence keeping my code up-to-date.
Removing unused imports.
Useless assignments to variables.
Errors in Manifest like not setting "allowBackup=true/false"
etc etc...
No errors, but only warnings, means your code will run well. But the code may not be the best.
The difference in an error and a warning is that an error doesn't allow the code to be compiled. A warning on the other hand is a message from the compiler telling that you have something weird or unnatural in your code, but it's still able to compile.
A warning should be interpreted as "this is weird, but if you know what you're doing, then it's OK".
For example, pointer casting (from one object type to another object type) is a common source of warnings, but if you know what you're doing and you're confident it will not fail, you can ignore it.
Warnings are not errors, and as others have said, if you know what you are doing you can ignore them. But remember that warnings are the compiler trying to help you, and programming can be difficult enough that you should be grateful for any help you can get. A good way can be to ignore only those warnings that you know exactly what they are caused by, and be very suspicious of any others. And always try to get rid of all the warnings, so the important ones don't get lost among all the unimportant ones.
Warnings are only indicators that there's something wrong, but this something isn't critical for running your app. Sometimes it's just that an imported code isn't used at all, another time it's a hint that a code can throw a NullPointer that you aren't catching right now. But summing up, warnings are not critical - at least during development time.
So far, you should only care about the errors that will prevent you from compiling your app.
It depends upon the types of warnings you have. If you have Deprecated Warnings then
You can configure the Java Compiler to ignore the Deprecated Warnings. I'd suggest to configure this setting for the specific project, not globally. To do so, right-click on your project and go to Properties > Java Compiler > Errors/Warnings. Click Enable project specific settings and then unfold Deprecated and restricted API and select Ignore for Deprecated API.
This will disable all deprecated warnings though.
Related
I don't know about it completely. I think that it allows the deprecated code to be compiled. I want to know if the code under this line will always be run or not and does it depend on the software like Eclipse, studio you are working on?
Check this out.
Using suppresswarnings just tells the compiler not to warn you. It's still valid to use deprecated code, but usually there's a better way you should use instead.
The code will be compiled with or without it. It tells your IDE not to even warn you about it. Sometimes you have a good reason for using deprecated code. Putting this on those functions/classes reduces the number of warnings reported, which makes it easier to find important warnings of real problems.
Disables compiler warnings... In this case, deprecated code... Just for your information, for show clean code
I need to remove all of Android Studios "This can be changed to" warning flags. I know I can reduce all the warning flags with the slider from inspections to Syntax.
I don't know if Syntax covers every non style warning, or if it also includes actual warnings. If it does, can you link me the documentation that says so? I need actual hard proof. I can't find much talking about the syntax warning highlighting.
I can ignore these, no problem but I'm seeing that my team is treating these like real warnings. When you take an existing code base and a team.. we waste a ton of times with hundres of personal style errors. I like to do if(boolean == false), Because it's CLEAR. A lot of these suggestions make the code, bleedin edge 1980s style, save every character efficient, but as readable as.. well.. 1980s code..
For example, we just spent half an hour trying to figure out if we had an error in an if statement, because it "could" have simplified it sorta.
Or my favorites where it tells you to change it, then tell you to change it back..
Also yes I know I can add suppressions, which cause errors in my coworkers Eclipse. . .
See if this helps, Preferences → Editor → Inspections,
Disable the those you don't want, eg. Pointless boolean expression under "Control flow issues"
reference: https://www.jetbrains.com/idea/help/disabling-and-enabling-inspections.html
You can also add this line above the pointless boolean you want to ignore. I use this a lot when using BuildConfig variables as they appear constant but are really not as they are controlled by the gradle build system.
//noinspection ConstantConditions,PointlessBooleanExpression
R.java is not generated. I tried several strategies like cleaning and building etc, none of them seemed to work. Please dont mark this as duplicate since I have tried all the strategies that has been told in other questions.
A common problem with not generating the R file is that you have an error somewhere in your code. Something doesn't match, isn't imported, etc. The R file isn't built until your code can be compiled without errors, even though sometimes it does anyway. I can't give you a reason why it does that, but make sure you don't have errors.
Go to the bottom of your eclipse view and look for a tab that says "Console". It may just show you that youve declared something in one of your layouts that doesnt make sense to the compiler or something like that. Also check the error log and the problems tab.
I followed this tutorial and it worked perfect for me. Now I want to add fix issue functionality. I am using Eclipse.
In Lint Warnings view we have Fix button, can I handle it?
For example when we have hard coded string (android:text="Test") in TextView when you click CTRL + 1, help pop up opens with possibility to Extract String. What I am trying to do is to add extract hard coded dp values functionality.
Also it would be great if you could point me where I could find source code of already implemented lint issues.
Thank You.
Lint checks can be written standalone:
Writing a Lint check: http://tools.android.com/tips/lint/writing-a-lint-check
Lint checks source: https://android.googlesource.com/platform/tools/base/+/master/lint/libs/lint-checks/src/main/java/com/android/tools/lint/checks
Lint fixes are part of the ADT pluggin: http://tools.android.com/tips/lint
Lint is integrated with ADT 16 and later. The integration offers a few features above the command line version of lint:
Automatic fixes for many warnings
Lint gets run automatically on various editing operations
Ability to suppress types of errors as well as specific instances of an error
Ability to configure issue severities
Jump directly to the problem source from the lint view
Consider making a plugin for your Custom lint check in IntelliJ Idea Community edition, downloaded from https://www.jetbrains.com/idea/download/, and follow the tutorial at http://www.jetbrains.org/intellij/sdk/docs/index.html.
After then you will come to know that to handle light bulb for the fix of your custom Lint warning you have to extend the IntentionAction class particularly.
And then search for deploying the plugin in the tutorial and finally you will come to know to put the jar of the plugin thus created in the Android Studio/Contents/plugins folder.
I understand there is the LogCat view to check the messages logged but I can't make sense of it.
When debugging (I use Java primarily) I've been accustomed to stepping over each line of code and finding out the exact point where the program crashes and then doing something about it.
How can I do this with Android development? Is there a way to precisely locate the line which is causing the application to crash?
I can't understand what to make of/how to read the LogCat messages and when I try to step over (using the F9 key or the 'Debug' option in Eclipse) it keeps opening new tabs for inbuilt classfiles (like Instrumentation.class etc) and after pressing F6 a few times over again the app crashes showing 'The application has stopped unexpectedly. Please try again'
Can someone tell me if there's something to be done in a way that I'm not doing here?
Thanks!
Btw if it helps, here's the generated log:
http://pastebin.com/EaqaWUdS
You are using a resource id that doesn't exist at line : 93 of com.site.custom.ModAdapter.getView(CustomListProjectActivity.java
--EDIT : add explanations
You will read a logcat stack trace in the same way as you did in Java : read bottom up and the culprit is the last line of your classes (before the code gets into the android sdk code).
You can do it the other way around, and start from top, stopping at the first class of yours and discarding android classes.
The same reasoning applies when debugging : step into your methods if needed and step over all methods of the SDK unless you want to debug them (and usually you don't, if you really suspect a bug inside the SDK, check the source at grepcode to see the inner mechanics of the android sdk class you are interested in).
Sometimes it gets difficult to track bugs on android, especially for widget layout related bugs because you can only see the code that is executed by the android platform, no code of your is executed, only your data are read from an xml file for instance. If something breaks here, it can be harder to debug. In that case, apply the dichotomy method : remove half line, if the bug doesn't show up, then readd your lines, remove half of them, etc...
It is the same like in java. Basically you need the sources to open the java files instead the class files. Google shows you how to add the sources.
Basically you debug android while staying in your own classes. I barely look into the android classes as the most issues are, of course, located in my own classes.
So just debug like you already do but don't step into methods/classes you don't own unless you have the sources added to your sdk. Even if you have, there might be some classes that aren't open source, so you can't step into the sources there. (Basically all Google API classes)