[TIMOB-17446] Build scripts should accept flags indicating the path to the platform and i18n folders to use for a build
GitHub Issue | n/a |
Type | Improvement |
Priority | High |
Status | Closed |
Resolution | Fixed |
Resolution Date | 2015-01-30T00:27:59.000+0000 |
Affected Version/s | n/a |
Fix Version/s | Release 4.0.0 |
Components | CLI |
Labels | n/a |
Reporter | Tim Poulsen |
Assignee | Tim Poulsen |
Created | 2014-08-01T21:34:01.000+0000 |
Updated | 2016-03-10T09:59:59.000+0000 |
Description
Our initial solution to ALOY-858 (use Alloy themes override the contents of a project's platform and i18n directories) has proven unworkable and pointed out the need to handle this at the platform level.
Our attempted solution was to make a backup copy of those folders in the build directory, merge themed versions of the i18n/platform folders to the original locations, proceed with the build, then restore the originals when done. This has created problems with inconsistent states, original files being lost, etc.
The better solution for Alloy would be to merge the originals and theme copies to a folder within build, then direct the platform to build using those versions. For that, we need new flags to the build scripts.
As you implement this, please consider how we might also theme the tiapp.xml, as this has also been requested. Again, that should be handled at the platform level not by Alloy making temp copies of files.
Attachments
To reiterate my comment from the original ticket; I strongly believe that including the tiapp.xml file into the files that can be included via theme folders would add the final hurdle of theming once the platform and i18n folders have been merged correctly. Assuming each theme was aimed at providing the same base app but to different clients or markets then the appid and if required elements like the google map api values would also need to swap over. The simplest solution would be to have the tiapp.xml file inside the root of each theme folder. If found this copy is used in place of the normal app version. Whilst deep merging could be used I do not believe it is required, a simple file swap out is the smartest approach. I imagine many professional app houses have a need to manage several variations of one base app engine and having manual steps in the process lead to potentially dangerous miss-managed store releases. The idea of the theme folders are superb; adding i18n and platform folder is a great move and championed by myself - but the tiapp.xml is the final hurdle to complete the process.
[~cbarber] Thoughts on the request?
Any movements, thoughts or love coming to this ticket?
titanium_mobile PR https://github.com/appcelerator/titanium_mobile/pull/6602 titanium_mobile_windows PR https://github.com/appcelerator/titanium_mobile_windows/pull/98 This change adds two new build flags: *
--i18n-directory <path>
*--platform-directory <path>
For a functional review, use the attached project. 1. Build the app withti build -p ios
to get an app with three basic labels. Check the Settings app and look for the stockclassic app's setting options. 2. Build the app again withti build -p ios --platform-directory somedir/myplatform --i18n-directory somedir/myi18n
. This time, the strings and the Settings option indicate that you're using the "My" versions of the i18n strings and platform/iphone/Settings.bundle files. 3. Repeat for Android withti build -p android
4. And again withti build -p ios --platform-directory somedir/myplatform --i18n-directory somedir/myi18n
. This time, you'll get the "My" strings. Return to the home screen, open the app tray. The app icon should have red lines drawn over it (icons supplied for high, xhdpi, and xxhdpi densities) Blackberry and MobileWeb should respect the i18n strings, but offer no support for platform files. Windows is untested, as at this stage it doesn't offer support for internationalized strings or platform-specific files.Merged PR into master.
Verified the implementation. Closing. Environment: Appc Studio : 4.0.0.201503301039 Ti SDK : 4.0.0.v20150330105813 CLI : 4.0.0-alpha Alloy : 1.6.0-alpha MAC Yosemite : 10.10.2