wei-spring / codenameone

Automatically exported from code.google.com/p/codenameone
0 stars 0 forks source link

IOS registered file/MIME type - not working on new VM #1376

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Using the old VM and a registered MIME type I am able to get a file URL via 
Display.getInstance().getProperty("AppArg", null). Now under IOS and the new VM 
it returns null.

Original issue reported on code.google.com by Stefan.A...@gmail.com on 26 Feb 2015 at 5:11

GoogleCodeExporter commented 9 years ago
Steve, can you evaluate this? 
Its based around this functionality: 
http://www.codenameone.com/blog/intercepting-urls-on-ios-android

Original comment by shai.almog on 27 Feb 2015 at 4:59

GoogleCodeExporter commented 9 years ago
Need more info.  I followed the instructions on this blog post to add a custom 
URL to my app:
http://www.codenameone.com/blog/intercepting-urls-on-ios-android

My ios.plistInject build hint was:
<key>CFBundleURLTypes</key>     <array>         <dict>             
<key>CFBundleURLName</key>             <string>com.codename1.issue1156</string> 
        </dict>         <dict>             <key>CFBundleURLSchemes</key>        
     <array>                 <string>myapp</string>             </array>        
 </dict>     </array>

I have attached my test case.

If I open the app cold by entering a url like myapp://ggg in safari, it 
correctly reports the URL in the AppArg property.  If the app is already 
running in the background, and I open a URL in Safari, the start() method is 
not called, but I can click the button to see that the AppArg has been applied 
correctly.

Please provide a test case.  I'll reopen this issue when one is received.

Original comment by st...@weblite.ca on 27 Feb 2015 at 6:01

Attachments:

GoogleCodeExporter commented 9 years ago
I really do not know what to give as a test case. This is very simple.

<key>CFBundleDocumentTypes</key>
    <array>
        <dict>
            <key>CFBundleTypeName</key>
                <string>MyApp MyFile</string>
            <key>LSHandlerRank</key>
                <string>Owner</string>
            <key>CFBundleTypeRole</key>
                <string>Editor</string>
            <key>CFBundleTypeIconFiles</key>
                <array>
                    <string>myfile.png</string>
                </array>
            <key>LSItemContentTypes</key>
                <array>
                    <string>de.sae.test.myfile</string>
                </array>
        </dict>
    </array>
<key>UTExportedTypeDeclarations</key>
    <array>
        <dict>
            <key>UTTypeDescription</key>
                <string>MyApp MyFile</string>
            <key>UTTypeConformsTo</key>
                <array>
                    <string>public.data</string>
                </array>
            <key>UTTypeIdentifier</key>
                <string>de.sae.test.myfile</string>
            <key>UTTypeTagSpecification</key>
                <dict>
                    <key>public.filename-extension</key>
                        <string>myfile</string>
                    <key>public.mime-type</key>
                        <string>application/myfile</string>
                </dict>
        </dict>
    </array>

I did another test - by opening my file in Apples mail apü. The funny thing is 
- it works if the app ist started anew. Then the start() method is called and 
Display.getInstance().getProperty("AppArg", null) delivers the right thing. If 
one then opens the file again the app is opened, the start() method is called - 
but Display.getInstance().getProperty("AppArg", null) gives the old value, 
whatever it was before.
Which consecutive file openings it works well.
I tested it. It is always the second time after restart of the app where 
Display.getInstance().getProperty("AppArg", null) fails to give the file that 
was opened. Any idias on that?

Original comment by Stefan.A...@gmail.com on 28 Feb 2015 at 4:06

GoogleCodeExporter commented 9 years ago
It looks like I was testing something different  (custom URL schemes).    For 
your test case, please also post some code showing how/when you are checking 
for "AppArg".  

Original comment by st...@weblite.ca on 28 Feb 2015 at 5:21

GoogleCodeExporter commented 9 years ago

Original comment by Stefan.A...@gmail.com on 28 Feb 2015 at 5:39

Attachments:

GoogleCodeExporter commented 9 years ago
Sorry that was my fault, I assumed this would be identical.

Original comment by shai.almog on 28 Feb 2015 at 5:49

GoogleCodeExporter commented 9 years ago
I see the problem.  The start() method is called before the URL callback 
occurs, so when you check the AppArg at the beginning of your start() method, 
it hasn't been set yet.   You can verify this by adding some sort of delayed 
action (e.g. through a Button action event) to be able to check the AppArg at 
will, and you'll see that it actually does get set even when the app was just 
being loaded from the background.  

The correct way to detect the loading of a file/URL is to implement the 
URLCallback interface.  See the test case I have attached for an example.

Original comment by steve.ha...@codenameone.com on 2 Mar 2015 at 6:05

Attachments:

GoogleCodeExporter commented 9 years ago
Steve, I'm not sure the URLCallbackInterface is the way to go since the 
behavior here is iOS specific. Unfortunately I can't think of a decent way to 
solve this because of the race condition where the app is launched and the 
callback is sent later.

Original comment by shai.almog on 2 Mar 2015 at 6:31

GoogleCodeExporter commented 9 years ago
The behavior on IOS and on Android is very different. It would be nice to have 
a description of how to handle this on both platforms.

There is also an issue under Android - see 
http://code.google.com/p/codenameone/issues/detail?id=1381

Original comment by Stefan.A...@gmail.com on 3 Mar 2015 at 11:13