kboyarshinov / activityscreens Goto Github PK

Passing arguments to Service is the same process as to Activity, so Service support can be easily added. However, how to name generated helper classes for Services. They are not Screens after all. I guess Launcher would fit pretty well.

Is it possible to add a support to start Activity from a Fragment?
According to the following documentation.

Actually, sometimes, it can be useful to start an Activity (and occasionally for result) from a Fragment.

So we will obtain something like this:

// Fragment section

public void open(android.app.Fragment fragment) {
    Intent intent = toIntent(fragment);
    fragment.startActivity(intent);
}

public void openForResult(android.app.Fragment fragment, int requestCode) {
    Intent intent = toIntent(fragment);
    fragment.startActivityForResult(intent, requestCode);
}

// Support fragment section

public void open(android.support.v4.app.Fragment fragment) {
    Intent intent = toIntent(fragment);
    fragment.startActivity(intent);
}

public void openForResult(android.support.v4.app.Fragment fragment, int requestCode) {
    Intent intent = toIntent(fragment);
    fragment.startActivityForResult(intent, requestCode);
}

If the Service support in #1 will be added title ActivityScreens would not fit to all features provided. So the annotations @ActivityScreen and @ActivityArg. My thoughts on better naming had lead me to the following: ComponentBundler for library and @ComponentBundle, @ComponentArg for annotations. Component because both Activity and Services are generified to Components in Android documentation.

Any suggestions are welcome.

Generated Screen classes has two methods to launch specified Activity:

    public void open(Activity activity) {
        Intent intent = toIntent(activity);
        activity.startActivity(intent);
    }

    public void openForResult(Activity activity, int requestCode) {
        Intent intent = toIntent(activity);
        activity.startActivityForResult(intent, requestCode);
    }

Now they have Activity as a first argument. However, startActivity method can be called using just Context, but startActivityForResult can't. The discussion is about to leave everything like now, or to change 1st argument of open to Context. The same is for toIntent method.

I want the final API to be clear, and different arguments for practically almost the same purpose methods can lead to usage misunderstanding.

Is it possible to add the "required/optional" status of a field?
So that it's removed from the builder constructor and can be configured via a specific setter method?
The check would be removed from the checkArguments method and replaced by a simple if(bundle.containsKey("optional_field_key") in the inject method before setting the field for example.

I have stumbled upon one problem I could not find right solution. The problem is within order of processing fields annotated with @ActivityArg annotation. They are processed in alphabetical order. Thus, generated methods accept these arguments also in alphabetical order, not in the order user wrote them in code. I guess method typeElement.getEnclosingElements() just works that way. Because of this problem, I had to write tests with fields in alphabetical naming.
However, I see that Google's AutoValue and its fork AutoParcel do not have that problem. All I have googled lead to some eclipse compiler problems which were solved with EclipseHack.

If the solution exists this line needs to be changed.