Get resources in converter? - xamarin

What is the best way to get resource string or drawable in convert method of MvxConverter?
Can I access to current context or I have to manage static tracking?
Thanks

What is the best way to get resource string or drawable in convert method of MvxConverter?
There are some standard bindings that get access to resources, e.g.
MvxImageViewDrawableTargetBinding.cs
MvxImageViewImageTargetBinding.cs
There's also at least one example of using resources in a custom binding:
FavoritesButtonBinding.cs
You could do similar code in an MvxValueConverter rather than in a custom binding if you would prefer it (but that converter would not then be usable across multiple platforms).
Can I access to current context?
You can normally get access to Android Context objects using Mvx.Resolve<T> on:
IMvxAndroidGlobals.cs
IMvxAndroidCurrentTopActivity.cs
For i18n text cross-platform alternatives to Android strings are also available - from Vernacular and from Mvx - see http://slodge.blogspot.co.uk/2013/05/n21-internationalisation-i18n-n1-days.html
I have to manage static tracking?
No idea what this is. Sorry

Related

Xamarin Forms - calling a shared code method from the platform project

I have read the two other questions on SO regarding this and I wanted to know if there is a good solution for that now / best practice.
Long story short, we use an SDK which is written natively and we've wrapped it so that it works on Xamarin.Android and Xamarin.iOS. It has asynchronous callback methods. I need to call a method in the shared code when a callback is received in the Android project for instance.
There's a lot of info for doing the opposite - using DependencyService. How about in my scenario? Does anyone have experience with an app like this and what's the best approach to keep code clean and do this using MVVM?
The options I know are:
Using a static App instance - this is what we currently do.
MessagingCenter
Anything else?
Actually I've never seen anyone recommend usage of MessagingCenter for anything else than communication between ViewModels so I am not sure it is recommended here. Also, I need to know the sender object type so I need a reference to the class in the platform specific project.
I would recommend you to use messagingCenter to pass data or call method between shared project and platform project. You can just send a new object instead of the class in the platform specific project.
Also, have a look at using eventhandler as I mentioned in this answer may help someone who want to call from the shared project into the platform specific one.
BTW, I mean you can even pass an object as TSender if it is not necessary to use:
MessagingCenter.Send<Object>(new object(), "Hi");
MessagingCenter.Subscribe<Object>(new object(), "Hi", (sender) =>
{
// Do something whenever the "Hi" message is received
});

How can i set the api version on a generic controller when loading a plugin?

I have some plugin's which are basically input and output type definitions. I have a generic controller which i can add to the mvc pipeline. All works fine.
but I'm having trouble setting the api version on this generic controller. I know you can set this based upon an attribute on top of the controller class. But since you can't have this dynamic (attribute) don't allow it, i have no way to set the version for each instance of the generic controller.
Currently i just compile the controller for each instance on runtime and register i using the roslyn compiler.
is there a way to set the api-version somewhere in the pipeline of registering controllers in the mvc pipeline and endup with different api versions endpoints.
This can be achieved by using the Conventions API. It was designed to support this exact type of scenario:
https://github.com/microsoft/aspnet-api-versioning/wiki/API-Version-Conventions
This will only work on closed-generics, but it shouldn't be too much work to make that happen. Here's a couple of basic examples:
// typed, closed generic
options.Conventions.Controller<GenericController<PlugIn1>>().HasApiVersion(1,0);
// untyped, closed generic
var controllerType = typeof(GenericController<>).MakeGenericType(new []{typeof(PlugIn1)});
options.Conventions.Controller(controllerType).HasApiVersion(1,0);
You can also author your own custom conventions a la IControllerConvention. This approach could be used to version all controllers that inherit from GenericController<>. Then you just need to add it to the conventions like this:
options.Conventions.Add(new PlugInControllerConvention());
Hopefully that's enough to get you started. Feel free to ask more questions.

Alloy - Controller.addTopLevelView?

