Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-13113] Ti.Platform.name and osname ='android' for iPhone simulator under certain circumstances

GitHub Issuen/a
TypeBug
PriorityMedium
StatusClosed
ResolutionInvalid
Resolution Date2016-08-29T18:13:32.000+0000
Affected Version/sn/a
Fix Version/sn/a
ComponentsAndroid, CLI
Labelsalloy, android, build, cli, i0S, simulator
ReporterDavide Cassenti
AssigneeAshraf Abu
Created2013-03-17T22:47:38.000+0000
Updated2017-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:

build for the iPhone simulator

build for the USB connected Android phone

running the iPhone simulator I clearly see Ti.Platform.name='android', as well as osname, which of course easily crashes my app on the simulator

This must be a brand new bug in the Studio/SDK since I have been developing like this for a few months now, and only recently seeing this weird behavior.

Comments

  1. Davide Cassenti 2013-03-18

    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
  2. Mark Mokryn 2013-03-18

    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
       <Alloy>
       	<Window class="container">
       		<Label id="label" onClick="doClick">Click me after building for Android device</Label>
       	</Window>
       </Alloy>
       
    testWin.xml
       <Alloy>
       	<Window class="container" id="testWin">
       		<Label id="label" onClick="doClick">Click on this label, in a new window that is demand loaded after Android build completes</Label>
       	</Window>
       </Alloy>
       
    index.js
       function doClick(e) {  
       	var win = Alloy.createController('testWin').getView();
       	win.open();
       }
       $.index.open();
       
    testWin.js
       function doClick() {
       	if (Ti.Platform.name === 'android') {
       		alert ('android');
       	} else {
       		alert('iPhone');
       	}	
       }
       
    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:
       function doClick() {
           alert("android");
       }
       
    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.
  3. Mark Mokryn 2013-03-18

  4. Davide Cassenti 2013-03-19

    Hi, good catch. I did replicate with the steps you provided. Moved the bug to ALOY-571
  5. Tony Lukasavage 2013-03-19

    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?
  6. Mark Mokryn 2013-03-19

    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....)
  7. Tony Lukasavage 2013-03-19

    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.
  8. Federico Casali 2013-03-19

    Verified as reproducible using TiSDK 3.0.2.GA and 3.1.0.v20130319082237 - Alloy 1.1.0 master - Xcode version 4.6
  9. Ingo Muschenetz 2013-03-21

    [~fcasali] Can you get around the issue by cleaning the project?
  10. Tony Lukasavage 2013-03-21

    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.
  11. Chris Barber 2013-03-21

    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:
        ti build -p ios --force-copy
        
    Now, remembering --force-copy is going to be a pain, so add this before the "build.pre.compile" hook in Alloy's CLI plugin:
        cli.addHook('build.pre.construct', function (finished) {
            cli.argv['force-copy'] = true;
            finished();
        });
        
    That should do the trick.
  12. Tony Lukasavage 2013-03-21

    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!
  13. Chris Barber 2013-03-21

    @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.
  14. Tony Lukasavage 2013-03-22

    lol, I'll be sure to have the docs guys add that advice to the guides.
  15. Federico Casali 2013-03-22

    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.
  16. Tony Lukasavage 2013-05-10

    [~cbarber] I'm using the --force-copy flag like this o nan alloy app:
        ti build -p ios --force-copy
        
    And none of my code changes update in the app. I'm seeing the log message that the flag is "working":
        Forcing copying of files instead of creating symlinks
        
    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.
  17. Chris Barber 2013-05-10

    @Tony, OK, I'll have to investigate when I have time.
  18. Ingo Muschenetz 2013-10-10

    [~tlukasavage], is this not related to ALOY-760?
  19. Tony Lukasavage 2013-10-11

    [~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.
  20. Chris Barber 2016-08-29

    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.
  21. Lee Morris 2017-03-22

    Closing ticket as invalid with reference to the above comments.

JSON Source