I have this code:
private async void Pin_MarkerClicked(object sender, PinClickedEventArgs e)
{
try
{
var popup = new PinPopUp(Convert.ToInt64(((Pin)sender).ClassId));
App.Current.MainPage.ShowPopup(popup);
}
catch(Exception ex)
{
Crashes.TrackError(ex);
}
}
which loads a popup when you click on a pin. On Android when you dismiss the popup you can click immediately on the same pin and the event will fire again, no issues.
On iOS the pins seems to have a 'selected/active' state that gets engaged after pin click (the pin appears larger on the screen) and after the popup is dismissed, the only way to select the pin again is to click on another pin or on the map to get the pin in the 'unselected' state, and then the user can re-select the pin.
Is there a way to reset the pin to make it selectable again? I see nothing applicable in the PIN properties or methods.
So in the Pin_InfoWindowClicked event you set e.HideInfoWindow = true, this keeps the pin in a state that's ready to be clicked again on iOS. I don't think that's a great name for that property as it doesn't actually hide your info window (thankfully) on iOS. It does hide it on Android so I had to put in a check to not add this line for Android.
Currently, the only way to close the notification is by pressing the stop button. But I wonder how can I wrap up the notification widget with a swipeable "thing". Can you tell me any package that would work on this or code that I have to wrap up a thing from the audio_service package?
The audio_service package publisher is - ryanheise.com
As a useful tip, the easiest way to search the entire documentation of audio_service to find an answer to some question is to navigate into the audio_service.dart file (which contains the whole plugin), and then search for the word "swipe". You will find this option on AudioServiceConfig:
/// Whether the Android service should switch to a lower priority state when
/// playback is paused allowing the user to swipe away the notification. Note
/// that while in this lower priority state, the operating system will also be
/// able to kill your service at any time to reclaim resources.
final bool androidStopForegroundOnPause;
And then inside the AudioHandler:
/// Handle the notification being swiped away (Android).
Future<void> onNotificationDeleted();
(You may find this easier to search than reading the online HTML documentation.)
What the above means is that you need to pass androidStopForegroundOnPause: true as a parameter to AudioServiceConfig and then if you want to handle any special behaviour other than the default (stop the service) when the user swipes away the notification, you can optionally override onNotificationDeleted in your own audio handler. There is no equivalent for iOS.
Note that it is not possible to swipe away the Android notification while audio is playing, but the option mentioned above will allow you to swipe away the notification from the paused state.
I'm working on an app that will have a lock screen, but I'm having some issues getting it to behave correctly. Right now I'm using the didChangeAppLifecycleState to navigate to the lock screen when the user suspends/resumes the app. I'm also using the WillPopScope to intercept and deny the back button. The problem with this approach is that pressing the back button and having nothing happen doesn't feel super intuitive. Ideally, I'd like the back button to take the user out of the app and back to their OS home screen when they're on the lock screen. I also want to do this in a way that the user's route history is maintained for when they successfully unlock the app.
Is there any way to accomplish what I'm trying to do, or should I just accept that the back button won't do anything on the lock screen?
You can create an identifier in your LockScreen state and check for the identifier in onWillPop and if the user is pressing the back button from the lock screen, exit the app.
String identifier = "lockscreen";
bool onWillPop() {
if (identifier == "lockscreen") {
SystemNavigator.pop();
SystemChannels.platform.invokeMethod('SystemNavigator.pop'); //preferred.*
return true;
}
}
SystemNavigator.pop(): On iOS, calls to this method are ignored because Apple's human interface guidelines state that applications should not exit themselves.
I'm starting a new activity to display a leaderboard in my Android App.
When the leaderboard activity is displayed, and the user presses the home key and then resumes the app (so the leaderboard activity comes up again), and then navigates back to the main activity by pressing the back key, the back key and volume keys stop working).
I've attempted to override onBackPressed in my activity class. I can confirm that when this problem occurs, onBackPressed is not called (When back / volume is working, pressing back does trigger onBackPressed).
Normally I get a message in LogCat when I press the back key 'Unimplemented WebView method onKeyDown called from android.webkit.WebView,onKeyDown(WebView.java.2178)' - Again I can confirm that this message doesn't come up when the back key isn't working
Armed with the above information, I can only assume that it's something to do with the View not having focus or something along those lines. I would point out that touch input on the screen itself does work. It just seems to be the back and volume keys/buttons that have no effect.
It's an openGL ES 2.0 app so in my onPause() I'm calling view.onPause(); and in onResume, I'm calling view.onResume();
I really have no idea what's going on and I've been on this for 3 days straight so if anyone can point me in the right direction, that would be great.
If the user comes out of the leaderboard and back into the main app before they press the home key, then everything is OK, it's just if the home key is pressed while the leaderboard activity is displayed as described above.
So when I'm at the point where the back / volume keys aren't working, if I click my scores button and fire up the leaderboard activity again, they work. On returning to my activity, they stop working again.
Not sure if this is relevant at all but the following shows how I'm starting my leaderboard activity:
if (scoresButtonPresses){
displayLeaderBoard();
}
void displayLeaderBoard(){
//Display the leaderboard if already signed in
if (checkSignedIn()){
startActivityForResult(Games.Leaderboards.getLeaderboardIntent(getApiClient(), leaderboardID), 1);
}
//if not already connected, then set flag and connect to play services before displaying leaderbaord
else{
signInAction=SHOW_LEADERBOARD;
getGameHelper().beginUserInitiatedSignIn();
}
}
#Override
public void onSignInSucceeded() {
//If the flag is set, then display the leaderboard
if (signInAction==DISPLAY_LEADERBOARD){
startActivityForResult(Games.Leaderboards.getLeaderboardIntent(getApiClient(), leaderboardID), 1);
}
//Otherwise, reset the flag and take no action
else {signInAction=NO_ACTION;}
}
This is driving me crazy so any help or even a nudge in the right direction would be very much appreciated!!
Edit
After much testing I have learned a couple of things:
If I remove the view.onPause() && view.onResume() the problem seems to go away. So this appears to be something to do with the way key events are captured by the view. Pausing and resuming seems to mess something up.
I have also tried removing the view.onPause() and view.onResume() as above, but instead, putting in View.setVisibility(View.GONE); and then making it visible again in public void onWindowFocusChanged(boolean hasFocus). Again, I get the same problem. Interestingly, when I open the leaderboard, as expected the view's staus is 'gone' then hitting the home key and running the app again, it's set back to 'visible' - I don't understand this behaviour but I'll ask another question for that.
Lastly, and this I find really odd. If I put my app back to as I had it, then after hitting the home key and relaunching the app via Eclipse (and I can do this multiple times) the problem doesn't seem to occur. So in that respect, it appears to be something to do with touching the screen.
Edit
It appears as though this isn't limited to my app. I've tested this on a couple of other apps from the Play store and get the same result.
One app clearly uses a single activity model like mine and the back and volume stop working throughout the app.
The other may use a different activity for it menu and game. When I test on this app, the back/volume breaks but if you start a game (therefore a second activity), the back key starts working again, even when you return to the first activity (recreated this activity?!)
So maybe I can get around this by ensuring the activity is recreated? I thought i was already but maybe I'm not getting something. Maybe it's something to do with the stack.........
I have no solution to your problem but some additional insights since I'm facing the same bug/problem with the leaderboards and the back button (and it's driving me crazy).
I'm using a single activity with fragments from which I login to Google Play, open Leaderboards and Achievements in the exact way you are doing it (startActivityForResult). Always when I come back from any Google Play Service activity my back button is broken. Sometimes it's even enough if I try to login to Google Play for it to break, meaning the login popup sometimes breaks the back button (but not always).
Some more insights which might help to solve the problem:
I'm not using OpenGL, so it's not related to this - I'm just using a single activity and fragments
It's also breaking for me when I just use the back button for going back from any Google Play Activity (I don't even need to go via the home key, just normal back is enough).
When the back button is broken the Activity is not receiving any Key Events (OnKeyDown, OnKeyUp, dispatchKeyEvent) are all not working, although using the activity and touching it fully works. My guess is that some view is catching the events...
Edit:
I also tried checking activity.getCurrentFocus() and activity.hasWindowFocus() as well as the parent and context classes of activity.getCurrentFocus() to see if there is any difference between when it's working and when it's not - and there isn't any difference...
Edit:
It seems that a simple call to View.requestFocus() is fixing the problem. For my single activity (using fragments implementation) I have now added:
#Override
public void onResume(){
super.onResume();
Fragment fragment = getFragmentManager().findFragmentById(R.id.fragmentContainer);
fragment.getView().requestFocus();
}
and this seems to be fixing the problem. Sill have to do long term checking if it's always fixed. In your OpenGL implementation I guess you will have to get the main view of the activity in some other way since you are not using fragments.
I know it's pretty old question, but for clarification: accepted answer is correct, but incomplete. Focus requesting should be done in onResume, onActivityResult, onSignInSucceeded and onSignInFailed. In first two you have! to call super. Some code:
private void requestFocusAfterGooglePlay(){
if(gimmeFocus==null)
return;
View currFocus=getCurrentFocus();
gimmeFocus.setFocusableInTouchMode(true);
gimmeFocus.setFocusable(true);
gimmeFocus.requestFocus();
gimmeFocus.setFocusableInTouchMode(false);
gimmeFocus.setFocusable(false);
if(currFocus!=null)
currFocus.requestFocus();
}
#Override
public void onSignInFailed() {
requestFocusAfterGooglePlay();
}
#Override
public void onSignInSucceeded() {
requestFocusAfterGooglePlay();
}
#Override
public void onActivityResult(int requestCode, int resultCode, Intent data) {
requestFocusAfterGooglePlay();
super.onActivityResult(requestCode, resultCode, data);
}
#Override
public void onResume(){
super.onResume();
requestFocusAfterGooglePlay();
}
in my case gimmeFocus is a dummy View created as below:
<View
android:id="#+id/gimme_focus"
android:layout_width="0px"
android:layout_height="0px"
android:focusable="false"
android:focusableInTouchMode="false"/>
I have dynamic layout so I can't never be sure that any view exists in my layout, so I've created this dummy View, it might be also added programmatically. You might choose your fixed View for gaining focus, but rembember that changing focus might change view's look (drawable state).
I've been writing a GWT app that does various simple things with images like pan, zoom, brighten, etc. when you click and drag the mouse. Everything is working really well in all the browsers, except Safari. Well, Chrome 3 was also a problem but my app now works fine in Chrome 4.
The problem is capturing the middle mouse down events. I've added mouse handlers to a widget class like this:
public class InteractiveThingy extends Composite implements
HasMouseDownHandlers, HasMouseMoveHandlers, HasMouseUpHandlers,
HasMouseWheelHandlers
{
#Override
public HandlerRegistration addMouseDownHandler(MouseDownHandler handler) {
return addDomHandler(handler, MouseDownEvent.getType());
}
...
}
and I can subscribe to the mouse events elsewhere and handle them. I can see which button was pressed and apply the appropriate operation.
However, in Safari and Chrome 3, the handlers are never called when I press the middle mouse button. Instead, the multi-way scroll icon pops up. The middle mouse down event comes through on IE, FireFox and Chrome 4 just fine.
Is there some extra event handling (like event preview) needed to stop Safari from handling the middle mouse before my code gets its chance? Or perhaps I need to wait until Safari fixes the issue like Google did with Chrome.