On Xamarin Android i have set in the App.cs the MainPage property to be a NavigationPage pointing to my MainPage.xaml page, which is a ContentPage. This navigates fine.
From a Command which executes from a Button in my MainPage.xaml I await a call to Navigation.PageAsync to go to my LoginPage.xaml, also a ContentPage. This works fine.
If i choose not to Login and wish to go back to the MainPage.xaml page from some unknown reason at the point where i was close to shipping it has decided that now it takes two clicks on the Android hardware back button to make this happen. This was not the case earlier in the day, it seems as if something has gone astray with Xamarin compilation as the only change i made was add some extra colors to a ResourceDictionary. This was working fine for months.
By the way, I have checked the NavigationStack, it is correct MainPage, and LoginPage (not two LoginPage instances). I also note RemovePage does not work anymore either, the point there being that if I do Login then i Remove the LoginPage so you don't come back to it from the following page.
In trying to find a cause I overrode OnBackButton inside the Android project and sure enough, the first click does not call it, only the second does. I have no idea how to fix this, my project was nearly ready to ship, and all of a sudden this. I've tried deleting the obj and bin folders and recompiling, Debug and Release, still the same. This is the case now on both emulator and physical devices.
Might anyone have an idea where to even begin looking how to fix this or better yet have a solution?
So i finally figured it out, and it is not pretty. I was wrong about only adding colours, i had also moved from a page a Style that works on TargetType Entry into App.xaml. In theory this should NOT have made a jot of difference, it would be just be merged into all the pages ResourceDictionary as per any other resource placed at the App.xaml level. I have two pages that had the exact same Style for Entry so i consolidated them at the root.
But here is the kicker. The double back button press comes about from one setter property that is there and only when it is in the App.xaml. I had set CursorPosition to 0. This innocuous setter causes the backbutton not to fire, no exceptions are thrown, just that it has this effect. Hope this helps someone.
P.S I'd have moved to MAUI (indeed did a full port) but that has so many issues relating to Images and crashing and performance at this time it is not possible, so stuck with Xamarin for now, fying pan or fire.
Related
I have a main menu inside my unity game and for some reason when i build the game for android to run it on my phone the buttons does not work, but it's not disabled.
My scene objects:
My event system object:
Three things I can suggest:
First, make sure that on your button object, raycast target is deselected. At times, this is destabilizing the text of the button, hence making the button itself invalid.
Second, check to see if the EventSystem is working. From what I'm seeing on your screen, you might have disabled it or accidentally deleted its script while working on the scene objects. You can re-create it if necessary through GameObject>UI>EventSystem.
If these don't work, you can try the steps shown here:
https://answers.unity.com/questions/1115464/ispointerovergameobject-not-working-with-touch-inp.html
This is directly related to button objects not working with touch input devices. Hope this helps!
I have a project that I did not develop but am trying to fix bugs in. There's a button that I press and then a bug occurs. I want to find out where in the code this button is implemented but its hard to trace it since there are so many classes and layout files. Usually, if there's text associated with the button, then I find the string in my strings.xml file and work my way back. Unfortunately, this button doesn't have any text associated with it.
Hey just connect your actual android phone and run the app on it and also open logcat, when you will click that button logcat should hopefully display all the errors and you can go to the function.
Try this and comment me back if it works
This is a unconvential method, but I used it in the beginning aswell. In Android Studio press CTRL + H to open the Find in Path dialog. This will search the whole project.
For a Button you might want to search e.g. setOnClickListener, Button etc. and navigate it down by this approach. This method will also find dynamically created Views in case it's not in the layout.xml
Library used: appcompat-v7:22.2.1,design:22.2.1
Theme used:
Devices/Android versions reproduced on: Nexus 6
Issue: Return activity quickly redraws/appears then fades in with desired behaviour, only with "Don't keep activities alive".
I am wondering if this is a bug or expected behaviour. I have a very simple setup. Activity A contains a toolbar wrapped in an AppbarLayout and CoorindinatorLayout. The toolbar contains a Cardview and a TextView. Upon click of the TextView, Activity A launches Activity B. I am using shared elements and passing them through as Option's via ActivityCompat.StartActivity(bundle, options);
My shared elements work perfectly, even after device rotation. After reading about how I can PostPoneEnterTransition and combo it up with PreDrawListeners I am able to successfully achieve the desired transition even after rotation. My actual activity contains a Viewpager / TabLayout and 2+ fragments but for simplicity sake, I've stripped it back in the video as well as to see if something else was causing this issue.
While dealing with rotation and postponing of the enter transition back to Activity A, I decided to open developer options and check "Don't keep activities alive". The video depicts the app running with that option enabled. If you look closely, you can see upon return to Activity A, it is completely drawn and hidden very quickly and then the fade in occurs as well as the shared element transition.
I've also excluded the navigation bar and status bar in the animations so that I don't see those flicker (redraw redundantly).
My questions are:
Is this a bug, or am I missing a step in order to prevent this.
Why would the app/transitions behave differently with "Don't keep activities alive" vs a plain old device rotation (destroy/recreate).
I've noticed by playing around with some google apps, this behaviour does not occur, or at least that I could find. Is there a way to concretely check if the activity I am returning too is "completely destroyed" so I can cancel the animation? Or do something different?
I can include specifics and code samples if required but my setup is very simple, and reflects a bunch of boilerplate examples from the Android documentation / Stack-overflow.
Sorry I meant to respond to this earlier. What I ended up doing was recreating the example in a completely fresh project following code samples and tutorials as best I could. First making it work with a single image view, and then of course adding my custom layout which was a floating search bar. Everything worked as expected. I went back and reviewed my actual project source (which was littered with different attempts and commented out code while trying to debug this issue) and cleaned it up. I can't say for sure, but I believe it came down to two possible issues:
"Unless you do something unusual..." - Most likely I "was" doing something unusual by the time I created this issue do to my debugging efforts and lack of full comprehension of the shared elements transition framework and lifecycle.
I think what was happening was the shared element transition was failing do to views not being mapped properly. I was excluding the statusBarBackground inside a transition defined in XML. My statusBarBackground was set to transparent so that I had the nice overlay effect for an expanded drawer layout. I found out that while trying to add the statusbarbackground as a shared element via code, the view was actually null resulting in a crash (NPE). As well as I had set a background color (instead of transparent) to my drawer layout. I can't say for sure, but a combination of these mistakes lead to the strange behaviour.
To conclude, I would say that this issue should be closed and everything is working as intended. It would be nice to get a little more insight on handling a transparent status bar as a shared element.
Is this a bug, or am I missing a step in order to prevent this?
No. Everything is working as intended.
Why would the app/transitions behave differently with "Don't keep activities alive" vs a plain old device rotation (destroy/recreate)?
It doesn't. When everything is setup proper and your timing and mapping of shared elements is correct, "Don't keep activities alive" is a concrete way to test your transitions against configuration changes.
I've noticed by playing around with some google apps, this behaviour does not occur, or at least that I could find. Is there a way to concretely check if the activity I am returning too is "completely destroyed" so I can cancel the animation? Or do something different?
This is because the Google dev's did it right :)
For anyone struggling with shared elements, here is a bit of advice.
Start small. Use a single view first and confirm you are getting the correct behaviour in all circumstances, even after rotation and config changes, then you can add complexity.
Use SharedElementCallback to debug your transitions. You can check which views are mapped, which view failed etc.
I am using the Launcher 3 code as a base for building my own launcher application. I've managed to build everything correctly and import the project in Android Studio, however I seem to have some issues when switching into landscape mode on a Nexus 7 (first generation) device.
The problem is that at first the Google search and voice search icons do not appear but after pressing the home button they do. Also if you tap on the places where they should be, the search activity appears and when coming back to the launcher the buttons are there too. It seem that somehow they are not visible and I have looked over in the code but so far I could not find what the issue is.
Is there any one who encountered this problem and can point me in the right direction to solving it?
Thanks,
Mihai
I have managed to solve the problem.
It would seem that the drawableStateChanged() method from HolographicImageView is called when switching to landscape mode before the view is laid out. This would cause the mStatesUpdated flag set in the method generatePressedFocusedStates(ImageView v) in HolographicViewHelper to be set to true and the code updating the search bar ui would not be executed anymore in the subsequent calls of the generatePressedFocusedStates(ImageView v), after the view is laid out.
A simple check for isLaidOut() before calling generatePressedFocusedStates(ImageView v) in the drawableStateChanged() method would do the trick.
I just started my work as an Android developer. My first assignment is to fix several bugs of an App call DailyFinance.
One bug is UI related, if you click a button on a certain page, a dialog will pop up, but the dialog is not displayed properly. My question is how can I locate the code (xml layout file as well as activities) related to the dialog quickly in the codebase which I am not familiar with?
Couple approaches come in mind:
Search for any text that displayed on the target dialog.
Search button text and locate the xml layout file that that contains the button which launch the target dialog
Once find the xml layout file, determine the button 'id' as xxxxx, then you can further search for source contains references to 'R.id.xxxxx'
Set breakpoints on methods in files that implement the dialog. So maybe search for dialog and then put breakpoints inside the dialog. See it it gets hit when your dialog gets pulled up. Or just see where the layouts are set in files that have the word dialog in them. look for R.layout.someLayoutName.
One other suggestion is for some difficult layouts where its tough to see whats going on you can use the HierachyViewer to see the runtime view layouts: http://developer.android.com/tools/help/hierarchy-viewer.html Its worth running on your app to see the structure of the layouts at runtime which is often hard to see these relationships in the layout files before they have been inflated.
BTW, I was a student of CS and the biggest mistake I ever made was not to learn the debugger inside and out. Its without a doubt the most powerful ally you have to learn as well as fix bugs. If you think about it, code really is only an abstraction until you see it running inside the debugger.