[TIMOB-13113] Ti.Platform.name and osname ='android' for iPhone simulator under certain circumstances
GitHub Issue | n/a |
---|---|
Type | Bug |
Priority | Medium |
Status | Closed |
Resolution | Invalid |
Resolution Date | 2016-08-29T18:13:32.000+0000 |
Affected Version/s | n/a |
Fix Version/s | n/a |
Components | Android, CLI |
Labels | alloy, android, build, cli, i0S, simulator |
Reporter | Davide Cassenti |
Assignee | Ashraf Abu |
Created | 2013-03-17T22:47:38.000+0000 |
Updated | 2017-03-22T20:58:07.000+0000 |
Description
This one appears straight voodoo but please check it out.....
I am developing my app for iPhone & Android. I often use the iOS simulator while having an Android phone connected to my Mac by USB. Here are the steps to reproduce:
I am unable to replicate the problem. I followed the steps mentioned, both trying to leave the iOS Simulator running (I do alert the value of Ti.Platform.name every X seconds, or re-building for it. In both cases, I always see the right value. Maybe, if you can share the code you are using, I can verify if this is a bug on our side. Thanks
OK - I think I tracked it down, and it appears to be an Alloy issue. Here's how to reproduce (note tool versions above): Index.xml
testWin.xml
index.js
testWin.js
Now build for iPhone simulator, leave it open and just follow the onscreen instructions :) The reason I think it's an Alloy bug is that here's what I see inside Resources/alloy/controllers/testWin.js:
Alloy turned Ti.Platform.name into a build-time constant and wiped out the "if", which I don't believe is the intent. In any case, I guess the iPhone simulator is for some reason using the file in the Resources directory which was later created for the Android build.
Hi, good catch. I did replicate with the steps you provided. Moved the bug to ALOY-571
I don't know if there's much I can do about the iOS sim using files in the Resources directory. It is necessary for Alloy to modify those files on each build so that the proper conditionals are used. I'll take a look into the situation though to narrow down exactly what is happening. What version of Alloy are you using?
I'm using stock 3.0.2GA tools - i.e. Alloy 1.0.0 This bug was a nasty one to hit, until the realization came that it was related to Android builds. Since Alloy rewrites the Resources directory, perhaps what is needed is an arch-specific Resources??? BTW - I don't believe this was occurring in pre-1.0.0 (not 100% sure on that, but close to it....)
In talking with Chris Barber he told me that all files from the Resources folder are symlinked to the ios simulator. This means when changes occur to those files, they show up in the ios simulator as well. This is what is causing this problem. For the time being I'm going to move this to TIMOB. WHile this issue presents itself in Alloy, it may need to be handled at the platform/CLI level.
Verified as reproducible using TiSDK 3.0.2.GA and 3.1.0.v20130319082237 - Alloy 1.1.0 master - Xcode version 4.6
[~fcasali] Can you get around the issue by cleaning the project?
Federico can confirm, but I don't think that would help since a clean shouldn't impact the files in the Resources folder, where this issue is originating.
Got an idea. I added a simulator-only flag in 3.0.2.GA that copies all resources instead of symlinking them. Simply do this:
Now, remembering --force-copy is going to be a pain, so add this before the "build.pre.compile" hook in Alloy's CLI plugin:
That should do the trick.
I assume that --force-copy will have a more-than-negligible hit on build time? I'm comfortable with this option existing and simply pointing it to developers that want to use it rather than imposing a potential build time speed decrease on all developers who couldn't care less. Unless I'm wrong about the time it takes to copy versus symlink. In any case, thanks Chris!
@Tony, yes, it will increase build time. In theory subsequent builds would copy only the files that changed, but the build scripts are that smart. In the meantime, I recommend upgrading to an SSD.
lol, I'll be sure to have the docs guys add that advice to the guides.
iPhone simulator behavior looks totally dependent of the Resources folder, so cleaning the project does not change the behavior. Changes in the behavior can be obtained if removing/rebuilding the Resources folder. For example: 1. Build on iOS (app is running) 2. Build on Android (app is running). iOS simulator is now relying of files built for Android, so if clicking on the label we get the 'android' label. 3. Instead of clicking on the label, remove the Resources folder and compile them again, this time for iOS (alloy compile --config platform=ios) 4. Click on the label Result: iPhone label is correctly displayed Also, closing and restarting the iOS app after point 2. , it gives an error, in this case for 'Ti.Platform.Android.physicalSizeCategory' is undefined, for the Resources files are the ones being compiled for Android.
[~cbarber] I'm using the --force-copy flag like this o nan alloy app:
And none of my code changes update in the app. I'm seeing the log message that the flag is "working":
but I can't update my app at all. The alloy hook and everything runs, everything recompiles, but something in the --force-copy process is just not updating the files. It's only when I remove the --force-copy flag that this starts working again, thereby putting us in the same position we started in. I'm using version 3.1.0 of the CLI.
@Tony, OK, I'll have to investigate when I have time.
[~tlukasavage], is this not related to ALOY-760?
[~ingo] This is the result of symlinking being used for ios sim builds. ALOY-760 most likely would be an indirect way to workaround this issue.
This is no longer valid. Starting with Xcode 7 and iOS 9, we can no longer symlink files, thus this shouldn't be an issue.
Closing ticket as invalid with reference to the above comments.