Recently I came across someone's code. The Alloy Markup is empty with just <Alloy />. In its controller, it adds a view using $.addTopLevelView().
How come I can't find any documentation regarding this function?
Good point. It might be because it's considered private, although it would normally start with _ to indicate that since JS doesn't actually support private methods.
It is also against the very idea of Alloy to not use the XML file for the markup but instead use "classic" Titanium code in the controller together with this method.
However, it might be a good idea to do a PR against the following file to request this to be documented:
https://github.com/appcelerator/alloy/edit/master/Alloy/lib/alloy/controllers/BaseController.js

Sharing code between NSDocument and UIDocument

I have created a document-based app that uses Core Data. I created the mac version first, and now that it's working properly, I am moving on to create an iOS version of it.
I just can't get my head around how to maximize code reuse between the iOS/mac versions, with respect to the Core data bit, since they don't use the same classes.
My document class that handles saving and such is a subclass of NSPersistentDocument. My intention is that a well-designed model class should work in both environments, especially since I don't do all that much fancy stuff with regards to Core data.
Now, since NSPersistentDocument isn't available in iOS, I hit a wall. I tried to get around this by using #if TARGET_OS_MAC and TARGET_OS_IPHONE and in that manner make it a subclass of UIManagedDocument in the iOS version. That obviously would have been convenient, but I can't seem to make it work like that. And it's really looks quite messy, since there are a lot of other stuff that has to be conditionalized as well.
I also tried building the classes atop of NSDocument/UIDocument instead, implementing the Core data hooks myself, but it also looks quite messy, leaving me thinking it's not the right way to go.
The question:
To me, it seems like a good idea to reuse the same document class between the iOS/mac versions, but maybe I'm being naive.
What's the best way to do this?
Should I forget about the code sharing and create a separate document class for the iOS version that emulates all the methods present in the mac version?
Am I right that the code you're wanting to share is model-related? I suggest refactoring that code to a separate object, which both an NSDocument and UIDocument contain (as rickster suggested above).
I use a DocumentRoot Core Data entity with its own NSManagedObject subclass, but if there are no properties you want to manage using Core Data, you can just subclass NSObject.
This may sound strange, but NSDocument and UIDocument are actually controller classes. (To be specific, they're part of the model-controller.) Their jobs are to load the model, set up windows, and save the model. If you need to provide an interface for higher-level access to model objects, it could be in a document root or model helper class instead.
Similarly NSPersistentDocument's job is to configure the managed object context and the persistent store and handle loading and saving. It doesn't necessarily need to provide a complete interface for accessing the model.
(Bringing this over from my comment.)
In general, the situation where you have two classes which must inherit from different superclasses but which also want to share a lot of code is composition. Put the shared code in a separate class; your NSDocument and UIDocument subclasses can each keep an instance of that class, and message it whenever they need to invoke that shared code. (Though as #noa mentions, you might want to consider whether all of that code belongs in your document class to begin with.)
Of course, then you might end up writing a bunch of methods that read like:
- (id)doSomething {
return [sharedController doSomething]
}
That can get to be a pain... so you might want to look into Objective-C's message forwarding system.

Calling protocols from a framework?

I am currently using the NinevehGL engine to develop a simple app. This engine has a class called NGLMesh that stores openGL data for an instance of this class. From NinevehGL's documentation for the copyInstance method located at http://nineveh.gl/docs/Protocols/NGLCopying.html it says:
"The NGLCopying is an extension of Cocoa protocol NSCopying.
It defines two basic copying modes to NinevehGL objects:
Copy: Makes a new clone, copying all the used memory.
Copy Instance: Makes a new clone, but clonning just the superficial memory."
I would like to copy one of my NGLMeshs into a new NGLMesh instance using this method, however Im having a hard time understanding protocols and how to call them. Could someone offer some explanation? The internet has proved to be a little confusing thus far.
From what I gather (although Im most likely wrong) I need to "adopt" the NGLCopying protocol in the class that I want to use it with. I cant seem to find much information on how to accomplish this.
A protocol is just a list of messages that a class can respond to. Think of it as an extension of the class's #interface block, only it can be shared by several classes. If you are just trying to copy another class that already conforms to this protocol (such as NGLMesh), you don't need to do anything special — just do [yourNGLMeshObject copy] or [yourNGLMeshObject copyInstance].

Resources