Maybe we could provide some parts of "functional programming" into Java through AndroidAnnotations.

I'm thinking of doing a thing that would be a bit like what jcurry does (http://code.google.com/p/jcurry/). It uses project Lombok to transform annotated methods into Guava functions.

We could provide First class functions in generated code, based on some annotated method.

So, you would have something like this :

@EFunction
Integer myFunction(String param) {
}

And you would do :

Function<String, Integer> myF = SomeGeneratedClass_.myFunction(activityInstance);

Integer result = myF.apply("Test");

The idea here is that we could then use some Java "functional" frameworks such as Guava, but also introduce Functions for some AndroidAnnotations features.

We could also detect whether Guava (or any other fwk) is in the classpath, and generate an instance of one class or another based on that. For example, we could have the AAFunction interface, and the AAGuavaFunction interface that extends Function from Guava and AAFunction. All those interfaces would have the same apply method signature.

This is really a draft, the idea is not mature yet, any comment / suggestion is welcome!

The First class function might be part of the "enhanced subclasses". In that case, we could create one instance per instance of enhanced subclass, so MyActivity_.myFunction(activity) would always return the same function instance if called with the same instance parameter.

Of course, static annotated method wouldn't need any instance param : MyActivity_.myStaticMethod_()

We need to document the Injecting Html wiki page wiki page.

@BluePyth you implemented this, so it would be great if you could document it as well :)

Original issue was here: http://code.google.com/p/androidannotations/issues/detail?id=95

Merge commit: 3c11139

We have a CI server hosted by CloudBees, here :

https://androidannotations.ci.cloudbees.com/

It still doesn't work, but it seems that it's related to CloudBees Android support, we have a support ticket open.

Next step could be to automatically deploy snapshots, but I don't know if that's feasible (may require some sort of authentication).

If would be great to have a Maven Archetype to easily create a new Maven + AndroidAnnotations project.

Any help appreciated on that subject (@slandelle, @BluePyth we need you!)

py.ricau, Jan 5, 2011
We must find out if we can read the res xml file at compile time.

For instance, it would be nice to check at compile time that a view id exists in a layout.

If anyone has knowledge on this subject when dealing with annotation processing, please let us know.

py.ricau, Jan 12, 2011
Emmanuel Bernard told me that they were reading some hibernate conf files at compile time for Hibernate metadata builder. I'll dig in that direction.

py.ricau, Mar 11, 2011
This does not seem feasible, since Android res files are not in the standard Java resource folder.

