I tried to run the Marketplace Test Kit and it failed at Capability Validation with a bunch of calls that Microsoft.Advertising.Mobile.dll was trying to make. This is understandable, but in no instance am I attempting to update the AdControl from the BackgroundAgent. The closest thing I can think of is in this:
public ScheduledAgent()
{
if (!_classInitialized)
{
_classInitialized = true;
// Subscribe to the managed exception handler
Deployment.Current.Dispatcher.BeginInvoke(delegate
{
Application.Current.UnhandledException += ScheduledAgent_UnhandledException;
});
}
}
Is the Application.Current call what is trying to engage the ad control? If so, how can I prevent it from doing so?
Edit: here is the output of one of the error messages:
Unsupported API cannot be used by a background agent. Assembly Microsoft.Advertising.Mobile.dll was trying to use Microsoft.Phone.Tasks.PhoneCallTask::.ctor.
Okay, it wasn't related to the code sample at all. What was the issue is that I was generating my ad controls via a Windows Phone Library I created. This library's Models were being used by the background agent and this apparently made the test kit believe the application was using the Ad logic somehow.
I removed the Ads.cs and migrated the things it was doing into the pages themselves and this resolved the issue.
edit: I think it is safer to say that it wasn't the Marketplace Test Kit thinking that the background agent was using the AdControl's library, but rather it had the ability to do so. I figure that is worth distinguishing.
Related
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
});
In the latest bot samples, we can see that bot is being added to services collection as below
services.AddTransient<IBot, MyBot>();
but in older samples, we saw below approach
services.AddBot<MyBot>(options => { });
Here I am trying to understand the benefits of adding bot using AddTransient() over using AddBot().
What I know is that internally AddBot uses AddTransient only, then why use AddTransient. Referred remarks section from this link.
You can see in the source code that the AddBot methods are used for automatically adding a bot adapter to DI in addition to the bot and for configuring bot-related options like credentials and error handling. The conventions for using the Bot Builder v4 SDK were very different when those samples were made, and the bot's configuration along with its credentials were loaded from something called a bot file. The current convention for using the SDK is much easier because it takes advantage of ASP.NET Core automatically loading the app's configuration from appsettings.json. Since we're not using AddBot anymore you'll notice that the adapter is added to DI explicitly, and you can configure things like error handling and middleware either by accessing the properties and methods of the adapter directly or by deriving your own adapter class, as seen in the samples.
I have created a console application with azure media service.
in the app i am using the plugin
windowsazure.mediaservices
the way i am doing is
static IAsset CreateAssetAndUploadSingleFile(string filePath, string assetName, AssetCreationOptions options)
{
IAsset asset = _context.Assets.Create(assetName, options);
var assetFile = asset.AssetFiles.Create(Path.GetFileName(filePath));
assetFile.Upload(filePath);
return asset;
}
so i just want to know whether this plugin will work on xamarin(i am not a xamarin devoloper) as its a portable project.
if its not do we have any alternative plugin?
my basic purpose is upload and encode.
That package is for our current .NET SDK
https://www.nuget.org/packages/windowsazure.mediaservices
It does not support .NET Core. See the dependencies.
It's not compiled for Xamarin though, so I don't believe that it works in Xamarin, but i'm not a Xamarin expert at all.
What is your scenario exactly? Why would you want to call the Media Services account directly from Xamarin anyways? You would only need to do that if you are creating a management application for the account Administrator. Otherwise, dont put Media Services directly into any client code! You should hide it in your middle-tier, and only pass Streaming URLs or SAS locators to the client application to upload content to.
For the upload from phone scenario, middle tier should create an Asset, get a writable SAS Locator for the Asset, hand that to the client side. Client can then use Azure Storage APIs to upload the content to that SAS URL directly (it ends up in an Azure storage container then.)
I believe that Xamarin has client side support for the Azure Storage APIs available.
As john answered, you don't do this stuff on a client, you will need to use SaS tokens and what not. I could explain everything here, but there are some nice guides and examples online.
Build 2018 video explaining how it works (including Azure Functions): https://www.youtube.com/watch?v=dEZkQNNpSIQ&feature=youtu.be&rel=0
The github example of this video: https://github.com/Azure-Samples/xamarin-azure-businessreview
To understand it better, I recommend this guide, it is old but it does cover the entire process, just make sure to combine new documentation with this old one.
Old docu: https://learn.microsoft.com/en-us/previous-versions/msp-n-p/dn735912(v%3dpandp.10)
Official current documentation: https://learn.microsoft.com/en-us/azure/media-services/previous/media-services-dotnet-upload-files#upload-multiple-files-with-media-services-net-sdk
Probably useful for new readers.
I'm trying to use Twilio IP Messaging in a simple Xamarin Android project, but unfortunately running into issues with the latest Nuget libraries: Twilio.Common (v. 0.3.4.2) and Twilio.IPMessaging (I tried both 0.15.0.4 and 0.15.0.6).
My setup is complicated by the fact that the online Xamarin samples are obsoleted within the recent library releases --- so instead of calling methods to Initialize the Twilio SDK, my code simply invokes Twilio.IPMessaging.IPMessagingClient.Create. The input parameters are a bit unclear, but reading elsewhere I'm trying to bind using a signature:
IPMessagingClient IPMessagingClient.create(
Context context,
AccessManager accessManager,
IPMessagingClient.Properties clientProperties,
Constants.CallbackListener<IPMessagingClient> listener)
Invoking it this way, I invariably receive an error message: NoSuchMethodError with details:
"no static method \"Lcom/twilio/ipmessaging/IPMessagingClient;.create(Landroid/content/Context;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Lcom/twilio/ipmessaging/IPMessagingClient;\"
Any ideas? I like the idea of using Twilio, but between the outdated documentation and unfortunate crashes it's looking simpler to just implement messaging myself.
While I check nugets can you provide more insights
why IPMessagingClient.create(...) and not IPMessagingClient.Create(...)?
Is linker turned on? Turn it off please. Then check.
Signature is
public static IPMessagingClient Create (Context context, Object acess_manager, Object properties, Object listener);
I am working on Firefox Addon development, I have successfully built the addon, but it is giving me validation error on submission as "Warning: Your add-on uses an interface which bypasses the high-level protections of the add-on SDK. This interface should be avoided, and its use may significantly complicate your review process." on these lines.
const { Cc, Ci } = require("chrome"),
nsIIOService = Cc["#mozilla.org/network/io-service;1"].getService(Ci.nsIIOService),
nsIStyleSheetService = Cc["#mozilla.org/content/style-sheet-service;1"].getService(Ci.nsIStyleSheetService);
I am able run the addon on my machine, but couldn't submit due to this flagged validation check.
Is there any alternative way?
It is completely acceptable to use that. There is not alternative to some APIs in the SDK. That validation is a warning because those features are not frozen and can change at anytime. Can you post a screenshot of the validation blocking your submission? It should be allowed through.
While not entirely identical in function to nsIStyleSheetService, sdk addons can use page-mod to inject stylesheets into some or all content pages.