[TIMOB-1077] Titanium.App.getArguments() not working on OS4 beta4

Need some more information, including a test case and which version of Titanium you're using.

Here are the info.
Mobile SDK 1.3
iPhone SDK OS4 beta4

Attached is the console log, running on an iPhone 3Gs with OS4 beta4. Using KitchenSink 1.3. (changed the name to be able to use my Profile.

Start KitchenSink 1.3
Go to Phone Tab
Go to GeoLocation
The data will be filled, only the Reverse Geo data is blank

Sorry wrong update :-)

Here is the proper additional info for this bug.

Info:
Titanium MObile SDK 1.3
xcode_3.2.3_and_iphone_sdk_4_beta_4
iPhone OS4 beta4 for iPhone 3Gs (build:8a274b)

================================================== Steps to reproduce on the Device:

Edit the Custom URL handler on info.plist

   <key>CFBundleURLTypes</key>
       <array>
          <dict>
             <key>CFBundleURLName</key>
                <string>com.appcelerator.kitchensink</string>
              <key>CFBundleURLSchemes</key>
               <array>
                 <string>kitchensink</string>
               </array>
           </dict>
       </array>
   

Now open Safari Mobile on the Device
type the Custom URL passing some query strings: kitchensink://?foo=bar
Kitchen Sink will open and then will crash.

================================================== Find the Files Attached, Crash Log and Console Log.

Hard to say if this is a bug on our end. I see

   Tue Jun  1 12:51:08 unknown UIKitApplication:com.acarlos.KitchenSink[0x80c9][1227]
   

In your output, and

   <string>com.appcelerator.kitchensink</string>
   

in the plist. Was the plist value changed so that you could test on device?

Hi Stephen, I needed to change the AppID, so I could use my Provisioning Profile and to test on my Device.

But When I run on Simmulator I use the default KitchenSink AppID: com.appcelerator.kitchensink

I am doing some more research on this as well.

Try changing the value for the CFBundleURLName key to match the application ID. I don't get crashes in simulator when they match, and can't test on device since I don't have a 4.0-capable one handy.

Mistakenly marked as invalid. Didn't know that getX() functions were the same as accessing the X property.

Yeah, this works for me in simulator when the CFBundleURLName matches the application ID.

I will close this ticket if you can confirm that any application which does not support backgrounding (built for 3.1) running on device does not crash when the CFBundleURLName and the app ID match.

(Edited to remove iPhone 4.0 information)