See [http://opensource.atlassian.com/projects/hibernate/browse/METAGEN-12 METAGEN-12], they have the same problem with files in META-INF/.
Status: WontFix

py.ricau, Apr 6, 2011
In METAGEN-12, they work around this using Class.getResourceAsStream(). They can do so because META-INF is available in the classpath. However, it's now the case for the AndroidManifest.xml file (as well as res/* files)

We were able to read it using a dirty trick (see http://code.google.com/p/androidannotations/source/browse/trunk/AndroidAnnotations/src/main/java/com/googlecode/androidannotations/helper/AndroidManifestFinder.java?spec=svn752&r=752).

Now that we actually read the AndroidManifest.xml file, we may also read the res/* files, such as res/layout/* to check that the referenced ids in code exists in the layouts.
Status: Accepted

py.ricau, Apr 17, 2011
It seems that Robolectric reads the layout files in a Junit runner... which means they have probably done that in Java, and it might actually help us.

http://pivotal.github.com/robolectric/

py.ricau, Apr 17, 2011
The interesting package : https://github.com/pivotal/robolectric/tree/master/src/main/java/com/xtremelabs/robolectric/res

@johngray1965, Dec 28, 2011
What steps will reproduce the problem?

1. android update project --path .
2. ant debug

What is the expected output?
A successful ant build.

What do you see instead?
An error in the packaging:
java.lang.IllegalArgumentException: already added: Lcom/googlecode/androidannotations/annotations/AfterViews;

I thinks AfterViews has been included twice.

What version of AndroidAnnotations are you using?
2.2

On what operating system?
Both Win7 and Ubuntu

I see this consistently across several projects that build fine in Eclipse, and build fine on the cmd line if we remove androidannotations.

This really makes it hard to use androidannotations with an automated build.

@matboniface, Dec 28, 2011
This error is thrown by dx command when two classes with the same name and package name are detected.

Have you placed both the androidannotations-X.Y.jar and androidannotations-X.Y-api.jar in the "libs" folder of your project ?

All the jars installed in the "libs" folder are directly passed to the dx command, and so, they are packaged in dex format in your apk file. This is not good because a lot of code that is not used at runtime is embedded in your apk .

The only (relatively acceptable) workaround I found is :

• Remove androidannotations-X.Y.jar from the "libs" folder (let the androidannotations-X.Y-api.jar in this folder) and install it in another folder ("compile-libs" for this example)
• Override the "-compile" target of the imported ant build file by copying it from the $ANDROID_SDK$/tools/ant/build.xml to your $PROJECT_ROOT$/build.xml
• add the content of "compile-libs" to the classpath when is invoked (in the "-compile" target of your $PROJECT_ROOT$/build.xml) :

<javac ...>
    ...
    <classpath>
        <fileset dir="compile-libs" includes"*.jar"/>
        ...    
    </classpath>
</javac>

You're right, working with ant + android + androidannotations is not easy at the moment, we are working on the documentation for automated builds.

I discovered AndroidBinding (http://code.google.com/p/android-binding/) in the following article : http://blog.springsource.com/2011/08/26/clean-code-with-android/

AndroidBinding implements some really neat ideas, but does so at runtime, which leads to an extra perf cost. Maybe we could implement some of its binding features, but at compile time, with annotations ?

@wadael, Nov 20, 2011
An annotation that would add an ad in each activity

Could it be on the application class (with publisher id + top|bottom for ad placement).

Eventually, an @NoaDS to prevent ad display on specific activities.

I'll try to contribute it myself, so do not expect a release date :)

Let's speak of it at a next PAUG/ParisJUG maybe.

Thanks

@pyricau, Nov 21, 2011
I'm not sure how that would work, but it's an interesting idea. Don't hesitate to put snippets of code in this issue to show what the generated code should look like.

And yes, don't hesitate to come talk to me next time you see me ;-) .

In Android 4, the fields of the R inner classes won't be final anymore for library projects (and only for library projects).

This means that those ids cannot be used for switches any more (and we don't really care), but also cannot be use into annotations. That's a problem for us, because the compiler won't allow this any more :

@ViewById(R.id.myIdFromMyLibraryProject)

So I think we'll have to provide an alternative way to specify ids, using strings and complete qualified names :

@ViewById(alt="com.mylibrary.R.id.myIdFromMyLibraryProject")

This is not perfect (not typesafe any more). Ids may become invalid and you won't notice. We can help with our compile time framework, because when can check that the "com.mylibrary.R.id.myIdFromMyLibraryProject" field exists, and issue a compile error otherwise. Runtime frameworks won't be that lucky (RoboGuice, ACRA...).

The Android team introduced this change to improve the build perfs when using library projects. More on this subject :

http://tools.android.com/tips/non-constant-fields
https://plus.google.com/u/0/109385828142935151413/posts
http://code.google.com/p/acra/issues/detail?id=85

The Cookbook should contain recipes on how to do a variety of things with AndroidAnnotations. Each recipe should be targeted with a minimum version.

@pyricau, Apr 13, 2011

It would be nice to see if we can generate subclass for fragments, so support annotations such as @ViewById, @click and others in fragments. The fragments would be annotated @efragment.

We need to see if that's feasible, and how it would work. The generated code will have to work with 3.0 and pre 3.0 (ie support jar). To do so, we'll have to check the annotated fragment package, and see if it's "support" or android 3.0 package.

Fragments are created based on layout.xml files, so those layout will have to be updated to include the generated fragment instead of the original one. Which mean we may also add some checks (compile errors) to see if an original fragment is recorded instead of the generated one.

@fjjonesjr, Dec 22, 2011

Personally I think this priority should be high. This is a great framework, but of little use to modern implementations until fragment support is available. ICS exacerbates this greatly.

@pyricau, Dec 26, 2011
You are right, and it is indeed of high priority. I want this to be part of the next release.

We should write documentation for SharedPreferences helpers

The corresponding wiki page is empty.

This was fixed when the project was hosted on Google Code, but we keep it as a reference for Milestone 2.3

http://code.google.com/p/androidannotations/issues/detail?id=143

We don't have any more tags on the new git repo, as you can see here https://github.com/excilys/androidannotations/tags

It seems that we lost the tags in the migration process. Probably didn't push all the stuff.

I'll do it ASAP.

Reported by project member py.ricau, Apr 14, 2011
Ok, this might sound silly / crazy... but what about using annotations to generate helpers at compile time for SQLite usage ? It could be a compile time JPA implementation, or maybe something completely different.

The first step might be to list all Android frameworks that provide solutions to hide the SQLite complexity.
Delete comment Comment 1 by mail.michael.ludwig, Apr 21, 2011
One framework I know is ORMlite. But i did not use it. But the idea is definetly very good
Delete comment Comment 2 by project member py.ricau, Jul 19, 2011
A StackOverflow question on the subject: http://stackoverflow.com/questions/371538/any-good-orm-tools-for-android-development

androidsql (defines schema with an enum) http://negentropiccoder.blogspot.com/2009/04/android-sqlite-framework-based-on-enum.html

orman (not specific to android): https://github.com/ahmetalpbalkan/orman/wiki

ormlite (not specific to android) : http://ormlite.com/

db4o (not specific to android) : http://developer.db4o.com/Blogs/Product/tabid/167/entryid/76/Default.aspx . Replaces SQLite.

ActiveAndroid: https://www.activeandroid.com/
Very interesting solution, but not free (only works on emulator). Mix between active record style (extending a base model class, which provides save and delete method) and annotations.

Queries are still a bit raw:

ActiveRecordBase.query(context, Item.class, new String[] { "Id", "Name"}, "Category = " + category.getId(), "Name ASC");

I don't like this kind of query methods with multiple weird and null parameters... and I don't like the unsafe strings (think Hibernate Metamodel generator).

android-active-record : http://code.google.com/p/android-active-record/

Works quite the same way as the previous framework (extending ActiveRecordBase), but free, less documented, and no annotation.

An interesting idea would be to generate the empty database at compile time, and inject it at first run (by coping and pasting the database file.

Delete comment Comment 3 by project member py.ricau, Jul 19, 2011
Querydsl (http://www.querydsl.com) uses annotation processing to generate a DSL dedicated to querying your entities, using JPA, SQL, and others.
Delete comment Comment 4 by project member py.ricau, Jul 19, 2011
Another list from StackOverflow: http://stackoverflow.com/questions/296587/light-weight-alternative-to-hibernate

Empire-DB : http://incubator.apache.org/empire-db/ One must generate a DDL, and them use a DSL a bit in the same way as Querydsl, but a lot more verbose.

Delete comment Comment 5 by project member py.ricau, Oct 20, 2011
(No comment was entered for this change.)
Labels: Milestone-
Delete comment Comment 7 by project member mat.boniface, Nov 21, 2011
IMHO, AA should not provide a "high level really complex way to manage data" like it's proposed in many ORMs (JSR 317 FR killed me). A lot of Android applications are really simple so it could be nice to bring a easy way to access data for developers.

What do you think about limiting AA features to dynamic finders ? And maybe a few more ?

I mean something like that :

public class MyActivity extends Activity {
@dao
PlaceDAO placeDAO
...
}

@dao
public abstract class PlaceDAO {

/**

• neighborhood is defined by developer as a field in the DB (table Place) and an attribute in the Place class. This method returns a list of Places that match with the given neighborhood name.
  */
  public abstract List findPlace(String neighborhood);

/**

• Will return the first result of the request that returns a Place where id field value equal id parameter value. (We don't care about PK/FK, it's not the AA job)
  */
  public abstract Place findPlace(int id);

  /**

• Insert a new row into the Place table using the parameters (names and values).
  */
  public abstract insertPlace(int id, int longitudeE6, int latitudeE6, String address);

  /**

• Will update the row identified by id parameter by using the adress value.
  *
  public abstract updatePlaceSetAddress(int id, String adress);

  @transactional
  public moreComplicatedMethodWrittenByDev() {
  ...
  }

}

Here, all abstract methods are generated by AA, and the user can implements its "complicated" business method.

With this example I suppose that developers define himself the database schema.
Delete comment Comment 8 by project member py.ricau, Nov 21, 2011
Ok, interesting.

A few notes :

We should provide a way to access the db, from the abstract class and from the generated class. Should a connection be part of the methods parameters ? Should we allow some constructor parameters ? Should we define a standard method to "retrieve a connection" ? Or should we work at the db level, letting the user open connections ?

How would the Object > ContentValues mapping occur in "Place findPlace(int id);" ? Do you look at fields, getters / setters ? Do you need an empty constructor ? What contraints do we put on the entities ?

You said you don't care about FKs. So if Place has a list of Users, you just let that to null, right ?

What about joins and projections ?

I like the idea of concentrating on the finders, but that may not be so useful, would it ?

Should me provide a mapping method ? For example, if the users writes an abstract method "Place mapFromCursor(cursor)", we would implement it. And if he implements it, we would use that. What do you think ?

Maybe we should also generate a metamodel for the entities. Create the class Place_, that would hold static fields holding the fields names. That would allow the user to have type safety when writing requests.
Delete comment Comment 9 by project member py.ricau, Nov 21, 2011
Let's try to list what usual ORM can do, and then pick what we want (with implementation examples):

• Generates Entities from SQL DDL (some hibernate tools)
• Generates DDL from entities (hibernate)
• Row > Object mapping (hibernate)
• Session objects, with automagic updates of the db (hibernate)
• Create / update the database schema (hibernate, flyweight)
• Helpers for customs queries (Querydsl, hibernate metamodel generator)
• Dynamic finders for simple queries (Spring Data)
  Delete comment Comment 10 by project member py.ricau, Nov 21, 2011
  A few more :
• Handling FKs (OneToMany, ManyToOne, OneToOne, ManyToMany)
• Handling transactions

I think we probably don't want session management, because it adds a lot of complexity in the backend code, and the dev doesn't have a feeling of "being in control" (that's one of hibernate's best and worst feature, in my opinion...)

We may decide that we don't want to handle FKs, but then we have to define how the user should work with FKs.
Delete comment Comment 11 by project member py.ricau, Dec 29, 2011
Interesting comment in issue 40 :

Comment 4 by wblandin, Dec 26 (2 days ago)
If you take a loot at:
http://developer.android.com/resources/samples/NotePad/src/com/example/android/notepad/NotePadProvider.html

You can that see a lot of this is boilerplate and can be deduced from:
http://developer.android.com/resources/samples/NotePad/src/com/example/android/notepad/NotePad.html

So annotations could take care of this.. A bit like Symfony2 (PHP framework)
http://symfony.com/doc/2.0/book/doctrine.html (search for "annotation")

What do you think?

We have a Jenkins instance hosted by CloudBees here: https://androidannotations.ci.cloudbees.com/

It currently points to the googlecode git repository. We need to let it point to the github repository.

We should also use a post commit hook from github instead of a cron checking of the git repo.

This was fixed when the project was hosted on Google Code, but we keep it as a reference for Milestone 2.3

http://code.google.com/p/androidannotations/issues/detail?id=99

I'd like to implement a new Listener system for the activity callbacks, somehow inspired from RoboGuice and other sources.

Here is the idea :

We would create some listener callback interfaces, such as OnCreateListener, OnResumeListener, OnPauseListener... they may all inheriting from an AndroidCallbackListener interface (a marker interface useful from the framework point of view).

Users would write a listener class :

public class MyListener implements OnCreateListener, OnResumeListener {

  public void onCreate(Activity activity, Bundle savedInstanceState) {
    // do something
  }

  public void onResume(Activity activity) {
   // do something
  }
}

Then, they would be registered in the activity :

@EActivity
@Listeners(MyListener.class)
public class MyActivity extends Activity {

}

And that's all : onCreate and onResume in the listener will be called immediately after the callback are called in MyActivity.

The implementation would just create a new instance of MyListener and set it in a field of MyActivity_, and delegate the calls to onCreate, onResume, etc.

This whole thing is not precisely defined yet, we need feedback, so please everyone tell me what you think of this.

The listeners could also be written with a constructor given activity, instead of something method based (so it shows that there is one instance of listener per activity :

public class MyListener implements OnCreateListener, OnResumeListener {

  public MyListener(Activity activity) {
  }

  public void onCreate(Bundle savedInstanceState) {
    // do something
  }

  public void onResume() {
   // do something
  }
}

On the activity side, we could use an @EActivity field instead of a dedicated annotation :

@EActivity(listeners = {MyListener.class})
public class MyActivity extends Activity {

}

BTW, what do you guys think : should it be one listener per activity, or one per application ?

Should we provide a way to use a specific kind of activity ? For instance, having an OnCreateListener interface, we could do this :

 public class MyListener implements OnCreateListener<MyAbstractActivity> {

  public void onCreate(MyAbstractActivity activity, Bundle savedInstanceState) {
    // do something
  }

}

Or if we go with the constructor solution, then we could allow subclasses of activity, and check that the listener can be used on the activity.

Any other idea ?

This would be a great alternative for issue 110 (provide a vendor specific annotation that do some stuff in some callbacks), because we could then do something like :

public class CapptainListener implements OnPauseListener, OnResumeListener  {

    private Activity activity;

    public CapptainListener(Activity activity) {
      this.activity = activity;
    }

    @Override
    public void onResume() {
        CapptainAgent.getInstance(activity).startActivity(activity, activity.getClass().toString, null);
    }

    @Override
    public void onPause() {
        CapptainAgent.getInstance(activity).endActivity();
    }
}

@vincent.barat, Nov 1, 2011 :
Yes, I think it would be a much better way to handle Capptain integration and other Activity related listeners.
I vote for it ! :)

Reported by sony.tricoire, Jan 3 (2 days ago)
I would like to use annotations from a AppWidgetProvider subclass.

Comment by @pyricau, Jan 4 (2 days ago)
Good idea. I don't have much experience regarding AppWidgets, I started reading the docs, and basically an AppWidgetProvider is a broadcast receiver.

So we could start with adding support for broadcast receivers, and then maybe later add specific annotations for AppWidgetProvider if needed.

What annotations would you use ?

As developers of AndroidAnnotations, we know all the situations where we can use annotations to clean up our code.

New comers do not have that chance. Having a cheatsheet that would list all annotations with a quick summary of what they do would be great.

I'm wondering if the @inherited annotation has any impact on annotation processing.

We should investigate that, it might help us in some way.

We currently don't take advantage of the multiple rounds of annotation processing. This is because we don't add any annotation to the generated code, so it doesn't need to be processed again.

When we do a clean build, we are in a situation where some generated artifacts are used in the code, but not available yet since they've just been cleaned. This leads to hard times trying the determine the types of some elements. The type of those elements is described as an "ErrorType".

The current decision when we encounter such elements is to treat them as "correct" elements and validate them without checkout them any more. We trust the developer. It works quite well, but it's not really future proof.

A solution could be to use multiple rounds for that, if possible. We could collect the elements that cannot be validated on a round because they depend on a generated item, then let the round generate the missing code, them do an extra round and treat the previously received elements.

That's not gonna be easy because our model doesn't work that way, so we have to think it through.

We need to document the @Trace wiki page

Idea from @matboniface:

Instead of having to implement this :

protected  void onActivityResult(int requestCode, int resultCode, Intent data) {
 // Switch based on request code here
}

We could have an @OnResult(REQUEST_CODE) annotation, and the switch would be done by AndroidAnnotations

@OnResult(FOO_REQUEST_CODE)
void myFooResult(int resultCode, Intent data) {

}

@OnResult(BAR_REQUEST_CODE)
void myBarResult(int resultCode, Intent data) {

}

Capptain is a great "analytics / monitor / reach" product. It has an AndroidLibrary that does great, but the usual way to use it is to extend specific activities, which doesn't integrate well with other frameworks.

However, it's quite easy to create your own custom capptain activities, you just have two calls to do :

    @Override
    protected void onResume() {
        super.onResume();
        CapptainAgent.getInstance(this).startActivity(this, "ActivityName", null);
    }

    @Override
    protected void onPause() {
        super.onPause();
        CapptainAgent.getInstance(this).endActivity();
    }

The usual behavior for "ActivityName" is to take the classname of the activity, and remove any trailing "Activity" string.

We could have a @Capptain annotation which would let the user integrate with Capptain without having to write such a code :

@Capptain("OptionalName")
public MyActivity extends Activity {

}

Please also notice that Capptain is not a free tool. There's a Capptain Plan ("DEV") which is free for apps in development (i.e. small number of unique users/devices). See http://app.capptain.com/#pricing

This idea here is to create a new annotation, called "@capptain", that would automatically implement this stuff in onResume and onPause. AndroidAnnotations can actually do this kind of things (and w already have a lot of RoboGuice features, we just do it at compile time instead of runtime).

Issue #5 will provide an alternative solution for that.

In @Enhanced components, dependency injection happens in the constructor of the subclass, which means that in the constructor of the annotated super class, no component is injected yet.

So we would need an @AfterInject annotation, that would work like @AfterViews, but be called after injection (and of course before @AfterViews).

@pyricau, Jan 5, 2011
It might be a good idea to provide helpers for PreferenceActivity.

Things such as @PreferenceScreen(R.xml.my_preference), and @preference("key") on a field.

Some annotations to had ValueChangeListeners might be nice too.

mail.michael.ludwig, Mar 20, 2011
Yes that would be very nice. Also clickHandlers to Preferences would be nice.

@pyricau, Jul 20, 2011
We should look at what RoboGuice already provides, to integrate the same kind of functionalities.

Original Issue here: http://code.google.com/p/androidannotations/issues/detail?id=106

Reported by project member py.ricau, Sep 13, 2011
Principle :

Let's say you have a MyFont.otf file in your asset directory.

You could then do the following :

@font("MyFont.otf")
@ViewById
TextView myTextView;

=> The generated code would do the following :

Typeface myFont = Typeface.createFromAsset(getAssets(), "MyFont.otf");
myTextView.setTypeface(myFont);

Maybe it should also work when not using @ViewById, ie :

@font("MyFont.otf")
TextView myTextView;

=> The user injects myTextView manually.

@font will do it's injection after view injection.

If twice the same font is injected, then we should load it only once (based on the string value of the annotation).

Maybe we should also check that the font file exists in the asset folder (or not ?)

Delete comment Comment 1 by project member mathieu.debrito, Sep 14, 2011
That's a really good idea !
Also, developers often use fonts on all views in an activity.

Could be cool to have it on the activty
like @EActivity([layout, .font?])

or @EActivity(layout)
@font(font)
Delete comment Comment 2 by project member py.ricau, Sep 14, 2011
Interesting idea. However, there is no way to know all the textviews in a layout, appart from reading the layout file and its included templates.

However, we could to this :

@EActvitiy(R.layout.main)
@font(font = "MyFont.otf", textviews = { R.id.tv1, R.id.tv2 })
public class MyActivity extends Activity {
Delete comment Comment 3 by project member py.ricau, Sep 14, 2011
In fact, I like it better then the initial idea, because then the user won't use a ViewById just to set the font. Plus, it makes it easier to centralise font loading.

Users may want to set multiple fonts, and there can only be one annotation of a given type at a time.

So maybe there could be two ways to set fonts :

@EActivity(R.layout.main)
@font(font = "MyFont.otf", textviews = { R.id.tv1, R.id.tv2 })
public class MyActivity extends Activity {

And

@EActivity(R.layout.main)
@fonts({
@font(font = "MyFont.otf", textviews = { R.id.tv1, R.id.tv2 }).
@font(font = "MyFont2.otf", textviews = { R.id.tv3, R.id.tv4 })
})
public class MyActivity extends Activity {

Delete comment Comment 4 by project member mathieu.debrito, Sep 14, 2011
That's true !

Another idea is that we could get the root layout element as a view group.
from that, we can get back all the views in this view group and apply on them the new font.

The main problem with this idea is that any new view ( I mean dynamically created ) will not have the font.

Delete comment Comment 5 by project member py.ricau, Sep 14, 2011
Yep. And there is a risk of magical chaos, ie the framework doing too much things and the dev not understanding exactly what happens under the cover.
Delete comment Comment 6 by project member mathieu.debrito, Sep 14, 2011
ya,I think the following versions are OK :

@EActivity(R.layout.main)
@fonts({
@font(font = "MyFont.otf", textviews = { R.id.tv1, R.id.tv2 }),
@font(font = "MyOtherFont.otf", textviews = { R.id.tv3, R.id.tv4 })
})
public class MyActivity extends Activity {

OR
@EActivity(R.layout.main)
@font(font = "MyFont.otf", textviews = { R.id.tv1, R.id.tv2 })
@font(font = "MyFont2.otf", textviews = { R.id.tv3, R.id.tv4 })
public class MyActivity extends Activity {
Delete comment Comment 7 by project member py.ricau, Sep 14, 2011
No, the latter can't work. You CANNOT twice the same annotation on an element, Java does not allow this. That's why I proposed @fonts ;-)
Delete comment Comment 8 by project member mathieu.debrito, Sep 14, 2011
Actually, instead of textviews, we could have the viewgroup option :
this would set the font for all the views in the viewgroup...

@EActivity(R.layout.main)
@font(font = "MyFont.otf", textviews = { R.id.tv1, R.id.tv2 }, viewgroup = { R.id.vg1 })
public class MyActivity extends Activity {
Delete comment Comment 9 by project member mathieu.debrito, Sep 14, 2011
Ok, got it for @fontss, a little bit too much I think
but if we can't skirt, it will be fine ^^
Delete comment Comment 10 by project member py.ricau, Sep 14, 2011
Well, I understand the idea, but as I said before, doing magical stuff might confuse the users :

• As far as I know, only TextViews have a setTypeface methods
• Setting ViewGroup is exactly the same as defining the font for the whole activity layout. It means iterating on all views of the viewgroup, and if a child is a viewgroup then iterating again.. and checking if it's a TextView for each child, and then setting the typeface. Problem is, if you have a complex view hierarchy, you'll end up iterating on a looooot of views. And it doesn't feel good.

AndroidAnnotations aims at writing for you the boring code. You wouldn't usually write this kind of code for an activity, you'd rather retrieve each view by id. At least, I guess so.

Maybe I'm wrong, and it has no runtime impact. This needs testing. People would hate us if AndroidAnnotations had a runtime performance impact.

Anyway, maybe we could also create an @AllFont (or something) annotation that would do what you suggested, and warn the user that this might have performance impact ?
Delete comment Comment 11 by project member mathieu.debrito, Sep 14, 2011
Well, I understand your feeling for the all views.
As I saw this, a viewGroup would be included ( with a warning for the user )

But I understand the way AndroidAnnotations should keep.
I think I could check whether the change of the setFont on a viewGroup could bring runtime problems or not.

I use a viewGroup Font modifier in my apps, and didn't receive any problem so far.
Anyway, I agree with you on the fact that AndroidAnnotations should keep its way for no runtime impact !

Delete comment Comment 12 by project member mathieu.debrito, Sep 19, 2011
Here is my font modifier for a view group :

public static Typeface setFontToAllViews(AssetManager assets, String fontName, ViewGroup aView) {
Typeface font = Typeface.createFromAsset(assets, fontName);

for (int i = 0; i < aView.getChildCount(); i++) {
    View v = aView.getChildAt(i);
    if (v instanceof TextView) {
    ((TextView) v).setTypeface(font);
    } else if (v instanceof Button) {
    ((Button) v).setTypeface(font);
    } else if (v instanceof EditText) {
    ((EditText) v).setTypeface(font);
    } else if (v instanceof CheckBox) {
    ((CheckBox) v).setTypeface(font);
    } else if (v instanceof ViewGroup) {
    setFontToAllViews(assets, fontName,(ViewGroup) v);
    }
}
return font;

}

I thought a bit about the font problem, and I think there should be only 2 ways for specify font :

@font(fontName)
@FontRecursive(fontName)

The @FontRecursive should be only accepted for viewGroup :
it should not compile else.

@pyricau, Jul 19, 2011
Creating Parcelables requires some hand work that could be automated with AndroidAnnotations.

The main problem is: how do we put custom objects in fields into parcels ? Shall they implement parcelable ? Should everything be done in Parcelable root ?

@mathieu.debrito, Oct 11, 2011
The idea of using parcelables is for bundle parameters ?
or something else ?
Anyway, it could be cool if the developper does not have any code to write to implement parcelable... but it will be a little tricky to make it out !

@pyricau, Oct 11, 2011
Well, for anything that uses Parcelable (hence, for Bundles too ;-) )

Tricky, that's the word. And I don't have too much experience on good Parcelable practices.

@ealden, Dec 12, 2011
When combining both the full JAR and the API JAR, I get an error saying that some classes have already been loaded. This is because the full JAR is a superset of the API JAR, hence they can't be combined together.

While only the API JAR should be included in Android projects, setting up build systems such as Gradle is a bit more complicated as it is not possible to define both JARs as dependencies and as part of the classpath. For Gradle, I had to resort to including the full JAR as part of the project, and referencing it in the configuration.

It would be easier really if the full JAR needed the API JAR to work completely, as all the API JAR-specific classes are not duplicated. I'm not fully aware of the decisions with AndroidAnnotations early on, so this might be a moot point.

@pyricau, Dec 15, 2011
I think you have a good point here. My main concern is that many of our users don't use Maven in their Android projects, so it's not easy for them to deal with dependencies, and I'd rather not ask them to add multiple jar to their annotation processing classpath.

I'm starting to think that maybe we should have 3 main artifact instead of 2 :

androidannotations-full (contains core, api and code model) : for non maven users
androidannotations (contains core, depends on api and code model) : for maven users
androidannotations-api (no dependencies) : runtime jar, for both maven and non maven users

What do you think ?

@ealden, Dec 15, 2011
Yes I think that makes sense. Should be much easier to add this at least for Gradle.

@pyricau, Dec 29, 2011
Funny enough, I'm starting to have the same error when using android-maven-plugin 3.0.0 (previously I used 3.0.0 -alpha-13).

[INFO] --- android-maven-plugin:3.0.0:dex (default-dex) @ functional-test-1-5 ---
[INFO] /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/bin/java [-Xmx512m, -jar, /Users/pyricau/bin/android-sdk-mac_x86/platform-tools/lib/dx.jar, --dex, --output=/Users/pyricau/Projets/remote/androidannotations/AndroidAnnotations/functional-test-1-5/target/classes.dex, /Users/pyricau/.m2/repository/com/google/inject/guice/2.0-no_aop/guice-2.0-no_aop.jar, /Users/pyricau/.m2/repository/com/googlecode/androidannotations/androidannotations/2.3-SNAPSHOT/androidannotations-2.3-SNAPSHOT.jar, /Users/pyricau/.m2/repository/org/roboguice/roboguice/1.1.2/roboguice-1.1.2.jar, /Users/pyricau/Projets/remote/androidannotations/AndroidAnnotations/functional-test-1-5/target/classes, /Users/pyricau/.m2/repository/com/sun/codemodel/codemodel/2.4.1/codemodel-2.4.1.jar, /Users/pyricau/.m2/repository/com/googlecode/androidannotations/androidannotations/2.3-SNAPSHOT/androidannotations-2.3-SNAPSHOT-api.jar]
[INFO]
[INFO] UNEXPECTED TOP-LEVEL EXCEPTION:
[INFO] java.lang.IllegalArgumentException: already added: Lcom/googlecode/androidannotations/annotations/AfterViews;
[INFO] at com.android.dx.dex.file.ClassDefsSection.add(ClassDefsSection.java:123)
[INFO] at com.android.dx.dex.file.DexFile.add(DexFile.java:163)
[INFO] at com.android.dx.command.dexer.Main.processClass(Main.java:486)
[INFO] at com.android.dx.command.dexer.Main.processFileBytes(Main.java:455)
[INFO] at com.android.dx.command.dexer.Main.access$400(Main.java:67)
[INFO] at com.android.dx.command.dexer.Main$1.processFileBytes(Main.java:394)
[INFO] at com.android.dx.cf.direct.ClassPathOpener.processArchive(ClassPathOpener.java:245)
[INFO] at com.android.dx.cf.direct.ClassPathOpener.processOne(ClassPathOpener.java:131)
[INFO] at com.android.dx.cf.direct.ClassPathOpener.process(ClassPathOpener.java:109)
[INFO] at com.android.dx.command.dexer.Main.processOne(Main.java:418)
[INFO] at com.android.dx.command.dexer.Main.processAllFiles(Main.java:329)
[INFO] at com.android.dx.command.dexer.Main.run(Main.java:206)
[INFO] at com.android.dx.command.dexer.Main.main(Main.java:174)
[INFO] at com.android.dx.command.Main.main(Main.java:95)

@pyricau Dec 30, 2011
However, I was able to fix that by using scope "provided" instead of "compile" for artifact androidannotations.

I should go read more about maven scopes...

We need to get users started quickly with AA. A good way to do that would be to create a screencast.

When using @ItemClick, sometimes you don't wanna know the item but rather the position. This is usually the case when using a string array from resources.

So we could change the rule : if the parameter is an int, then the position is given, and otherwise, the item is given.

We need to document the [@enhanced wiki page](../wiki/Enhance custom classes)

Let's list here what's needed to complete the migration to Github:

• Migrate the wiki pages by transferring the Git repo of the wiki and then transform the 43 pages to the Markdown syntax (@BluePyth)
• Move the source to GitHub (@pyricau)
• Switch default branch on GitHub from master to develop
• Update the README.md with all informations from the frontpage of AndroidAnnotations
• Update the website androidannotations.org to point to GitHub
• Remove the wiki pages, and keep only one page, that redirects to the GitHub project
• Update the front page of the google code project to point to github
• Move the open issues, copy and paste each issue content to a new github issue and add a link to this issue from the google code issue

This is more of a draft idea that needs to be discussed. Suggested by @matboniface, I write it here after a few beers so the idea might need improvements ;-)

Create a new annotation, @runwhen or @RUNIF, which would be provided with conditions. Those conditions would be evaluated at runtime. It's basically brings the same things as if you were just adding an "if" at the beginning of your method, except that you provide the conditions through metadatas, and your code is therefor more readable, since it only deals with what's important.

It would be nice to be able to do things such as :

@RunIf(@Device(constructor="HTC"))
public void myMethod() {
// Runs if device has an HTC constructor
}

@RunIf( { @AndroidVersion(greaterThan=8), @MyCondition(myParam="SomeValue") })
public void myMethod() {
// Runs if android version > 8 and a custom condition is met. 
}

The @MyCondition annotation would be created by the user, which would bind it to a condition class that would have a validation method (returns boolean) and parameters that matches the annotation parameter names and types. This condition class should also be able to receive a context (activity?).

It could also be used to implement roles :

@RunIf(@Role("admin"))
public void myMethod() {
// Runs if user has admin rôle.
}

@RUNIF method must return void

This was fixed when the project was hosted on Google Code, but we keep it as a reference for Milestone 2.3

http://code.google.com/p/androidannotations/issues/detail?id=155

Right now, the @Rest annotated classes cannot be inner classes. We don't add any compile time error (and we should), but the generated code is wrong.

Maybe we should try to support inner annotated classes, for small services where you want to have it next to the activity code.

Not sure this is good for clean code though.

This was fixed when the project was hosted on Google Code, but we keep it as a reference for Milestone 2.3

http://code.google.com/p/androidannotations/issues/detail?id=147

When using @Enhanced on a component without anything that requires init, the following code is generated :

private void init_() {
    if (context_ instanceof Activity) {
        Activity activity = ((Activity) context_);
    }
}

This generates a warning : The value of the local variable activity is not used

This part of the code should only be added when needed.

@shuya-inc we'll need your input for the documentation of @EViewGroup

(moved that task out of #39)

We have a Jenkins instance hosted by CloudBees here: https://androidannotations.ci.cloudbees.com/

Currently, any commit on the develop branch triggers a new build.

Our Snapshots are deployed to Sonatype's OSS maven repository.

I wonder if we could configure Jenkins so that when the develop branch has been built successfully, the artifacts are deployed.

We could use "mvn deploy" goal, but there's also an option to deploy artifacts in Jenkins. I'm not sure what's best.

It may be interesting to allow users to write less code when using Google Analytics SDK for Android (http://code.google.com/mobile/analytics/docs/android/ )

The dedicated annotations should not compile if the SDK jar is not available at compile time.

Ideas :

The UA account value should be set in the AndroidManifest.xml as a custom variable, and we should check it's there at compile time.

The activity should be annotated with @Analytics The default would be a tracker with a dispatch interval of twenty.

the tracker would automatically track a page view ( tracker.trackPageView("/testApplicationHomeScreen");) when onCreate is called, and destroy would automatically be called in onDestroy.

This behavior may be disable using annotations attribute :

@Analytics(trackPageView = false, destroy = false)
public class MyActivity {

The tracker may be injected in the activity (if @analytics is set at the top), using @Tracker on a field that has the Tracker type.

We could also track some events on demand. For example, creating a new @Track annotation :

@Track // Maybe some annotation parameters ?
@Click
void myButtonClicked() {

Custom vars may also be set using annotations (maybe sub annotations for @Analytics)

Automatic dispatching could be disabled using @Analytics(autoDispatch=false).

But then, we should check that the tracker is injected, otherwise it means that the tracking events will never be dispatched.

Warnings with OnXXXListeners in @eviewgroup generated subclasses

Code example:

@EViewGroup(R.layout.component)
public class MyEnhancedLayout extends FrameLayout {

    @Click
    public void title() {
    }

}

Generated code:

public final class BasicComponent_
    extends BasicComponent
{


    public BasicComponent_(Context context, int i) {
        super(context, i);
    }

    private void afterSetContentView_() {

        {
            View view = findViewById(id.title);
            if (view!= null) {
                view.setOnClickListener(new OnClickListener() {


                    public void onClick(View view) {
                        title();
                    }

                }
                );
            }
        }
    }

    @Override
    public void onFinishInflate() {
        inflate(getContext(), layout.component, this);
        afterSetContentView_();
        super.onFinishInflate();
    }

}

CodeModel adds an import to import android.view.View.OnClickListener; in the generated code. OnClickListener is an inner class of View, and since a ViewGroup extends View, this import is not needed, because OnClickListener is visible from any View subclass.

Therefore, we have the following warning in the generated class :

The import android.view.View.OnClickListener is never used

Same thing for @LongClick, @Touch, etc.

We'll have to dig through CodeModel source to see if we can do anything about that (maybe using reflection...), or if we should submit a patch to CodeModel.

Idea stolen from RoboGuice ;-)

Maybe we could inject the Secure.ANDROID_ID value.

Here is the doc : http://developer.android.com/reference/android/provider/Settings.Secure.html

Should we create a @Androidid annotation ? Or maybe something like @SecureValue(Secure.ANDROID_ID) that would allow injection of other values.

• Move website repository to gh-pages
• Remove "website" remote branch
• Check if gh-pages can use a dedicated domain name (androidannotations.org)

We should provide annotations for other Android components (Service, ContentProvider, BroadcastReceiver).

Annotations that could be nice (when applicable) for those components :

@Background / @UiThread
@SystemService

Everything except view related stuff and extras (extras might be interesting, but it won't be easy to implement, we need to think them through).

@a-thomas it would be great if you could update the Rest API recipe ;)

(moved that task out of #39)

We have to create a vector version of AndroidAnnotations' logo for the website.

Sent by Tony Membot:

Hi !

I'm using android annotation for a short while and it's really a good API ! Thank lots for this work !

But I have one question about the last release (2.2). I've see that now we can use the @Notitle annotation to hide the title bar on an activity (on issue 127).
But when I try to use it, it does nothing. Are there some prerequisites to use it ?

I've just write the code like this :

@EActivity(R.layout.city_list)
@Notitle
public class CityListActivity extends ListActivity {

Thank in advance for your help !