In my application all images, local HTML pages etc. are marked as "Build action Content".
I have just realized that there is also "Resource".
Which one should I use for images and which one for HTML pages to display in a UIWebView?
Currently I use images like this:
this.oImgLoginLogo.Image = UIImage.FromFile ( "Data/Images/ball.png" );
But in Monotouch.Dialog I see this line:
static UIImage arrow = Util.FromResource (null, "arrow.png");
But arrow.png is also marked as "content"...?
Puzzled.
What are the disdavantages/advantages of each option?
Embedded resources are embedded into the dll or exe file, and accessible from .NET reflection APIs. Content files are bundle resources and are copied into the app bundle (which is simply a directory), and accessible using file APIs or MonoTouch's Apple bundle APIs.
MonoTouch does support embedded resources, but they aren't straightforward to use from Apple-specific APIs, which are designed to use things from the app bundle. However, embedded resources may make more sense when you aren't dealing with MonoTouch-specific APIs, or when you're writing libraries that are portable to other platforms.
MonoTouch 4.0+ does support Content files in dll libraries - behind the scenes they're mangled into embedded resources when the library is compiled, so you can share it as a single dll file, then they're unpacked into the app bundle when the app is compiled.
My guess is that MonoTouch.Dialog was using embedded resources and not bundle resources because it's a library and predates MonoTouch 4, therefore the file marked as Content is a bug in the project.
In the .NET world, the difference is that during the build process a file marked as Content gets copied to the output folder, while a Resource file becomes part of the DLL itself.
AFAIK, MonoTouch doesn't includes resources into the build, because that doesn't exist in iOS, so that's why you always use Content. A final step then zips the directory with the executable and the content files into the .app file, which is how iOS expects it. The same thing is valid for MonoDroid.
The difference between MonoTouch and MonoDroid in the API exist because the idea of those frameworks is to translate, almost one-to-one, the APIs available in those platforms, instead of creating one interface that supports all platforms equally.
Related
I'm working on a project which is an open-source cloud, similar to Nextcloud. It also provides a file upload and manage feature.
I'd like to have a shell namespace extension which displays those files and folders in the Windows Explorer. Moving, deleting, renaming and editing files / folders should be possible.
Data is available from a REST API or my Electron Client.
I know NodeJS and only some C#.
Is it possible whith NodeJS / Electron to create a shell namespace extension?
If not, are there any free libraries which make this task easier?
Windows Explorer uses 'COM' as its extension model. Therefore, technically speaking, you can use whatever you like, as long as it supports COM.
For NodeJS, you'd be dependent on the runtime to provide the COM support for you and to wrap the appropriate APIs. I'm not aware of any project that does this for the Windows Shell APIs. Here is one for the WinRT APIs.
For C# (.NET), again you'd be dependent on the runtime for COM support. .NET does expose that to you; although it is messy. There are a few projects which wrap the shell APIs and try to hide the COM interop goo as best they can for you.
Here is an open source one.
Here is a commercial one.
Be aware that Microsoft advises against building shell extensions which require a runtime (EG: .NET). The runtime may be loaded into processes that aren't expecting it. Therefore, in practice, Microsoft expects you to use C/C++ to build shell extensions. Here is the Microsoft supplied sample project. It is written in C++.
I'm using Mono For Android (probably will use MonoTouch too soon) and MVVM-Cross to port of a Windows Store app (Work on progress by another team, in Parallel).
Unfortunately the Windows store app team started of without using MVVM-Cross. That lead to some Windows specific libraries (like Windows.ApplicationModel.Resources) being scattered across code that should be portable across other platforms (for eg "Windows.ApplicationModel.Resources.ResourceLoader" was used for localization).
I was wondering if there's a cross-platform alternative (or may be a mvvm-cross plugin) for some of these windows libraries. Or may be guidance on how to create my own plugin/alternative.
There is a resourceloader plugin which uses windows package content files and android asset files.
See https://github.com/slodge/MvvmCross/blob/v3/Plugins/Cirrious/ResourceLoader/Cirrious.MvvmCross.Plugins.ResourceLoader.WindowsStore/MvxStoreResourceLoader.cs
It is used in (for example) the customer management sample in order to load an XML data file - see https://github.com/slodge/MvvmCross-Tutorials/blob/master/Sample%20-%20CustomerManagement/CustomerManagement/CustomerManagement/Models/SimpleDataStore.cs
It's also used internally in the json i18n plugin.
If you want a different implementation on one platform, then you can override the plugin for just that platform.
If you want a different implementation on all platforms, then it should be easy to create your own plugin, or to inject implementation of an interface on each platform. See the explanation of mvvmcross IOC in Instantiation of ViewModels and Service classes
What are the correct steps to creating a bindings project for a Framework versus a library? (Yes, they are close to the same thing, but NOT the same, the framework is a directory structure with header files, library and resources). These are what I've come up with, note that none of the Framework specific steps are documented as far as I can tell at the Xamarin web site (please prove me wrong).
Create the bindings project via MonoDevelop wizard.
Generate the ApiDefinition.cs and StructsAndEnums.cs files with btouch or by hand.
Copy the file from the root of the framework directory to lib.a (e.g., ArcGIS to libArcGIS.a) and add it to the project. It is important to note that the file without any file extension in the framework directory is in fact a library file.
?? Include framework resources ??
You'll notice that I get foggy at the third step. How to you add these resources to the bindings project? The large part of the bindings project links and runs fine, but I think it crashes at times because it is missing an expected resource.
You must (a) create a C# contract that describes the Objective-C contracts and how you want your projection into C# to look like, and (b) statically distribute the library with your project.
To kick the automatic population of the linkwith.cs you must rename the framework library (for example MyFramework) to use the library pattern (in this case, "libMyFramework.a")
Resources you have to select and flag as resources, they will be bundled directly into your app, and extracted when the library is consumed.
Due to MonoTouch using dll's within the actual app, how secure is this approach? For instance, if someone is using the Mono.Security.dll, couldn't someone swap out that dll with one which implemented the methods and perform a code injection attack on an app?
how secure is this approach?
As much as any existing ones I know :-)
couldn't someone swap out that dll
No for several reasons.
You cannot change the applications files. That would break the digital signature and iOS won't execute it. That alone removes a MitM attack;
the code from every .dll is already compiled to native code (by the AOT compiler) and part of the main executable binary. Swapping a new .dll won't change the code that is executed;
the .dll that is deployed on devices is stripped (for release builds). There's no IL (code) inside it since it would not be useful (we can't JIT on iOS). Even if you add a .dll with IL code (e.g. a debug build) it won't be executed (again it would require JITting);
Why are the .dll deployed ? for their metadata (e.g. if you use reflection)
Final note: MonoTouch produce native ARM executables just like Objective-C would.
I was going to try Subsonic, you can generate DAL with buildProvider element in an ASP.NET website project. But I get curious why Web applications or windows applications do not support BuildProvider.
PS: I know for Subsonic there is one other option to use it with other than BuildProvider, but I just get curious.
It doesn't work because of the different way things are compiled in web application projects vs. website projects. From what I read on MSDN, it has to do with the fact that in web app projects, all your code files are compiled into a single assembly using MSBuild before deployment, but Build Providers are used to generate code that is compiled at runtime (from your App_Code folder).
In website projects, all of your code is compiled at runtime so it all plays nicely together.
You could possibly hook it into your pre-build event, and call the sonic.exe with the proper command line.