Titanium JIRA Archive
Alloy (ALOY)

[ALOY-1336] Alloy Theme Fails to merge/overwrite the platform/iphone folder - specifically 'Settings.bundle' sub-folder

GitHub Issuen/a
TypeBug
PriorityCritical
StatusResolved
ResolutionCannot Reproduce
Resolution Date2017-03-15T21:41:51.000+0000
Affected Version/sn/a
Fix Version/sn/a
Componentsn/a
LabelsSettings.bundle, platform, themes
ReporterMalcolm Hollingsworth
AssigneeFeon Sua Xin Miao
Created2015-11-30T11:48:07.000+0000
Updated2017-03-15T21:43:02.000+0000

Description

Adding an iPhone *Settings.bundle* to a platform sub-folder of the theme folder does NOT **merges folders, overwrites files* as stated in the documentation [/Alloy Styles and Themes section](http://docs.appcelerator.com/platform/latest/#!/guide/Alloy_Styles_and_Themes-section-35621526_AlloyStylesandThemes-Themes). The *Settings.Bundle* will ONLY work if it does NOT appear within the theme and resides directly within the project platform folder instead. This process should work, according to both the documentation and the rules I helped define. Path of file when inside a theme; {noformat} {project}/app/themes/{theme}/platform/iphone/Settings.bundle/Root.plist {noformat} Example code within file 
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>StringsTable</key>
    <string>Root</string>
    <key>PreferenceSpecifiers</key>
    <array>
        <dict>
            <key>Type</key>
            <string>PSGroupSpecifier</string>
            <key>Title</key>
            <string></string>
        </dict>
        <dict>
            <key>Type</key>
            <string>PSTitleValueSpecifier</string>
            <key>Key</key>
            <string>Version</string>
            <key>Title</key>
            <string>Version</string>
            <key>DefaultValue</key>
            <string>1.0</string>
        </dict>
    </array>
</dict>
</plist>
However when the app is run to a simulator or a device - the contents of the simple example shown above are not used within the app. If the theme folder is not used (for reasons of testing) and instead located at the non-themed path of {noformat} {project}/platform/iphone/Settings.bundle/Root.plist {noformat} With the very same example code used previously it does perform correctly on both the simulator and the physical device. It appears obvious that NO 'merging and overwriting of files' are occurring on the themed _platform/iphone/Settings.bundle_ folder and potentially this may be true for ALL platform iphone child folders. The themed platform itself has been proven to work as the Android elements held within that folder are used correctly no matter which theme is used.

Comments

  1. Fokke Zandbergen 2015-11-30

    This seems to be a regression in the Titanium SDK. * Alloy pushes 2 CLI args to Titanium for custom i18n and platform dirs: https://github.com/appcelerator/alloy/blob/master/hooks/alloy.js#L178-L179 * Titanium was modified to let these override the default paths: https://github.com/appcelerator/titanium_mobile/pull/6602/files * But this was removed when [~cbarber] refactored the build process for TIMOB-18840: https://github.com/appcelerator/titanium_mobile/commit/57f6c23afc28379dfd7821c269bb9ec0f16e9cc8#diff-f430483233aa01af5b10df8390f9635dL3745
  2. Chris Barber 2015-11-30

    This sounds like an Alloy bug/limitation. I'm not sure exactly how the themes work, so it's hard for me to say. I'll move this ticket to Alloy for further triage. [~fokkezb] I'm not sure why \-\-platform\-dir was created, but now that you've brought it to my attention, I shall remove it from Android since it's not documented and it is not implemented in any other platform's build command. FYI, in Titanium SDK 6, there will be a behavior change with platform/iphone. In Titanium SDK 5.x and older, platform/iphone gets copied into the actual compiled application output directory. This is not consistent with other platforms and interferes with differential builds. All files in platform/* should get copied into build/<platform name>. So, in Titanium SDK 6, we fix this. Since Settings.bundle is an edge case, the iOS build will explicitly look for it and copy it to the correct location.
  3. Malcolm Hollingsworth 2015-11-30

    Why is this an 'edge case'? It is a folder with file in it residing inside the platform iphone folder. This can and should follow the same merge and overwrite rules. The logic is no different to android density folders with images inside them. So should I assume;

    This will not get fixed

    Because somehow it is confusing?

    Because a new version of the SDK 6.0 will change where all previous versions have located files for iOS extras?

    This is no longer related to 5.0.2 as I stated as it is an Alloy issue? If so why is SDK 6.0 the point it will get fixed if Alloy related?

    Sorry [~cbarber] but your comment has confused me more.
  4. Fokke Zandbergen 2015-11-30

    [~cbarber] it's a TIMOB bug in the sense that it no longer works since 5.x because the SDK no longer applies the --platform-dir argument added by TIMOB-17446 (a discussion you were mentioned in) to enable ALOY-858. So even if it's not documented it is a regression of a feature added in 4.x and we can't just take it out.
  5. Chris Barber 2015-11-30

    [~core13] We're getting off topic of this ticket, but it's an edge case because all files in platform/<platform> should be copied into the build/<platform> directory, not the compiled app output directory. iOS is the only platform that does this. However, this change would mean Settings.bundle would be copied into the build dir and so it's an edge case where we need it copied into the compiled app output dir. There is no "merge" logic. We only overwrite and that logic hasn't changed, only the destination. In Titanium SDK 5.x and older, Resouces, Resources/iphone, Resources/ios, platform/iphone, and platform/ios copy files to the same directory build/iphone/build/Products/<xcode target>/<appname>.app/. This makes no sense and it's not consistent. So, in Titanium SDK 6 I will fix this. Settings.bundle should probably go in the build dir anyways and we'll add it to the Xcode project and let Xcode copy it into the compiled app output dir. So, with regards to the Titanium SDK 6 change and *this* ticket, you have nothing to be worried about. Just know that files in platform/iphone will be copied to a different place in Titanium SDK 6. Ok, back on topic. Alloy theme files not being copied to the correct destination is an Alloy bug. The \-\-platform\-dir option is a hack. Alloy must not be lazy and must do things correctly. We'll triage it and eventually fix it.
  6. Fokke Zandbergen 2015-12-01

    [~cbarber] the chicken egg with Alloy theming i18n and platform is that if Titanium always reads from /i18n and /platform then Alloy must somehow first merge/overwrite the defaults in there with that from the theme and after Ti is done compiling revert that. Which is tricky (e.g. if the build fails). So that's why it works as it works (worked) now. I do agree it's hacky ;)
  7. Chris Barber 2015-12-01

    [~fokkezb] Sorry, why does Alloy need to revert the copying of files to the i18n and platform directories? Why aren't the i18n and platform directories treated just the same as Resources where they are nuked every build?
  8. Fokke Zandbergen 2015-12-01

    Actually... that might be a very clean solution. *classic* 
       /i18n
   /platform
   /Resources
    *Alloy* 
       /app/i18n
   /app/platform/
   /app/assets/
   
   /app/themes/mine/i18n
   /app/themes/mine/platform
   /app/themes/mine/assets
    It would be a tricky breaking change since but one we can check for by making sure there is a /app/i18n or /app/platform before we nuke the /i18n or /platform What do you think [~fmiao]?
  9. Malcolm Hollingsworth 2015-12-01

    To confirm - this only occurs as it is Alloy (which is the subject - so good). The root platform folder */project/platform/* is to be left empty as this now acts in the same manor as build & resources as noted above. During the Alloy build process;

    *whatever* is inside */project/platform/* is deleted

    *whatever* is inside */project/app/platform/* is copied into */project/platform/*

    *whatever* is inside */project/app/themes/theme/platform/* is copied into */project/platform/*

    no merges; simply copying and overwriting if previously existed

    The */project/platform* clean process could be part of each Alloy build (shown above), OR part of the ti clean or a new alloy clean. There would need to be caution that the clean process only occurs for alloy projects of course. Plus sufficient warning for existing projects. Same rules apply for *i18n*. Simple enough to work. This is essentially what I need to create in a jmk file due to the time factor.
  10. Fokke Zandbergen 2015-12-01

    yep, indeed... but for i18n it would merge.
  11. Feon Sua Xin Miao 2015-12-01

    When we were working on ALOY-858, we iterated through all the above suggestions. In fact, Malcolm's elegant solution was in the first PR and it was rejected, the reason given was that _source project files should never be overwritten/modified, specifically the root project i18n/platform files_. The 'hacky' solution was implemented under 2 limitations: 1. alloy compile should not modify source project files 2. titanium build looks for i18n and platform directories under the project root only A thorough account of the discussion are in the comments of ALOY-858. IMHO, this can be easily solved if we could all agree on that Alloy compile is allowed to manipulate the project root platform/i8n directories like what it has been doing to the Resource folder.
  12. Chris Barber 2015-12-01

    [~core13] Yes, that's what I'm proposing should be the official behavior. I'm not sure how close we are today to that behavior. [~fokkezb] We would only need to merge if an app has two xml files with the same name in separate folders (i.e. app/i18n and app/themes/mine/i18n). The Titanium build system will merge all *.xml files into a single i18n file. So Alloy really just needs to check if the destination i18n xml file exists and if so, append a number or something to the filename. For example, your Alloy app has app/i18n/en-US/strings.xml and app/themes/mine/i18n/en-US/strings.xml, then during compile Alloy would copy app/i18n/en-US/strings.xml to i18n/en-US/strings.xml and copy app/themes/mine/i18n/en-US/strings.xml to i18n/en-US/strings2.xml. Much easier and faster than doing a merge. I agree with [~fmiao] that Alloy apps should be able to modify the root i18n and platform directories just like the Resources directory.
  13. Malcolm Hollingsworth 2015-12-01

    Alloy apps must be able to modify root elements, as it already does with Resources. Given Alloy is the framework used to create the files used to build an app this should go as far as all elements within the app and not just generating the JS code and moving some assets. So if the App is Alloy based then the Platform and i18n root folders follow the exact same rules as the Resources one already does. This simple rule 'correction' allows a far greater degree of control for more than Alloy apps with themes and allows future beneficial features to not be stifled based "we cannot modify root elements" as Alloy already does. So I vote "let us stop pretending Alloy does not already modify root elements" as it simply persists in harming the evolution of the dev platform going forwards. BTW anyone not building an Alloy app when starting a new project is harming themselves, their client, their future productivity not to mention basic human decency rules. Just saying.
  14. Malcolm Hollingsworth 2016-02-17

    Any guesses on a time to release on this yet? This month, quarter, half year, year, decade? Trying not to sound flippant - simply trying to see how much hope I should place in this moving forward.
  15. Malcolm Hollingsworth 2016-06-28

  16. Feon Sua Xin Miao 2017-03-15

    Looks like this has been solved by ALOY-1365. Please reopen if seen again.

JSON Source