We are using premium SDK and OnTapEvent callback of OnGestureListenerAdapter interface is invoked on background thread. Is it intended behaviour or bug in SDK?
Tried to find answer in docs but there is no info about this behaviour.
val state = MutableLiveData<MapViewState>()
override fun onTapEvent(point: PointF): Boolean {
viewModel.onMapClick()
return false
}
fun onMapClick() {
state.setValue(state.copy(selected = None))
}
Getting error when trying to set value to LiveData directly from onTapEvent.
java.lang.IllegalStateException: Cannot invoke setValue on a background thread
at androidx.lifecycle.LiveData.assertMainThread(LiveData.java:443)
at androidx.lifecycle.LiveData.setValue(LiveData.java:286)
at androidx.lifecycle.MutableLiveData.setValue(MutableLiveData.java:33)
at com.example.MapFragment.onTapEvent(MapFragment.kt:121)
at com.nokia.maps.MapGestureHandlerBase.a(MapGestureHandlerBase.java:253)
at com.nokia.maps.MapGestureHandlerBase.a(MapGestureHandlerBase.java:230)
at com.nokia.maps.NmaaGestureHandler.handleTap(NmaaGestureHandler.java:230)
at com.nokia.maps.NmaaGestureHandler.pollNative(Native Method)
at com.nokia.maps.NmaaGestureHandler.a(NmaaGestureHandler.java:26)
at com.nokia.maps.NmaaGestureHandler$a.d(NmaaGestureHandler.java:379)
at com.nokia.maps.NmaaGestureHandler$a.c(NmaaGestureHandler.java:371)
at com.nokia.maps.NmaaGestureHandler$a.a(NmaaGestureHandler.java:363)
at com.nokia.maps.NmaaGestureHandler$a$1.a(NmaaGestureHandler.java:390)
at com.nokia.maps.NmaaGestureHandler$b.run(NmaaGestureHandler.java:429)
Seems logic to have this callback invoked on main thread.
Quick answer is: to avoid ANR. SDK user can write heavy code and that will cause application not responding issue.
There are two ways to solve the issue:
1) Post your actions to UI thread like below:
new Handler(Looper.getMainLooper()).post(new Runnable() {
#Override
public void run() {
// customer code
}
});
2) Use asynchronous listeners, which are called on UI thread. You have to register your gesture listener using "false" value as third param:
m_mapGesture.addOnGestureListener(gestureListener, 0, false);
Hope this helps!
Related
Good day!
Wondering if using fireUserEventTriggered/userEventTriggered is netty way to collaborate with callback-oriented external services while processing message in channel handlers?
I mean, if there is some "alien" service with nonblocking(callback mechanic) methods, is this is right way to call ChannelHandlerContext#fireUserEventTriggered(passing some params from callback closure) and then handle it within overloaded ChannelInboundHandler#userEventTriggered for continue communication within original channel where it all started.
Example for illustration
#Override
public void channelRead(ChannelHandlerContext ctx, Object msg) {
externalServiceWithAsyncApi.doAndRegisterCallback(
//some call that will finish later and trigger callback handler
(callbackParam)->
ctx.fireUserEventTriggered(
new ExternalServiceCallbackEvent(callbackParam)
)
);
}
#Override
public void userEventTriggered(ChannelHandlerContext ctx, Object evt) throws Exception {
//seems its for us to handle
if (evt instanceof ExternalServiceCallbackEvent) {
//some processing and answer in the original?
ctx.channel()
.writeAndFlush(...)
.addListener(...);
// let other handlers process
} else {
super.userEventTriggered(ctx, evt);
}
}
Seems example with HeartbeatHandler in "Netty in Action" (in Listing 11.7) is relevant, but this part is a bit ahead from my current point of reading, so decided to ask for a help.
There is very similar question but something did not work for author and no answer Netty, writing to channel from non-Netty thread
UPD
The correct way seems to call NOT
ctx.fireUserEventTriggered(...)
but
ctx.channel().pipeline().fireUserEventTriggered(...)
It's definitely something you could used for that. That said you can also just do the write directly from your callback.
I'm facing this kind of problem: I'm creating Event Manager with ability to handle several concrete providers, and I'm struggling with dependency injection issue here.
I'm using:
Typescript#2.0.10, node#7.0.0, inversify#2.0.1, inversify-binding-decorators#2.0.0
Lets see that in code:
const socketIO: SocketIO.Server = io.listen(instance);
kernel.bind<SocketIO.Server>(TYPES.SocketIO).toConstantValue(socketIO);
const eventManager: IEventManager = kernel.get<IEventManager>(TYPES.IEventManager);
eventManager.init(kernel.getAll<IEventManagerProvider>(TYPES.IEventManagerProvider));
console.log(eventManager);
And console logs me that event manager is undefined, which crashes the whole app. But...
When I disable the kernel.getAll(...) from init, then I'm receiving just what I've expected:
const eventManager: IEventManager = kernel.get<IEventManager>(TYPES.IEventManager);
eventManager.init([]);
console.log(eventManager);
Gives me: MultipleProvidersEventManager { providers: {} }. The init method is very simple by itself and contains:
#provideSingleton(TYPES.IEventManager)
class MultipleProvidersEventManager {
...
public init(providers: IEventManagerProvider[]): void {
forEach(providers, this.registerProvider);
}
public registerProvider(provider: IEventManagerProvider): void {
if (this.providers[provider.type()]) {
throw new Error('Event Manager provider already registered');
}
console.log('Registered ' + provider.type() + ' event manager provider');
this.providers[provider.type()] = provider;
}
...
}
So my problem is that I have to wait with calling the init method until
all required objects are stored properly in InversifyJS container and can be returned. But I don't know how :(. Can someone explain me how should I solve this problem ?
Ok, I've solve it.
The problem was in totally different place that I was thinking on the beginning.
So... in MultipleProvidersEventManager class on init method, forEach was loosing the context of the caller. Adding bind soved the problem..
forEach(providers, this.registerProvider.bind(this));
... is the anwser.
I am showing activity indicator after clicking login button until redirecting the user to another page, to make them understand some progress is going on. But after clicking login button Activity Indicator is not shown immediately, it is shown after few seconds,
Why its so? To reduce that delay only I am putting activity indicator...
My Code:
async void loginButtonGesture_Tapped(object sender, EventArgs e)
{
Device.BeginInvokeOnMainThread(() =>
{
loadingPanel.IsRunning = true;
loadingPanel.IsVisible = true;
});
}
Does the method have to be async void? It seems like this particular scheduling anything on the main thread shouldn't need to be async. Try that to see if it changes anything. Also you could try to set breakpoints on the Device.BeginInvokeOnMainThread line, and the loadingPanel.IsRunning... line to see where the delay happens.
First of all, loginButtonGesture_Tapped() event handler is triggered by UI thread so you don't need to use Device.BeginInvokeOnMainThread(), it is already in UI thread. But since you used Device.BeginInvokeOnMainThread() here, the reason for the delay is because on Android, your code inside of BeginInvokeOnMainThread() is added to MainLooper's message queue,(your code is not executed immediately) and is executed when the UI thread is scheduled to handle its messages.
The detailed answer can be found in Xamarin document:
For iOS:
IOSPlatformServices.BeginInvokeOnMainThread() Method simply calls NSRunLoop.Main.BeginInvokeOnMainThread
public void BeginInvokeOnMainThread(Action action)
{
NSRunLoop.Main.BeginInvokeOnMainThread(action.Invoke);
}
https://developer.xamarin.com/api/member/Foundation.NSObject.BeginInvokeOnMainThread/p/ObjCRuntime.Selector/Foundation.NSObject/
You use this method from a thread to invoke the code in the specified object that is exposed with the specified selector in the UI thread. This is required for most operations that affect UIKit or AppKit as neither one of those APIs is thread safe.
The code is executed when the main thread goes back to its main loop for processing events.
For Android:
Many People think on Xamarin.Android BeginInvokeOnMainThread() method use Activity.runOnUiThread(), BUT this is NOT the case, and there is a difference between using runOnUiThread() and Handler.Post():
public final void runOnUiThread(Runnable action) {
if (Thread.currentThread() != mUiThread) {
mHandler.post(action);//<-- post message delays action until UI thread is scheduled to handle messages
} else {
action.run();//<--action is executed immediately if current running thread is UI thread.
}
}
The actual implementation of Xamarin.Android BeginInvokeOnMainThread() method can be found in AndroidPlatformServices.cs class
public void BeginInvokeOnMainThread(Action action)
{
if (s_handler == null || s_handler.Looper != Looper.MainLooper)
{
s_handler = new Handler(Looper.MainLooper);
}
s_handler.Post(action);
}
https://developer.android.com/reference/android/os/Handler.html#post(java.lang.Runnable)
As you can see, you action code is not executed immediately by Handler.Post(action). It is added to the Looper's message queue, and is handled when the UI thread's scheduled to handle its message.
We are evaluating Grid Gain 6.5.5 at the moment as a potential solution for distribution of compute jobs over a grid.
The problem we are facing at the moment is a lack of a suitable asynchronous notification mechanism that will notify the sender asynchronously upon job completion (or future completion).
The prototype architecture is relatively simple and the core issue is presented in the pseudo code below (the full code cannot be published due to an NDA). *** Important - the code represents only the "problem", the possible solution in question is described in the text at the bottom together with the question.
//will be used as an entry point to the grid for each client that will submit jobs to the grid
public class GridClient{
//client node for submission that will be reused
private static Grid gNode = GridGain.start("config xml file goes here");
//provides the functionality of submitting multiple jobs to the grid for calculation
public int sendJobs2Grid(GridJob[] jobs){
Collection<GridCallable<GridJobOutput>> calls = new ArrayList<>();
for (final GridJob job : jobs) {
calls.add(new GridCallable<GridJobOutput>() {
#Override public GridJobOutput call() throws Exception {
GridJobOutput result = job.process();
return result;
}
});
}
GridFuture<Collection<GridJobOutput>> fut = this.gNode.compute().call(calls);
fut.listenAsync(new GridInClosure<GridFuture<Collection<GridJobOutput>>>(){
#Override public void apply(GridFuture<Collection<GridJobOutput>> jobsOutputCollection) {
Collection<GridJobOutput> jobsOutput;
try {
jobsOutput = jobsOutputCollection.get();
for(GridJobOutput currResult: jobsOutput){
//do something with the current job output BUT CANNOT call jobFinished(GridJobOutput out) method
//of sendJobs2Grid class here
}
} catch (GridException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
});
return calls.size();
}
//This function should be invoked asynchronously when the GridFuture is
//will invoke some processing/aggregation of the result for each submitted job
public void jobFinished(GridJobOutput out) {}
}
}
//represents a job type that is to be submitted to the grid
public class GridJob{
public GridJobOutput process(){}
}
Description:
The idea is that a GridClient instance will be used to in order to submit a list/array of jobs to the grid, notify the sender how many jobs were submitted and when the jobs are finished (asynchronously) is will perform some processing of the results. For the results processing part the "GridClient.jobFinished(GridJobOutput out)" method should be invoked.
Now getting to question at hand, we are aware of the GridInClosure interface that can be used with "GridFuture.listenAsync(GridInClosure> lsnr)"
in order to register a future listener.
The problem (if my understanding is correct) is that it is a good and pretty straightforward solution in case the result of the future is to be "processed" by code that is within the scope of the given GridInClosure. In our case we need to use the "GridClient.jobFinished(GridJobOutput out)" which is out of the scope.
Due to the fact that GridInClosure has a single argument R and it has to be of the same type as of GridFuture result it seems impossible to use this approach in a straightforward manner.
If I got it right till now then in order to use "GridFuture.listenAsync(..)" aproach the following has to be done:
GridClient will have to implement an interface granting access to the "jobFinished(..)" method let's name it GridJobFinishedListener.
GridJob will have to be "wrapped" in new class in order to have an additional property of GridJobFinishedListener type.
GridJobOutput will have to be "wrapped" in new class in order to have an addtional property of GridJobFinishedListener type.
When the GridJob will be done in addition to the "standard" result GridJobOutput will contain the corresponding GridJobFinishedListener reference.
Given the above modifications now GridInClosure can be used now and in the apply(GridJobOutput) method it will be possible to call the GridClient.jobFinished(GridJobOutput out) method through the GridJobFinishedListener interface.
So if till now I got it all right it seems a bit clumsy work around so I hope I have missed something and there is a much better way to handle this relatively simple case of asynchronous call back.
Looking forward to any helpful feedback, thanks a lot in advance.
Your code looks correct and I don't see any problems in calling jobFinished method from the future listener closure. You declared it as an anonymous class which always has a reference to the external class (GridClient in your case), therefore you have access to all variables and methods of GridClient instance.
Here is basically what is happening....
Class A (Main thread) sends an MVVM message
This message is received, and in the course of processing, Class B is constructed and kicks off a background task.
This background sends an seperate MVVM message.
Class C has registered for this message and does an invoke on the dispatcher to attempt to update the UI.
At this point the main thread is still executing the original Send command and the threads are deadlocked (I can pause the debugger and see they are both waiting).
Other Notes
If I add a sleep in the background thread for one second (allowing the main thread's Send method to complete) it works fine.
This only happens if there is a nested MVVM message sent on another thread which invokes on the dispatcher.
Commenting out the dispatcher call...fine.
Not using an MVVM message to invoke the dispatcher...fine.
Can anyone explain what is going on?
I'll take a stab at this...
You can take a look at the MVVM-Light source code on its CodePlex site. I'm going to paste in the relevant method here (slightly annotated for the sake of this post):
private void SendToTargetOrType<TMessage>(TMessage message, Type messageTargetType, object token)
{
var messageType = typeof(TMessage);
if (_recipientsOfSubclassesAction != null)
{
// Clone to protect from people registering in a "receive message" method
// Correction Messaging BL0008.002
var listClone =
_recipientsOfSubclassesAction.Keys.Take(_recipientsOfSubclassesAction.Count()).ToList();
foreach (var type in listClone)
{
List<WeakActionAndToken> list = null;
if (messageType == type
|| messageType.IsSubclassOf(type)
|| type.IsAssignableFrom(messageType))
{
lock (_recipientsOfSubclassesAction)
{
list = _recipientsOfSubclassesAction[type].Take(_recipientsOfSubclassesAction[type].Count()).ToList();
}
}
// Class A probably sends a message here from the UI thread
SendToList(message, list, messageTargetType, token);
}
}
if (_recipientsStrictAction != null)
{
// Class B grabs this lock on the background thread.
// Class A continues processing on the UI thread and arrives here.
// An attempt is made to grab the lock on the UI thread but it is
// blocked by the background thread & Class B which in turn is waiting
// on the UI thread. And here you have yourself a deadlock
lock (_recipientsStrictAction)
{
if (_recipientsStrictAction.ContainsKey(messageType))
{
var list = _recipientsStrictAction[messageType]
.Take(_recipientsStrictAction[messageType].Count())
.ToList();
// Class B sends its message here.
// Class C receives the message and does an Invoke on the UI thread
SendToList(message, list, messageTargetType, token);
}
}
}
RequestCleanup();
}
Class A probably sends a message on the UI thread picked up by 'subclass recipients'.
Class B is a recipient that picks up this message and kicks off your background task.
Your background task then sends a message that has a 'strict action recipient'.
Class B grabs the '_recipientsStrictAction' lock on the background thread.
Class B sends the message to class C, which does an invoke on the UI thread.
This invoke blocks because the UI thread is still executing the first message.
UI thread execution continues on and then tries to grab the '_recipientsStrictAction' lock on the UI thread. Unfortunately, your background thread (which is waiting on the UI thread) already has the lock. You are now deadlocked :(
Might want to consider doing an InvokeAsync in Class C rather than an Invoke. I think you could probably avoid the issue that way.
Makes me wonder why MVVM light is sending the message 'inside' the lock. Seems like a not-so-cool sort of thing to do. After typing all this up, I went looking around the CodePlex site, looks like this is issue has been documented:
http://mvvmlight.codeplex.com/workitem/7581