Add "Populate" functionality to Enhanced Views (EActivity, EFragment, EGroupView), Recollect and Populate functionality adjustment.

[smaugho]

The enhanced views could make the Populate action by themselves without the need of an intervention of @Populate annotation. Let's say that we have a layout with Ids "@+id/user_firstName", "@+id/user_lastName", "@+id/user_fullName", "@+id/userNameMeaning".

With the models User:

public class User {
    @NotEmpty String firstName;
    @NotEmpty String lastName;
    
    public String fullName() {
        return firstName + " " + lastName;
    }
}

Now our layout:

@EActivity(R.id.main_activity)
public class MainActivity extends Activity {

    @Model
    NameMeaningUtility nameMeaningUtility;

    @Model
    User_ user;

    @Click
    void btnSaveUser() {
        $PutModel(user).validate();
    }

    String userNameMeaning() {
        return nameMeaningUtility.nameMeaning(user.getFirstName());
    }
}

First we realize that the annotation @EActivity can automatically detect the views that are trying to be populate from within the interface. It does this with the ids of the components.

So @EActivity detects that there's 3 dependency injections into views coming from the model User, and there's one injection from a method in the activity.

So this simplifies much more the injection mechanism into views, and it permits to reduce one more element in the code, @Populate.

It is important to point that from the Activity itself, view values can be injected (from fields, or methods), adding much more versatility to the programming process.

MVVM with DecleX

The pattern MVVM can be easily implemented in this way, and highly simplifies. DecleX has the power of Dependency Injection inherited from AA, so it can convert the Activity itself in the ViewModel (given to it a place finally in MVVM, and removing the god capabilities of it).

From the point of views of the generated code, this "god activity" would be the generated activity. But the Activity itself can be converted in the ViewModel completely.

It simply contains the methods that are needed to populate/recollect information from the Inteface, and it interacts with the Model.

All the special dependencies can be injected (like in the case above, NameMeaningUtility).

Removing Recollect for normal behavior.

At this point, there's no a real need for a Recollect annotation, since the actions $Recollect and $PutModel are present in the framework (Plus @PutOnAction). So the needs to prepare the object to be recollected can be completely satisfied by the actions themselves.

Handling Only-Populate / Only-Recollect scenarios

Some times it is needed to handle scenarios where you don't need to make these actions above... Since $Recollect will be done by an action, it is not a problem to executed or not (since the programmer decides when to do it).

Now, to handle scenarios in which you only need to Recollect data, or some specific fields, and the same for Populate, then you can use @Populate @Recollect for that specific situation.

So, by default the behavior is Populate all the fields, and Recollect all the fields... it would be the same if you specify the annotations. Now, both annotations should take as parameters one Enum, that can be set to:

ALL -> Default FIELDS NONE

So you can configure with the annotation if to populate or not some specific Model (they are applied only to Models).

Both annotations will have also a parameter named field, where it can be specified what fields to recollect or not... This value can be override by the fields method of the actions $LoadModel, $Populate, $PutModel, $Recollect.

$Populate(this)

It should be added the special $Populate(this) which will populate whole the user interface again (it will update all the user interface)