kboyarshinov / activityscreens

[DEPRECATED] Android library that simplifies passing arguments between Activities using generated classes aka Screens

[DEPRECATED] ActivityScreens

Deprecation note

Library was never finished and released and there are few alternatives exist: Dart & Henson or IntentBuilder.

Description

Android library that simplifies passing arguments between activities using generated classes aka Screens.

Example:

@ActivityScreen
public class SampleActivity extends Activity {

    @ActivityArg
    long id;
    @ActivityArg
    String title;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        // read fields annotated with @ActivityArg
        SampleActivityScreen.inject(this);
    }
}

This example generates helper class SampleActivityScreen:

public final class SampleActivityScreen {
    public final long id;

    public final String title;

    public SampleActivityScreen(long id, String title) {
        this.id = id;
        this.title = title;
    }

    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);
    }

    public Intent toIntent(Activity activity) {
        Intent intent = new Intent(activity, SampleActivity.class);
        Bundle bundle = new Bundle();
        bundle.putLong("id", id);
        bundle.putString("title", title);
        intent.putExtras(bundle);
        return intent;
    }

    public static void inject(SampleActivity activity) {
        Bundle bundle = activity.getIntent().getExtras();
        if (bundle == null) {
            throw new NullPointerException("SampleActivity has empty Bundle. Use open() or openForResult() to launch activity.");
        }
        checkArguments(bundle);
        activity.id = bundle.getLong("id");
        activity.title = bundle.getString("title");
    }

    private static void checkArguments(Bundle bundle) {
        if (!bundle.containsKey("id")) {
            throw new IllegalStateException("Required argument id with key 'id' is not set");
        }
        if (!bundle.containsKey("title")) {
            throw new IllegalStateException("Required argument title with key 'title' is not set");
        }
    }
}

And it can be easily used:

    new SampleActivityScreen(3, "Sample title").open(activity);

LICENSE

Copyright 2015 Kirill Boyarshinov

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

activityscreens's Issues

Optional field support

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.

Library and main annotations names

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.

Arguments for methods activityScreen.open() and activityScreen.openForResult()

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.

Open method with Fragment parameter support

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);
}

Order of processing annotated fields

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.

Support for Services

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.