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.
Related
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!
I'm creating a new module in android studio, and I want some of the classes to be hidden to outside of the module, I mean, that the classes could just be used internally in the module, but not externally. Is it possible? How could I achieve that?
Thanks in advance!
EDIT: I doubt it's possible to have module-visibility, but the closest you can use is package-visibility, for which you do the following:
Don't make the classes you intend to hide 'public'. Keep the default visibility, which is only seen within classes of the same package. Other public classes within this same package can act as your external interface to your module.
class PrivateToPackageInModule {
}
public class InterfaceOfModule {
private PrivateToPackageInModule ptpim;
}
For anyone that happens to stumble upon this post, there is now a keyword called internal which offers exactly the functionality that OP was looking for.
Documentation link
So I have just started running through the tutorial located here
Even though it starts off easily enough, with everything being described, the second chapter rushes you through action bars.
I have managed to import appCompat; which was located at C:\Users\New\Desktop\Programmin' languages\Android dev\adt-bundle-windows-x86_64-20130522\eclipse\sdk\extras\android\support\v7\appcompat - for me.
After importing appCompat I referenced it by going to properties>android and then the adding it to libraries.
What is confusing me is that the compiler allows me to write
public class DisplayMessageActivity extends ActionBarActivity {
without any errors; though I have referenced
android:support:v7:app:ActionBarActivity
so I didn't think that would give me an error.
Errors are coming from things like action_search (which I'll assume is a referenced xml) and openSearch() (a referenced class) - in my java activities
and #drawable/tab_unselected - which is located in my drawable-hdpi (under res).
I'm assuming that the person who wrote the tutorial presumed that my project would get these resources from the appCompat directory, but for some reason it isn't.
Please help, because the next chapter just goes on to describe how to develop new things - without addressing issues that could arise first.
Please see here on how to properly include the appcompat libraries in your Android project.
I'm trying the tutorial located here
I have compiled sample code for openCV without issues - so I'm sure I have all the necessary things installed for opencv. I've added the opencv library to my project and I'm compiling with java 1.6 (java 7 doesn't work with opencv4android right now AFAIK). I added the opencv library as a resource as well.
However, the sample code doesn't make sense to me once it gets to step 5 under Hello OpenCV example.
public void onCreate (Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
mView = new HelloOpenCVView(this);
setContentView (mView);
}
Is the code I'm talking about, I immediately get the error "mView cannot be resolved to a variable". mview is consistently used without declaration throughout the code -- is it from another file I'm supposed to be importing? Any ideas? Thanks
B
The "m" in mView indicates that it is a member variable. It's a language naming convention used in most Android apps (you can read more about it here if you feel so inclined). So just add the following inside MyActivity:
public class MyActivity extends Activity implements HelperCallbackInterface
{
private HelloOpenCVView mView;
... // rest of class
}
That should resolve your mView cannot be resolved to a variable error, which is just a scoping issue.
On that page it says to refer to the 15-puzzle sample for more details. I suggest taking a look at it here.
I agree it is a little confusing. Since OpenCV is open source, feel free to send them a GitHub pull request with an amendment to this part of the documentation.
How can I use an Android Library Project, and overwrite certain classes in the "final project".
In other words, I want to reference a library project, and at the same time, change some of the code..
Probably not quite what Android Library projects are all about but you could achieve that by using the interface and class inheritance features of the java language itself.
Library project seem to deal well with merging/overriding resources from the parent in the child and letting you use one codebase with varying app package names.
Given your updated comment about using library projects to have one edition of the app that uses AdMob and one that doesnt, I've revised this answer...
Assuming you dont mind packaging the AdMob library (~138KB) in with your full/paid edition, the simplest thing to do would be to extend an Applcation class and therein declare an enum and a static method to decide whether AdMob ads should be shown.
public class Application extends android.app.Application
{
public enum EditionType { LITE, FULL};
public static int getAdVisibilityForEdition(Context ctx)
{
if (EditionType.valueOf(ctx.getString(R.string.edition)) == EditionType.FULL)
{
return View.GONE;
}
return View.VISIBLE;
}
}
You'll add this class to the library project only. In all three of the projects you'll need to add an entry to /res/Strings.xml as such:
<?xml version="1.0" encoding="utf-8"?>
<resources>
<string name="edition">LITE</string>
</resources>
It doesnt matter what the value of this string is in the library project, but you'll vary it in the paid vs. ad supported editions using FULL and LITE respectively.
Finally, to make your activities responsive to these values call something like this in your onCreate() or onResume():
View ad = (View)this.findViewById(R.id.your_adMob_view_id)
ad.setVisibility(Application.getAdVisibilityForEdition
(this.getApplicationContext()));
This will work fine with AdMob as the AdMob code wont actually try to get an Ad if the view is not visible.
If you really dont want to have the extra 138K for the AdMob jar and the manifest permissions needed for it in the full edition, there are more elegant ways to do this but would involve using some kind of wrapper around the AdMob stuff and either varying the xml layouts between the editions (to include the AdMob view or not) or inject the AdMob view into the layout programatically.
Hope that helps.