As discussed during engineering week, we should step away from generating custom asset-image hashes and instead use the real name. Here are some reasons I had:
* Custom hashes make it extremly uggly to deal with custom storyboards that include images / icons. This is very common, since storyboards should show an empty UI state, that can have tab-icons in it. I've made one for a customer last year and it took me double the time dealing with hashes than implementing a full split-view storyboard
* Custom hashes cannot be used in Hyperloop. There could be utility-methods for it, but that attacks performance again when working with a larger number of images to process
* Custom hashes cannot be used in native module. Same struggle than above. For the [Ti.AlternateIcon](
https://github.com/ccavazos/titanium-alternate-icons) module, I needed to basically copy and paste half of our TiFilesystem API's into the module to generate the hashes.
* The *only* contra-point is that a developer might have an image in different directories that has the same name. Besides the fact that no one should ever do that anyway, I don't think anyone actually does. At least I didn't do in 50+ Titanium apps.
So what do we need to change?
* Remove the hash-generator from our iOS build
* Loop through the images to detect possible filename-duplicates. Throw error if any matches.
* Remove the hash-bridge in our Titanium core
* Add a note in the release-notes, so people having custom hashes right now can migrate
That's it!
Why have the watch status been removed from this? We need to prioritize this in order to support dark mode in iOS 13 properly. cc [~amukherjee] [~shaig]
As discussed with Chris on Slack, I strongly disagree with him. On the native side (both iOS and Android) it will fail as well if you use same filenames, even when in different directories. Simply because modern asset managers do not use paths anymore but store them in a flat hierarchy. Hashing them was a *bad* idea in the first place and got worse every time it was touched. Issues with web views, launch screen images and now dark mode are making this an unmaintainable mess for the future and should be reverted. And again, I am speaking from a developer perspective where I have to suffer with this in really really large projects. Moving forward, the asset catalog plays a more and more important role in the iOS ecosystem (tvOS support, on-demand resources, iOS 13 binary optimization), so any non-conformant naming convention makes this harder in Titanium. And no, a cross-platform asset management system is not requested by anyone, so I wouldn't suggest to spend time on that, since it only breaks more overhead to the getting started with Titanium.
[~vijaysingh] The only thing that comes to mind is the storyboards. If someone has a custom storyboard launch screen and wants to use a specific image, today they would need to build the app, then open the generated Xcode project to view the asset catalog and see what the hashed name is, then refer to the hashed image in the storyboard. If you remove the hashing, then their images won't be hashed and they won't be resolved. If the simply update their storyboards, then they're good to go. This is technically a breaking change, but we could add code that continues to hash images referenced from a storyboard -or- add code that fixes the images in the storyboard as it's copied to the build dir. The latter seems a little less horrible.
PR - https://github.com/appcelerator/titanium_mobile/pull/11437 Note - For testing, create alloy app. Replace app folder with attached folder. Run the app, click on label. It should add three image view on window.
FR Passed. PR Merged.
Verified based on the test instructions. Verified on: Mac OS: 10.15.1 SDK: 9.0.0.v20200214090043 Appc 8.0.0-master.6 JDK: 11.0.4 Node: 10.16.3 Studio: 6.0.0.201911251516 Xcode: 11.2 Device: iPhone XR(v13.2.2)