Getting java.net.MalformedURLException in MonoDeveloper
Hey I'm new to MonoDeveloper. I am trying to pipe libgdx code to iOS platform. My Libgdx code works fine on desktop and android phone. But when I run it on an iPhone simulator with MonoDeveloper, it gives me this error:
Unhandled Exception: 0 iosgame
[ERROR] FATAL UNHANDLED EXCEPTION: java.net.MalformedURLException: unknown protocol: file.
0x000e8932 mono_handle_exception_internal_first_pass + 3058 1 iosgame
0x000ea012 mono_handle_exception_internal + 1602 2 iosgame
0x000eab5f mono_handle_exception + 47 3 iosgame
0x0012dcb2 mono_x86_throw_exception + 306 4 ???
0x0b73df8f 0x0 + 192143247 at java.net.URL..ctor (java.net.URL,string)
<IL 0x00004, 0x00018> at java.net.URL..ctor (string)
<IL 0x00003, 0x00018> at java.net.URI.toURL ()
<IL 0x00023, 0x00064> at IKVM.Internal.AssemblyClassLoader.MakeResourceURL(System.Reflection.Assembly,string)
<IL 0x00016, 0x0006c> at IKVM.Internal.AssemblyClassLoader/AssemblyLoader.FindResources(string)
<IL 0x0003c, 0x00084> at IKVM.Internal.AssemblyClassLoader/<GetResourcesImpl>c__Iterator0.MoveNext()
<IL 0x00068, 0x00070> at IKVM.Internal.AssemblyClassLoader/<GetResourcesImpl>c__Iterator0.MoveNext()
<IL 0x003dc, 0x0069f> at IKVM.NativeCode.ikvm.runtime.AssemblyClassLoader.getResource(java.lang.ClassLoader,System.Reflection.Assembly,string)
<IL 0x00034, 0x0009c> at ikvm.runtime.AssemblyClassLoader.getResource(java.lang.ClassLoader,System.Reflection.Assembly,string)
<IL 0x00006, 0x00018> at ikvm.runtime.AssemblyClassLoader.getResource (string)
<IL 0x00000, 0x0001c>
Please give me a suggestion where I am wrong.
source to share
I found the answer to the question myself.
The stack trace will tell you which line of your Java code is causing the MalformedURLException. So for example: Example.java:208
Search line 208 of the .java example and see which file it came across.
Then find this file inside Xamarin / mono studio and right click on it.
Then go to Build Option> BundleResource.
source to share
Based on a previous question (from the same user) I think this is the result of a chain reaction . Apple recently began to ditch applications executables larger than 60MB.
It's a huge, main hello world app built with Xamarin.iOS is less than 3MB and that's the total app size . The executable itself is under 2.2MB and includes the Mono runtime, associated base class libraries (BCLs), and unrelated user code.
This 2.2 MB size is now achieved as the BCL is linked (by default, the Link SDK is used to build the device). This means that everything that is not used in the BCL is deleted. If the BCL was not connected (you can disable it, if you're interested), then the size of the executable file is 46MB - more than 20 times! (and that part of the reason why you should never disable the linker on device assemblies).
LibGDX is a Java library. It can work with Xamarin.iOS by converting to .NET using IKVM. It converts GDX library and in the Java class library. This is all user code (i.e. stuff you added), not SDK (i.e. code posted by Xamarin). IOW, the default linker does not remove anything from GDX (or IKVM libraries).
So, by default , everything in GDX and Java (the lib class) in the AOT goes into its own executable, which brings it to Apple's limit (which was the previous question ).
The previous answer was to use Link All Assemblies , IOW to run the linker in all application managed code. This removes a lot of unused code and results in smaller applications and executable size (see hello world example above).
However, it goes back to the main constraint of the linker. It uses static analysis to detect unused code - and reflection (from .NET or Java) is dynamic. Therefore the linker needs help to save (using an attribute [Preserve]
or XML file ) that is used for reflection.
I ca n't see how the Java code processing protocols are handled, but I'm pretty sure it uses reflection to load the schema-based type (for example file
) and for that type (s) so that it works correctly at runtime. After saving, I am confident that the application will work as expected (and not be too large).
source to share