Android : Activity error in other package - java

This is my project stricture :
-com.android.test
--com.android.test.activity
---MainActivity.java
---SplashActivity.java
--com.android.test.ui
---ActivityBase.java
I created all activity in com.android.test.activity package and all activities extended from Base activity in com.android.test.ui package
But i don't know , when i creating activities on com.android.test.activity i see .R error in my Eclips , but when i creating activity on com.android.test package ,no need for importing the .R class.
I'm very beginner , please help

When you build an android project, the build tools generate a class called R.java. Because R is a class, it will exist in a package, just like all your other classes. By default, R will be generated in the package you've specified as the project package. For you, this should be com.android.test.
So your package structure is actually like this, even though R is in gen/, not src/.
-com.android.test
--R.java
--com.android.test.activity
---MainActivity.java
---SplashActivity.java
--com.android.test.ui
---ActivityBase.java
In Java, you will require an import statement if a class is not declared inside the package of the current class. So because com.android.test is not contained in com.android.test.activity, you will need to add import com.android.test.R; to MainActivity and SplashActivity, in order to use R in them.
If R is not being generated for you, check out Developing for Android in Eclipse: R.java not regenerating. I would possibly recommend learning to use IntelliJ IDEA, as I've encountered fewer strange build issues than in eclipse, but this is completely optional.
Another possible source of error is if you accidentally imported android.R, which is where the resources of the android SDK are referenced from. This could easily mess you up, since you could write code like R.string.foo and think you are using com.android.test.R.string.foo, but in reality, you are using android.R.string.foo, which may not exist. An easy way to find the problem is to explicitly say in your code, for example:
// you were originally getting an error here
MyActivity.this.getString(R.string.foo);
// try this to get a more obvious error, or see if it fixes it
MyActivity.this.getString(com.android.test.R.string.foo);

Related

Creating Java Packages in IntelliJ

I've been using Eclipse for a while and I'm having trouble understanding what's going on with my first project in IntelliJ. I've read the documentation, and searched other questions, but I still can't seem to grasp it. I think there is something wrong with my project structure. This is what my structure currently looks like;
I'm trying to run the JavaForLoop class, but whenever I do, compilation fails because I have errors in the StringMethods class of the strings package. My question is why would that prevent compilation if the two classes are in separate packages? Neither class uses the other, and they both have the appropriate package declaration statements. With a similar structure in Eclipse, this would work. Should I be using a different project structure?
By default IDEA adds Build Configuration which is executed before launch and includes following steps (taken from here):
Compiling source code in the source path of a module and placing results to the output path.
Compiling source code in the test path of a module and placing results to the test output path.
Creating copies of the resource files in the output path.
Reporting problems in the Messages tool window.
check if it's your case in Edit Configuration screen and if so, remove it.
To use a class from a different package you must declare a import statement to the class.
In your JavaForLoop.java add the import before the class statement (and after package declaration where its the case)
//package ...
import strings.StringMethods;
//public class JavaForLoop { and the rest of the code
Intellij uses regular javac, which will fail to compile if you have errors anywhere in the code.
Eclipse has it's own compiler, that allows to compile and even run code that has compilation errors, causing a runtime exception if any part of the code that has errors is run. This allows you to run parts of the code that work even if other pieces of code are failing.
The simple solution is to resolve your compilation errors. You can also use the eclipse compiler with Intellij, but I've never done this so I can't comment on how well it works.

FATAL EXCEPTION: main java.lang.NoClassDefFoundError: external library.jar.class Android studio

