I am trying to use the library DBFlow in Android. I have used it before and in the older version (2.2.1) it used a $Table.field. Now it seems to have another format where we reference a new class by "_Table".
Example:
int taxBracketCount = SQLite.select(count(Employee_Table.name))
.from(Employee.class)
.where(Employee_Table.salary.lessThan(150000))
.and(Employee_Table.salary.greaterThan(80000))
.count();
Where and when are these "_Table" classes created? How do I access them?
(Even if I wanted to use and older version, my newly created studio project do not create the $ files either. Some explaination of this, or both, would be nice)
You need to run a successful build for the files to be generated. Make sure your code can compile, so remove any references to the "_Table" classes and run your project first and then you should be able to access them.
I got weird errors recently as below, said it couldn't find those "$Table" classes, but actually they had been built and in there.
I commented and uncommented every new java files. And eventually I found that's because there is no "#PrimaryKey" in one model class of DBFlow.
So, you have to define the bloody "#PrimaryKey" for your DBFlow model classes( and don't forget to extends BaseModel as well).
PS: DBFlow Version 3.0.0-beta
/Users/XXX/code_projects/###/src/main/java/com/XXXXX.java:9: error: cannot find symbol
import com.XXX.databasemodel.XXX$Table
_Table classes and their corresponding methods to communicate with the database are created when you build your project. You can build it even with these errors, and they'll be created on that moment.
If you're still facing the issue, make sure you're adding the #Table annotation on top of your class, else they won't be created.
I have faced the same problem, but the reason was an absence of the annotation
#Table(databaseName = AppDatabase.NAME)
at the top of
public class AwesomeModel extends BaseModel
#PrimaryKey(autoincrement = false)
#Column #Expose long id;
public long getId() {
return id;
}
}
class...
Ok so I was also facing similar issue -
And like someone else has also pointed out, the app needs to build to solve this. But removing all _table references first and removing them is a long task. I followed following steps -
try to rebuild the app, it will fail
Now head over to Problems tab in Android Studio
Try to identify any issues other than _table - fix that issue and build again - voila!
Related
I have an annotation processing library that generates RecyclerView adapters in compile time.
I'm currently rebuilding it from the ground up with many changes and improvements, but while testing, I received a warning stating:
Resource IDs will be non-final in Android Gradle Plugin version 7.0,
avoid using them as annotation attributes
This is a problem because it means I won't be able to use R.layout variables in annotations.
I currently use it to associate the layout file's integer value with the R class variable name; this is to locate the layout file from the resource folder and later call inflate(layoutResId).
Currently, I solve this issue like so
Example
Given a simple ViewHolder annotation.
annotation class ViewHolder(val layoutResId: Int)
With the usage
#ViewHolder(R.layout.sample)
data class Sample(val text: String) : GencyclerModel
And the Generated R.layout class.
public final class R {
public static final class layout {
public static final int sample = 567541283;
}
}
When processing the ViewHolder annotation, the processor would receive the integer value 567541283.
In the first processing cycle, the processor would analyze the R class and create a table to map the integer to the layout name, in this case, 567541283 <-> sample.
With that info, I can iterate over the layout resource directory and find the layout file with the name sample.xml.
and I can also later call inflate(R.layout.sample)
The field will be non-final in the new version, thus throw a compile-time error.
An annotation argument must be a compile-time constant.
Possible solutions
(Butterknife solution) Creating a duplicate R class that will generate the R.layout variables as static final, thus removing my R class dependency.
(AndroidAnnotations solution). Using strings instead of the Resources class. I'm not too fond of this solution because it will cause issues if the layout is renamed or a typo.
I'm not sure how happy I feel about both, but I honestly don't see other ways to solve it.
If anyone has a better way to solve this, I would love to hear, and if not, which solution would you prefer?
Thanks
I'm linking the issue that I opened in the GitHub project in case you want to contribute.
Another solution would be adding a method to GencyclerModel which returns the layout reference and remove that reference from your annotation. I guess the only problem this approach is going to make, is your checking condition about the existence of layout file in your compiler. But using this approach you won't hardcode layout references in annotations and you'll get them from a method inside each model
I have tried AndroidStudio's code coverage feature and I have met a strange issue:
It is marks the tested class's name as 'not covered' code.
How is that possible? Is that a bug?
Picture here:
As you can see it has one method with 4 lines and each one of them is covered. So why is the red line at the class's name?
You are using a static method, so the class itself is never created as an object, therefore never testing that ability.
I tried the lombok #UtilityClass, it helped to ignore the class name and code coverage was improved to be 100%.
Since also a class with a static function has a default no-argument constructor, your code coverage tool will complain. A good way to solve this, is by adding a private constructor.
private EmailValidator() {
}
I'm using AndroidAnnotations in an Android Studio gradle project. I currently get error output from AA during compilation that says:
cannot find symbol class MyActivity_
The error output does not prevent building the application - its not really a compile error because the class is there, it seems that it is just an unfortunate timing issue with the compilation process.
Is there anything I can do to avoid these false-positive errors from AA? When there are "fake" errors shown every time I compile, its very easy to miss the real errors.
I had same error. To solve it I have revert my last changes and it has worked again.
I think it was either wrong optimized import(you must import generated classes eg. xxx_) or I injected layout by id what was not existed in the layout xml
Update
I figured it. My problem was what I had use private mofidier instead of proteced in
#ViewById(R.id.list)
private ListView list;
Try to see if you missed to fix some errors in the class MainActivity or in someone of his Bean member that you have annoted.
The problem doesn't have to be in MainActivty, but it is probably because of a private modifier which is used with Android Anotations (in injection, method declaration etc) somewhere in your code
Im trying to build the Contacts app from AOSP as a Android project in Eclipse. I can't find the reference
Calls.VOICEMAIL_TYPE
in code CallLogFragmentTest.java
private void insertVoicemail(String number, long date, int duration) {
Object[] values = getValuesToInsert(number, date, duration, Calls.VOICEMAIL_TYPE);
// Must have the same index as the row.
values[CallLogQuery.VOICEMAIL_URI] =
ContentUris.withAppendedId(VoicemailContract.Voicemails.CONTENT_URI, mIndex);
insertValues(values);
}
Even in my other Android environment the variable VOICEMAIL_TYPE does not exist?
Has someone done this, if so exactly what libs did you use?
VOICEMAIL_TYPE is found in CallLog.Calls, as you can see from the source.
Here are two reasons I can think of for why you are missing this:
You do not have all the right source code (i.e., your copy of CallLog does not have VOICEMAIL_TYPE)
You actually set up an Android project (with an android.jar as part of your build path), as VOICEMAIL_TYPE is marked as #hide, so while it is part of an OS build, it is not part of the Android SDK
There may be other reasons as well.
CommonsWare pointed me out in the right direction and I solved it by building the AOSP and then I got out/target/common/obj/JAVA_LIBRARIES/framework_intermediates/classes-full-debug.jar and added it first in my build path in Eclipse
I'm making a paid/free version of my app so have a 'Library Project' that the two apps use.
I'm trying to use Android Annotations to clean up my code:
http://code.google.com/p/androidannotations/
Unfortunately when I use this in my shared library project, one of my projects gets the error in Eclipse:
The type xActivity_ is already defined xActivity_.java /ProjectName/.apt_generated/lib/activities/
Because Android Annotations automatically creates a new activity with an extra '_' in the folder .apt_generated one of the apps is allowed to create this file, but the other gets the error "already defined".
Is there a way in Eclipse to resolve this? Or is it a problem with the Android Annotations?
This seems to be an AndroidAnnotations bug, and should be reported on the dedicated bug tracker.
AndroidAnnotations wasn't designed with this use case in mind, but this is still a very valid use case. The problem seems to be that the activity is generated in the shared library project, when it should be generated in each depending project, am I right ?
(please answer in the bug tracker)
This question is quite old, but I thought that I should mention android annotations now supports being used in libaries:
https://github.com/excilys/androidannotations/wiki/Library-projects
One caveat is that due to the way android library projects generate the R class, you cannot reference resouces directly inside the annotations. Eg, you cant do this:
#EActivity(R.layout.myLayout)
public class MyActivity extends Activity {
#Click(R.id.myButton1, R.id.myButton2})
public void someButtonClicked() {
}
}
Instead you must do this:
#EActivity(resName="myLayout")
public class MyActivity extends Activity {
#Click(resName={"myButton1", "myButton2"})
public void someButtonClicked() {
}
}
I just knew AndroidAnnotations (which seems a great tool!) but I think that if you do this using different projects (sharing the same library) your problem should be solved.