Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Warning when implementing ArgsBundler #53

Closed
Tagakov opened this issue Apr 18, 2016 · 3 comments · May be fixed by #67
Closed

Warning when implementing ArgsBundler #53

Tagakov opened this issue Apr 18, 2016 · 3 comments · May be fixed by #67
Projects
Milestone

Comments

@Tagakov
Copy link

Tagakov commented Apr 18, 2016

When I am copying implementation of any ArgsBundler from sources, for example NoneArgsBundler, Android Studio warns me about unchecked method overriding. Is it a bug or my misunderstanding? What is the reason of using this generic in interface: ? Why we should can't use T generic type instead?

@sockeqwe
Copy link
Owner

What exactly do you mean? NoneArgsBundler is for internal purpose only (to tell FragmentArgs that no custom ArgsBundler should be used). ParcelerArgsBundler per se is not "checked" therefore this warning will be displayed.

This warning should be supressed by the library.

Regarding the type <T>. The readme had an error that might was misleading. I have changed that.

For instance to write a custom ArgsBundler for types of Date you have to implement something like this:

public class DateArgsBundler implements ArgsBundler<Date>{

    @Override public void put(String key, Date value, Bundle bundle) {

        bundle.putLong(key, value.getTime());
    }

    @Override public Date get(String key, Bundle bundle) {

        long timestamp = bundle.getLong(key);
        return new Date(timestamp);
    }

}

public class MyFragment extends Fragment {

    @Arg ( bundler = DateArgsBundler.class )
    Date date;

}

@sockeqwe sockeqwe reopened this Apr 20, 2016
@sockeqwe sockeqwe added this to the 4.0 milestone Apr 20, 2016
@Tagakov
Copy link
Author

Tagakov commented Apr 22, 2016

The way how to implement custom ArgsBundler is clear. I just want to pointed out that when using Android Studio auto generating for interface implementation we will have :

public class DateArgsBundler implements ArgsBundler<Date> {

    @Override
    public void put(String key, Date value, Bundle bundle) {

    }

    @Override
    public <V extends T> V get(String key, Bundle bundle) {
        return null;
    }

}

Which is obviously incorrect. When we fix method get like this

    @Override
    public Date get(String key, Bundle bundle) {
        return null;
    }

We will have Unchecked overriding warning. This happens because the return type of get method in parametrized interface ArgsBundler<T> is <V extends T> V.

So we need to suppress it with @SuppressWarnings("unchecked")

Maybe this is reasonable approach, but I cant understand the reason. Can you please explain it?

@sockeqwe
Copy link
Owner

sockeqwe commented Apr 22, 2016

Ah, now I understand what you mean.

The reason was Parceler and other libraries that are working in a similar fashion.

But lets stick with Parceler. The problem with parceler is that the api Parcels.wrap() and Parcels.unwrap() are defined as follows:

public static <T> T unwrap(Parcelable input);

The problem is that those methods from Parceler have generic type methods parameters and that java generics are not strong enough to detect a safe cast somehow:

fragment.foo = fooBunder.get(key, bundle);

Where foo is some class Foo annotated with @Parcel. Java can't resolve that type correctly otherwise, so <V extends T> fooBundler.get() requires method arguments too. Otherwise we would have write a custom ArgsBundler<Foo> for each type annotated with @Parcel to ensure type safety.

If you know a better way, don't hesitate to prove me wrong an I will change that ...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

Successfully merging a pull request may close this issue.

2 participants