[TIMOB-9079] Tooling: Organize "Resources" folder with a "platforms" directory

GitHub Issue	n/a
Type	New Feature
Priority	Low
Status	Open
Resolution	Unresolved
Affected Version/s	Release 2.0.1
Fix Version/s	n/a
Components	Tooling
Labels	cb-tooling, core
Reporter	Tony Lukasavage
Assignee	Unknown
Created	2012-05-09T12:59:33.000+0000
Updated	2018-02-28T20:04:21.000+0000

Description

It would make the Resources folder in a Titanium project much cleaner if we had a platforms folder, under which all specific platform folders, like iphone, android, mobileweb, would reside. It just makes for less clutter in the overall project. While they serve 2 different purposes, we may also want to consider condensing what can be done with the root-level platform directory, and what can be done in the Resources/PLATFORM directories. Just throwing ideas out for discussion, but perhaps a layout like this would work... * Resources ** app.js ** platform *** android **** native ***** AndroidManifest.xml ***** res ****** values ******* strings.xml **** project ***** app.js *** iphone *** mobileweb This is probably not an ideal layout, but it gives an idea of how we can organize all platform-specific elements in one location without continue to crowd the project structure.

Comments

Neeraj Gupta 2012-05-22

Imposing rigid structure may be counterproductive and possibly break existing applications. We already have the "platform" directory that is intended to hold platform-specific resources. We may just need to document it better.
Tony Lukasavage 2012-05-23

My concern is that the pollution of the Resources directory grows with each new platform we add. Soon a developer will have android, iphone, mobileweb, and blackberry dumped into their Resources path before they even start their project. As these folders pile up, they make for harder organization when a developer is attempting to establish their own structure, be it MVC or otherwise, or even eventually having ZipTi in their project. It seems to me that when a developer is defining a project structure, they will have a much easier time visualizing and creating it if they have 1 special folder to worry about accounting for instead of 4-5. I understand that we have a platform directory already, and I thought it may be beneficial to find a way to combine the project-level platform directory with the Resources-level directory, so as to provide a single home for all platform-specific code and resources. As stated above, I don't necessarily think that the structure I proposed is the best, or even a good one. I just wanted to get a conversation going on how we can better organize code and folders in such a way as to facilitate the building of scalable applications. We are imposing structure now, just in a less structured manner. I'm suggesting we locate that imposition in a single, intuitive location. And yes, I share the concern of this potentially causing problems for existing apps. I don't think that precludes us from talking about how we can improve the structure of future (and many existing) apps though.
Stephen Tramer 2012-05-23

No. We should not do any special processing of the Resources directory (your suggestion potentially breaks many existing apps by treating Resources contents in a special way, which we do not do). Again, the platform-specific resources are copied in at the time of build - or should be.
Chris Barber 2013-08-02

I was just talking with Bryan and he had a great idea. Instead of creating a "platforms" directory in the Resources directory, create "Resources-ios", "Resources-android", "Resources-mobileweb" (and so on) that would live NEXT to the Resources directory. This way things are explicit, more elegant, backward compatible, and we don't have to jump through hoops to blacklist platform folders from being bundled into the built app. I very much would like to add support for this in 3.2.0. Thoughts?
Tony Lukasavage 2013-08-02

Very much more explicit and backwards compatible, though I'd disagree with it being elegant. It seems just as messy (if not moreso) as does having all the platform folders listed at the top-level of Resources. I don't really see the advantage to moving them in this manner. That is, I don't see any advantage to the developer. It might make our lives easier under the hood, but the developer is not getting any kind of win in terms of organization here.
Ingo Muschenetz 2013-08-02

I agree that I don't like the Resources- folders. I'm not positive what the proper solution is yet, though.
Ingo Muschenetz 2013-09-20

My feeling is this will be solved as part of ti.next. I don't see this as pressing to solve for 3.2.0.

JSON Source