cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Brooks <mich...@michaelbrooks.ca>
Subject Re: [cordova-cli] Merges Directory
Date Tue, 26 Mar 2013 16:03:57 GMT
As a heads up, I'm not trying to sell the naming convention approach.
Simply, I've used both approaches for multiple projects between 2009-2012.
I've found the merges/ to become confusing, error prone, and encouraging a
platform-specific coding mindset.

I can see the benefits, but they seem somewhat minor, so I'd prefer the

compartmentalization of platform files.  If I'm working on a specific
> platform, I can work in that platform's directory.  Having the files spread
> out in a monolithic directory—especially once an app supports more than a
> couple of platforms—might get a little cumbersome.


Arguments for or against either approach can usually be countered, because
they solve the exact same problem. The main difference is organization and
being able to quickly eyeball whether a given file/folder will be replaced
by a platform-specific one. This important when you a generic www/ file
that is overwritten by only one platform. Too many times, I've edited the
 generic file only to realize that there was also a platform-specific
implementation of it.

The other consideration for ./merges are other assets: icons, and
> splashscreens. (Which would then require 2x or something for
> retina/hdpi situations.)


The platform resource problem should not be solved with the merges
directory. The config.xml parser should move the platform's resources and
delete the other platforms' resources.

Michael

On Tue, Mar 26, 2013 at 8:36 AM, Max Woghiren <maxw@chromium.org> wrote:

> I can see the benefits, but they seem somewhat minor, so I'd prefer the
> compartmentalization of platform files.  If I'm working on a specific
> platform, I can work in that platform's directory.  Having the files spread
> out in a monolithic directory—especially once an app supports more than a
> couple of platforms—might get a little cumbersome.
>
>
> On Mon, Mar 25, 2013 at 5:34 PM, Michael Brooks <michael@michaelbrooks.ca
> >wrote:
>
> > Just like to provide an alternative suggestion to the merges/ directory
> and
> > here everyone's thoughts.
> >
> > While doing client work at Nitobi, each of our build scripts had similar
> > functionality to merging platform-specific web assets. Below, I'll
> describe
> > what I've experienced and make a suggestion on an improvement.
> >
> > 1. Separate Merges Directory
> >
> >   app
> >   |__ merges/
> >   |    |__ android/
> >   |__ www/
> >
> > In the above structure, the android/ directory is a mirror of the www/
> > directory. When a file exists in the android/ directory, it will replace
> > the file in the www/.
> >
> > I believe this is how the merges/ directory in `cordova-cli` works.
> >
> > I've experienced two main problems with this approach:
> >
> > - difficult to keep track of what files are replaced, since you need to
> > cross-reference between directories
> > - too easy to start developing in the merges/android/ directory instead
> of
> > www/
> >
> > 2. Unified Merges Approach
> >
> > app
> > |__ www/
> >      |__ index.html
> >      |__ myfile.js
> >      |__ myfile.android.js
> >      |__ myfolder/
> >      |__ myfolder.android/
> >
> > I've had much greater success with this approach.
> >
> > When a file ends with a dot platform (optional extension) name (e.g.
> > myfile.android.js), it will be renamed to remove the platform name (e.g.
> > myfile.js). This will work on both files and directories.
> >
> > This makes it extremely easy to keep track of what files and directories
> > are generic or platform specific. I haven't actually noticed any downside
> > to this approach and I used it for 2 years.
> >
> > Thoughts?
> > Michael
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message