Hard-coded Extra parameters

[MattiaPrimavera]

Bundles extra parameters are hard-coded, this being above all error-prone, furthermore causing some code duplication ... plus hard-coding would require changing the variable name in several spots since they do not all refer to the same final constant value ...

Proposed solution: create a Parameters.java file where to store all extra (added by putExtra) parameters, and refactor the code base in order for hard-coded strings to disappear.

[maniac103]

No. We had it like that, and we changed it to intent (activity) and instance (fragment) factory methods to make it obvious what extra is actually used and required in a given class.
If anything we could introduce (private) string constants in each class, but I'd consider even that overkill.

I'd also be interested in where you see code duplication going on there.

[MattiaPrimavera]

I did not meant removing makeIntent methods but only moving for instance "owner" hard-coded string, which is part of several extra bundles, into a separate file containing a list of strings only, not a list of Bundles or Intent ... So every info will stay attached to its fragment / activity, but we'll reuse string constants among multiple screens

[maniac103]

Sorry, but what additional would that provide? Would writing AssortedBundleExtraNames.OWNER be more readable than "owner"? I seriously doubt that.
If your concern is string duplication in the final binary, I'd leave that up to the compiler. I know C compilers are pretty good at merging string constants; I'd be very surprised if the Java compiler weren't as well.

[MattiaPrimavera]

Well it's simply not good practise to hard-code strings :

• that would be Extras.OWNER, yes more readable, highlighted as a final constant by the IDE, directly showing it's a key string.

• the main interest is sharing those constants among multiple screens, instead of declare them again. In case of changing one constant parameter value, the change would be restrained to the Extras file

Once the OWNER param declared in a file, we don't worry anymore of its actual value ...

[maniac103]

I don't see a value on sharing those constants. They're private for each file (IOW: not of interest outside of each file), and their actual value is totally irrelevant. They also won't be changed - why should they?
Also the IDE won't show 'it's a key string' (what differentiates a 'key string' from any other string, BTW?), because it simply can't know where it's used.

[MattiaPrimavera]

They may not be this private if they re declared exactly the same across multiple screens ... Why not to simply declare one single final constant value, and refer to it from other classes?

What I mean is that if I had another screen using OWNER value, hard-coding it again is more error-prone than using a constant value ... That's stays my opinion, and it's nothing that will revolution the project anyway ...

[MattiaPrimavera]

what differenciate ...

Well the IDE highlight color :P

[Tunous]

I agree with @maniac103 on this one. There is no need to share these between multiple classes. Even though they use the same strings "repo", "owner" it doesn't make them something that's worth sharing.

IMO the best way is to declare them as private constant fields separate for each class.

[MattiaPrimavera]

@Tunous +1 on private final constants to address hard-coding

[MattiaPrimavera]

Partially solved @Tunous #719