Erel, this works:
and the reason I am there (codewise), is that when calling an ActivityForResult with Google Play Game Services when trying to use the autoMatch criteria, a waiting room is displayed, showing the status of different people joining/leaving etc... until the matchCriteria are met... but all of the Room Construction calls (peers joining/leaving etc...) are all being called (I see it in the Eclipse logcat) but the main GUI thread is the waiting room, so I need to use the raiseEventFromDifferentThread call. But, if you build a Room by inviting players specifically, and users respond to invitation requests, then they are run on the Main thread, so raiseEvent works great.
I can write the code such that when AutoMatch criteria meet parameters of knowing that the UI might be the foreground activity, I can use just one or the other call.... but this works so well in my testing I thought "why do that")
(I really am going to write the code for the automatch, but just wondered why I don't get any errors with the way it's written now?)
B4X:
/**
* Called when the client is connected to the connected set in a room
*/
@Override
public void onConnectedToRoom(Room room) {
debugLog("onConnectedToRoom and # participants is " + Integer.toString(room.getParticipants().size()));
RoomWrapper rw = new RoomWrapper(mBA, room);
mBA.raiseEvent(this, eventName + "_onconnectedtoroom", rw);
mBA.raiseEventFromDifferentThread(this, null, 0,eventName + "_onconnectedtoroom" , false, new Object[] {rw});
}
and the reason I am there (codewise), is that when calling an ActivityForResult with Google Play Game Services when trying to use the autoMatch criteria, a waiting room is displayed, showing the status of different people joining/leaving etc... until the matchCriteria are met... but all of the Room Construction calls (peers joining/leaving etc...) are all being called (I see it in the Eclipse logcat) but the main GUI thread is the waiting room, so I need to use the raiseEventFromDifferentThread call. But, if you build a Room by inviting players specifically, and users respond to invitation requests, then they are run on the Main thread, so raiseEvent works great.
I can write the code such that when AutoMatch criteria meet parameters of knowing that the UI might be the foreground activity, I can use just one or the other call.... but this works so well in my testing I thought "why do that")
(I really am going to write the code for the automatch, but just wondered why I don't get any errors with the way it's written now?)