Closed octohub closed 8 years ago
Would love your opinions @markpragma and @kenkyee.
Depends on how much stuff is in each file. If you have lots of different parts of the app, separate files makes more sense...e.g., in one of our apps, we have different style files per section of app to keep size down but the styles are mostly extracted out of the layout files (something agrosner did initially). I'd suggest breaking a file up if it gets hard to find something...
@kenkyee Valid point, but I would say that is not the norm. I think we should default to keeping resources of the same type in the same file, and if it becomes apparent we need to switch to separate files, then do that. Making separate resource files the default creates unnecessary overhead when we probably won't end up needing them anyway.
Yep, I'd agree...just saying the style guide shouldn't say leave everything in the same file because it becomes unmanageable w/ some projects...
I don't have a strong opinion on this, but after giving it some thought, I think I lean towards keeping separate files.
please see tl;dr version below
In general, as a developer, I never, ever look at the file tree view in order to find something. If I am, something went wrong and time is being wasted / overhead incurred, regardless of file structure.
If I need to make a change to a string resource, I'm probably already looking at its usage in the layout editor or Java code. If that's the case, I'm just going to highlight it and CMD+B. What file it's in doesn't matter to me in this method, other than I might end up looking at a new tab with 6 lines, or with 600 lines - but either way, the line i'm interested in is highlighted.
On the other hand, if someone who doesn't have Android Studio needs to make changes to the strings for whatever reason, they don't have the same tools we have to facilitate digging through 600 lines of xml.
Also, if two people both add strings to the monolith strings.xml
, a potential merge conflict occurs. It's an easy one to resolve, but merge conflicts are always a bummer.
I think it's probably unnecessary to group strings by activity though. More effective might be by feature. I.E. not strings-cat-detail.xml
and strings-cat-list.xml
, just strings-cats.xml
.
tl;dr version
From my perspective, keeping strings in separate files has a really unlikely and small benefit, and no drawback. Moving to a monolith strings file has no benefit, and a really unlikely and small drawback. I prefer the former.
Also, if two people both add strings to the monolith strings.xml, a potential merge conflict occurs. It's an easy one to resolve, but merge conflicts are always a bummer.
I did not think of this, but like you said, it is trivial to resolve.
I think it's probably unnecessary to group strings by activity though. More effective might be by feature. I.E. not strings-cat-detail.xml and strings-cat-list.xml, just strings-cats.xml.
I suppose my bitter experience with multiple string resource files comes from the fact that the way they were separated on my last project was very annoying. Way too granular, every single screen essentially has it's own file and some only have a few strings.
Thanks for your thoughtful response @sigmabeta.
@dkim89 do you have any thoughts on this?
Yeah I would lean to keeping app wide values in the base file, then breaking out other values into separate files but on a per feature basis. And I'm with @sigmabeta on using Android Studio actions to navigate around the various files rather than the Project tree. Lots of good stuff out there on how best to do that, such as http://hadihariri.com/2014/06/24/no-tabs-in-intellij-idea/.
Ok, sweet. Thanks @markpragma. As I seem to be in the minority here, I will be closing this PR. Going forward I think I can mitigate my frustration with multiple resource files by separating them in ways that make sense, and not simply do it for every single part of the app.
Thank you everyone for chiming in :+1:
I have found creating separate resource files for different parts of the app to be cumbersome to work with. I have discussed this with @Mervyn-Raizlabs and he agrees.