NoSuchMethodError using Twilio IPMessaging - xamarin

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);

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
});

Services.AddTransient() Vs Services.AddBot()

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.

Calling Xamarin.Android Interop from Xamarin.UITest

I've created a method in the first Activity of my app which I have added the Java.Interop.Export tag to, as below.
[Export]
public string MyInvokeMethod(string myString)
{
_webview.LoadUrl("http://www.google.co.uk");
return "test";
}
And I'm trying to call this method in Xamarin.UITest with the below.
app.Invoke("MyInvokeMethod","test");
However, nothing seems to happen. I looked into the logs of the Android device and it seems as though it is trying to call the method but it gets below error.
"Method not found with correct argument types. Trying to type convert."
Is there a way to get this to work? I have tried with passing an argument, without passing an argument, adding a name for the method in the attribute but nothing has worked.
EDIT
After speaking to one of the Xamarin developers they believe it might be an issue with how MvvmCross handles the Android Activity.
I think you should add
[Export("myInvokeMethod:")]
on top of your method, instead of only add [Export]
Someone using xamarin uitests might find this useful too: https://forums.xamarin.com/discussion/57662/xamarin-forms-uitest

Testing ViewModels in MVVMCorss

I have just started working with MVVMCross for a cross platform app and I am having a hard time figuring out how to test my ViewModels. I tried following the testing done in TwitterSearch and ran into problems. Specifically in the MockSetup.cs I found that in the latest version of MvvmCross there no longer seems to be a IMvxViewDispatcherProvider but that is ok because I think its functionality has been rolled up into the IMvxViewDispatcher. However, when actually setting up the dipatcher for my test cases there is no RequestNavigate method for the dispatcher anymore and I can not find an implementation of MvxShowViewModelRequest. So I can not actually get any tests for my ViewModels to work.
I also tried to follow the testing here http://slodge.blogspot.com/2012/10/testing-viewmodels-in-mvvmcross.html but again ran into issues with missing MvxOpenNetCfServiceProviderSetup.
So in summary, my issue has been getting a MockSetup working so that I can test my ViewModels. If I could just be pointed in the right direction on the dispatcher, I think that would help.
It looks like you are trying to test an mvvmcross v3 application using mvvmcross vnext objects.
The updated twitter search test for v3 is at https://github.com/slodge/MvvmCross-Tutorials/tree/master/Sample%20-%20TwitterSearch/TwitterSearch.Test
This test uses a single special mock object: https://github.com/slodge/MvvmCross-Tutorials/blob/master/Sample%20-%20TwitterSearch/TwitterSearch.Test/Mocks/MockMvxViewDispatcher.cs
The role of this mock is just currently:
to provide a very simple main thread (it uses the current thread)
to provide simple storage for any navigation requests.
You can see it used in:
https://github.com/slodge/MvvmCross-Tutorials/blob/master/Sample%20-%20TwitterSearch/TwitterSearch.Test/HomeViewModelTest.cs

BackgroundAgent trying to do updates to my AdControl?

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.

Resources