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

Replace @ActivityStarterConfig(converters = { ParcelarArgConverter.class }) to @Arg(bundler = ParcelarArgConverter.class) #15

Closed
Kolyall opened this issue Jun 6, 2017 · 1 comment

Comments

@Kolyall
Copy link

Kolyall commented Jun 6, 2017

#4
Seems like you didn't see last answers and advices. Can you refactoring code to make this support:

@Arg(bundler = ParcelarArgConverter.class) StudentParceler mItem;

@org.parceler.Parcel
public class StudentParceler {
    private int id;
    private String name;
    private char grade;

    public StudentParceler() {
    }
}

instead of using this:

@ActivityStarterConfig(converters = { ParcelarArgConverter.class })
class MyActivity extends Activity {
@Arg StudentParceler student;
//...
}

@org.parceler.Parcel
public class StudentParceler implements IsParcel {

    private int id;
    private String name;
    private char grade;

    public StudentParceler() {
    }

//...
}
@MarcinMoskala
Copy link
Owner

I am really busy for next month. I would like to keep previous format because thanks to it there is no need to define converter in every line. But I am open for definition in arg annotation that will be designed to define converter just for single element. Feel free to contribute.

Also bundler is not correct name in this case. It was in FragmentArgs where it was used just to add elements to Fragment bundle. While this library is supporting also Intents (in Activities and Services) this name was not adequate. Also this would lead to problem of separate definitions for Intents and Bundles what could lead to problems and confusion. From them same reasons I decided that way of saving element to Intent or Bundle should be done by library. Thanks to that we can be sure that there are no key problems. As a conclusions I decided that instead of class that is defining how custom type should be saved, there should be class that is defining a way how element is changed from not supported object to one that is supported. And this are converters.

Also about Parceler - I am planning to make build-in support for this feature. Then no converter will be needed for them. I am just really overloaded right now. According to my plans, I would be able to sit to that feature in August. Unless someone will decide to implement it earlier. Another time - feel free to contribute.

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

No branches or pull requests

2 participants