(from [76a7494c760ea73db037f719e67ab3a700d8a750]) [#1077 state:open] plist change to allow KS to test getArguments(). Note that under 4.0, we do not support changing the arguments; this may not even be possible. Have to look into it. http://github.com/appcelerator/titanium_mobile/commit/76a7494c760ea73db037f719e67ab3a700d8a750"> http://github.com/appcelerator/titanium_mobile/commit/76a7494c760ea...

Hi Guys, you are right. It seems that on OS4 I can't get the arguments when coming from a 'Pause'.

let me give you some more background on what I am trying to achieve.

What I am trying to do is an oAuth 3-legged authorization process with Yahoo!, then my App does the call for authorization and opens Safari, after authorizing the app, I have created a callback that calls the Custom URL passing the access token and the verifier as arguments. Then my app checks the arguments and completes the oAuth process.

It worked very well on 3.1, but for 4.0 first I needed to change my startup listener to 'resume', but then the arguments are always empty.

Anyway, now I have no Idea how to proceed with the whole oAuth 3-legged process as Safari will not be able to open back my App.

I would like to be able to give you a workaround, but the NDA prevents me from discussing this issue with you further in a public forum. All I can recommend is looking through (4.0) documentation on the relevant subjects.

Ok, thanks, so will it be possible to retrieve arguments from Safari on Titanium 1.4?

What my Safari does e call a callback like this, passing the oauth verifier and a Token.

Myapp://?oauthv=something&token=otherstuff

This starts my app, but getArguments does not work with "Resume".

Do you have any suggestion on how to retrieve this data back with my app?

Thanks once again.

It is possible to retrieve arguments from Safari, but only on startup. We will very likely not get to this feature in time for 1.4.0. I can't advise you further until the NDA is up because the workaround does not involve Titanium directly.

Ok, thanks Stephen.

With the advent of iOS4 I can finally give you the bad news. When apps resume from background, they are NOT passed any new information about arguments; they are only passed arguments on startup. This means that if it's absolutely critical that your app always be able to get startup argument information, it must opt-out of background execution.

You can do this by changing the UIApplicationExitsOnSuspend key in the Info.plist file to have a YES value.

All right, thanks for the update Stephen.

It appears it is possible to receive the URL if the process is backgrounded, but a different approach is required. From the developer forums:

• (BOOL)application:(UIApplication )application handleOpenURL:(NSURL )url

Also, check that you're using

• (void)applicationDidFinishLaunching:(UIApplication *)application;

and NOT

• (BOOL)application:(UIApplication )application didFinishLaunchingWithOptions:(NSDictionary )launchOptions

If you're using the second one, handleOpenURL is ignored.

Would it be possible for Titanium to expose this information in the future? For dictionary and study applications, the ability to switch quickly between them is important.

(sorry for the bold, I had only meant to mark off what was quoted and what wasn't)

Thank you for pointing this out - it was not covered in any of the backgrounding documentation. I will see if I can get it in before 1.4.0 drops.

(from [8c573ed5806e0477e143f40e272314bfe130d054]) Closes #1077: Apps can now get URLs on return from backgrounding. Thanks to Damien Elmes for the solution. http://github.com/appcelerator/titanium_mobile/commit/8c573ed5806e0477e143f40e272314bfe130d054"> http://github.com/appcelerator/titanium_mobile/commit/8c573ed5806e0...

Thanks for the quick fix!

Hi There,

so do you know how can I get the arguments that are passed from an CustomHandle, here is some sample code I am trying, but the arguments object is empty.

on App.js I have added the following code, trying to trap the data from the customHandle from a Resume or Open

    var argu = Ti.App.getArguments();
    var argumentos = JSON.stringify(argu);
    // var theImage = null; //capture image from gallety and/or camera
    // var theThumbnail = null; //capture image thumbnail from gallety and/or camera
    
    
    // trap app Open event and retrieve the arguments from safari
    Ti.App.addEventListener('resume', function(e)
    {
    
    Ti.API.info("MemePost is being RESUMED, getting Arguments");
    
    Ti.API.info("Arguments from RESUME on app.js " + argu);
    
    a = Ti.UI.createAlertDialog({ 
        title:'URL Arguments from RESUME on app.js',
        message: argu
    });
    a.show();
    
    });
    
    // trap app Open event and retrieve the arguments from safari
    Ti.App.addEventListener('open', function(e)
    {
    
    Ti.API.info("MemePost is being OPEN, getting Arguments");
    
    Ti.API.info("Arguments from OPEN on app.js " + argumentos);
    
    a = Ti.UI.createAlertDialog({ 
        title:'URL Arguments from OPEN on app.js',
        message: argumentos
    });
    a.show();
    
    });
    

What am I doing wrong?

This change unfortunately doesn't appear to work. When I resume my app with a url, the argument doesn't appear. It only appears later, on pause, and then on the next resume.

Example:
1) Start MyApp
2) Open Safari (closing MyApp)
3) Safari: myapp://first
4) MyApp launched to the front. In

    Ti.App.addEventListener('resume', function() {
      if (Ti.App.getArguments() == 'myapp://') { // this will be true

    

    
    
    
    

    alert('This is always true the first time resume is called');
    

    
    
    

      }
    });
    

Hopefully this all makes sense. Somehow the value is getting set too late.

You need to use the 'resumed' event. There are two separate events on iOS due to the fact that some information is only available after resuming execution.

Thanks! That solved the problem.