I am developing an android app which process speech and I have speech basic project (dependency for android project) ready on JAVA so I compiled JAVA project in eclipse in JAVA 7 compiler and exported that java project as a runnable jar.
I put this jar into my android studio project's libs folder and by right clicking selected AS A library, I got build successful message. But when I try run the android project it gives me error saying,
FATAL EXCEPTION: main Process: in.automator.automator, PID: 4242
java.lang.NoClassDefFoundError: jar_filename.Storage.class_in_jar_file
but the said class is there in the jar file, the only doubtful thing is the mentioned class file looks something like this
import javax.sound.sampled.AudioFileFormat;
import javax.sound.sampled.AudioFormat;
import javax.sound.sampled.AudioFormat.Encoding;
import marf.util.InvalidSampleFormatException;
public class MARFAudioFileFormat extends AudioFileFormat {
....
...
....
}
It refers javax.sound.sampled, so possibly that might causing the problem.
I tried searching on the google for the problem but didn't got the solution which can resolve the issue. I tried everything.
I am using JRE 7 in android studio and exporting java project in Compiler & itself.
How to resolve this error?
Thanks in advance.
You are correct, the problem lies in the fact that the library you're trying to depend on, in turn depends on the javax package hierarchy. Android does not provide javax, so those classes don't exist at runtime (even though they do exist in your computer's JDK, so your compiler doesn't complain - it's basically the same as not having a particular DLL installed that a program on your PC needs).
The NoClassDefFoundError is being thrown on the class that first references the invalid class dependencies, which is probably what's confusing. That class may indeed actually exist in your jar, but it requires classes that don't exist in order to complete its definition - so in effect, your class is not fully defined.
The only way around this is to figure out a way to do whatever you're after, without the javax namespace. I have heard of a few attempts to try to port javax.* into Android, but they never end well - many of the javax classes end up boiling down to native calls, which also won't exist on Android.

Java disutil CoordinateConversions import problems

I'm writing a Java class that will be used to send PDUs across a network- to do this, I am following the tutorial at: Tutorial
In the example, the line:
double lla[] = CoordinateConversions.xyzToLatLonDegrees(c);
appears towards the end of the class, and I see that CoordinateConversions has been imported with the line:
import edu.nps.moves.disutil.CoordinateConversions;
I have tried using the xyzToLatLonDegrees(); method in the class that I am writing- calling it in the same way as is done in the example. However, for some reason, I get a compile error that says:
CoordinateConversions cannot be resolved
on the line where I'm trying to use it, and
The import edu.nps.moves.disutil.CoordinateConversions cannot be resolved
on the line where I am importing it.
Does anyone know why this is, and how I can fix the import, so that I can use the xyzToLatLonDegrees() method?
You need to have the CoordinateConversions class on your classpath. Either by obtaining the source and dropping it into your project (possibly adjusting package names, and only if the license allows), or by finding a JAR containing that class and adding it to your build path in your IDE.
You probably need to download the Java files from here.

NoClassDefFound error with OrmliteSqliteOpenHelper

I have a class which extends OrmliteSqliteOpenHelper in order to provide a persistence module for an Android application. The problem is, whenever I access this class from the test project in Eclipse, it throws a NoClassDefFound Exception. The source code appears to be fine as the package is imported and Eclipse has no highlighting to indicate anything will go wrong, but it does.
Here's the kicker: not only does everything else in the project work fine when accessed from the test project, but when I move this file into the test project voila it works perfectly! The issue is that it needs to be in the actual project in order for other components to make calls to it. Has anyone ever encountered this error or have any idea where I might be going wrong?
The class path is set correctly as all the other classes work and the test project always has the main project added to its class path. I also tried moving the OrmliteSqliteOpenHelper object to an inner class: this allowed the outer class to be visible and touched but as soon as it tried to instantiate the inner class the same error occurs. Also, if I copy this file into both projects in the same package, an error occurs stating "class ref in pre-verified class resolved to unexpected implementation" whenever something in the main project tries to access this class. Clearly, there is some difference in the way the class is being compiled/handled between the two projects.
I'm quite stumped :/ Thanks a ton for any assistance!
Well friends, I seem to have hacked together a solution for this issue:
I linked the entire 'src' folder from the main project into the one for the test project. Now, when it goes searching for the particular package my file is located in, it finds the file in its own source tree first. Hooray!
Why does this work? I haven't a clue, perhaps someone could enlighten us to that fact.
Does it work? For now...
There is how I fix the problem:
Remove OrmLite from Build Path of the test project.
Export them from the main project.

eclipse 3.4 (ganymede) package collision with type

We have a package that ends with exception e.g.
package a.b.c.exception;
Our code base had no issues up till eclipse 3.3, however when we shifted to eclipse 3.4, it started giving errors related to this package:
"The package a.b.c.exception collides with a type"
When I refactor the package name to a.b.c.exceptions, there are no issues. Is this due to a bug in eclipse 3.4 or is there some setting to rectify this behavior?
It's because you have a class named exception (with a lower case "e") in the a.b.c package and a package named a.b.c.exception.
It causes a name collision because if you have the code a.b.c.exception.doSomething(); - does that mean you want to call the static doSomething() method in the a.b.c.exception class? Or does it mean there's a class called a.b.c.exception.doSomething that you're trying to invoke the constructor of?
Stick with the Java naming conventions - packages all lowercase, classes starting with an uppercase and camel-case after - and you'll never see this problem.
==========EDIT==========
This is the only legitimate reason this error should be showing up...
It doesn't have to be in your project directly, it could be in another project or library that your project depends on. This should show you any occurrences of the class anywhere on the build path or your project : Hit the Flashlight looking button in the Eclipse toolbar -> Choose 'Java Search' -> enter a.b.c.exception in search field -> select 'Case sensitive' -> select 'Type' in 'Search For' -> make sure all options are selected for 'Search In'.
Are you using any tools that generate classes? Could they be putting them into the build directory of your project? When you see the error, if you go to the project's build directory, and go down into the a/b/c/ directory do you see a .class file for 'exception'?
Of course Eclipse in general could have a bug (though I'd expect there would be a bug report in Eclipse 3.4 and you'd be able to find more complaints if it was...), your Eclipse install could be broken in some way (Can anyone else open your project in Eclipse 3.4? Could you do a clean Eclipse 3.4 install in another directory? Does the error appear there?), or your project could be messed up in some way (Create a new project with no dependencies other than the JDK, create the a.b.c.exception package in your new project, create a class in your project to import a.b.c.exception.*; and see if the error occurs.).
In Java you can not have a class name that is the same as a package name.
That means the JDT package must have enforced that rule only in 3.4
See bug 63668 for instance.
As Nate comments:
A class named Exception won't prevent you from creating package exception.
Case matters.
Also remember the full name of a class includes the package it's in.
So a.b.SomeClass (class name) is different from x.y.SomeClass (package name).
There would be no name collision here.
The class name and the package name have to match in both case and package to cause this error.
See his more accurate answer.
I encountered a similar problem in a huge code base that I inherited. It turns out that the clash was caused by an partially qualified class name in a JavaDoc link.
To paraphrase, Eclipse was telling me that I had a package/type clash for a.b.c.d. when compiling a.b.c.d.London. Doing a java search on the code for a.b.c.d revealed that Eclipse thought that a JavaDoc comment in a.b.c.Paris was a match. The JavaDoc comment contained {# link d.NewYork}. When I changed the it to read {#link a.b.c.d.NewYork} the compilation error was resolved.
It should also be noted that NewYork was not imported into the Paris class as it only appeared in the JavaDoc comment. This also made it un-resolved in its abbreviated form and clicking on the link in the comment did not work. Making it an absolute reference also makes the JavaDoc link work.
I know this will sound silly, and possibly too simple to be true, but I solved this exact same error message by:
Deleting the entire line of the package name causing the error message.
Saving the .java file(this triggers a new error on the same line stating "The declared package "" does not match the expected package"), which it should do.
Re-typing the original package name onto the same line.
Saving the .java file.
Could not tell you why this worked, but it did, and Eclipse stopped throwing a tantrum on the spot.
Safe typing and speedy coding.
-Goodge
I changed one of the compilation option in eclipse and the problem disappeared.
Under workspace properties:
Java Compiler -> Errors/Warnings ->
Change 'Unused import' from 'Warning' to 'Ignore'.
If you have a class Foo, you cannot have a package that ends with Foo, such as com.my.Foo.
Also if you are using maven style, you have resources in your project under something like src/main/resources
The folders in your resources also have a package style and there, also, you cannot have a folder that contains the name of your class.
you will definitely encounter this problem when developing a Jenkins plugin according to the recommended conventions.
if you follow the Jenkins conventions, and you create a builder in a class named MyBuilder in package x.y then you are also supposed to place your .jelly in a resource folder named x.y.MyBuilder. This will result in the above problem.
However, if you name your resource folder x.y.myBuilder (notice lower case 'm' in myBuilder), unlike the recommended convention, the plugin will still work as you intended

Categories

Resources