Hi Xamarin/MvvmCross devs,
I am having a problem with the MvxCachingFragmentCompatActivity, or I think it's a problem. I don't know if it's expected behaviour or not.
In my app I use fragments inside a container view. I'm having a problem with the FragmentBackStack when the activity is being restored after destruction. If I go three levels in from my initial fragment, go into the background and come back to the foreground only the last two views are restored. Note this is with "Don't keep activities" switched on in developer options.
Is there any specific setup/indication I have to give to MvvmCross to indicate too them that I want them to handle my viewmodel save/restore functionality. I don't see any in the samples I went through.
I use to use a manual approach with older versions of MvvmCross where I stored a reference to all my viewmodels in the ContainerViewModel and then just read that up when it's restored. But this doesn't work particularly well when you can have multiple of the same view on the backstack.
I have nothing special in the app, it's base usage of MvxFragment for all the views. I do have a custom presenter, but I only override ShowFragment so I can show popup views instead of replacing. None of the views not being restored uses this functionality, so it's not interfering with anything.
Any help would be grately appreciated.
Dane
Update 1
Keep in mind that views in this case are MvxFragments.
while researching this I found some weird backstack behaviour associated with the MvxCachingFragmentActivity. While doing the restore functionality I got fragment tag not found in cache errors, so I added this
FragmentCacheConfiguration.RegisterFragmentToCache<View, ViewModel>(typeof(ViewModel).FullName);
When I add this for my view that's displayed second (after the first view), the first view is never added too the backstack. Causing a weird back navigation bug where back would close on the second view even if AddToBackstack is set too true for the first view we navigated from.
When I remove that line the navigation works completely fine. I have no idea why that is.
There were two reasons the MvxCachingFragment was not restoring the fragment backstack properly and had the weird navigation issues after coming back from the backgroun.
I did not set RetainInstance = true; for the fragments. Since I had many I created a base fragment using MvxFragment and set Retain Instance true in the constructor.
I did not have MvvmCross-Json-Plugin installed. Which is used for deserializing the stored viewmodel information from the Bundle.
Related
I have built a Xamarin Android app that presents the user with a series of data entry forms, like a wizard. The wizard has a bottom navigation bar with previous and next buttons, and a menu button that when pressed displays a list of all forms in the wizard and allows the user to jump to any given form.
The desired functionality is to preserve the linear navigation, so that when the user jumps to the middle of the wizard, they can still use the previous and next buttons to page through the various forms in order. They should also be able to use the hardware back button to view the previous form in the wizard.
I suspect my implementation is not MvvmCross friendly because I'm seeing some bugs with it, specifically my viewmodels are not destroyed when I clear the fragment backstack (wizard hosted in an Activity, each form is a Fragment).
How should I implement this?
Have you tried using this overload of PopBackStackImmediate? This one will pop all of the fragments until the one you specify in the string (if inclusive flag is passed, then that fragment is also popped) so you spare iterating all over the fragment backstack.
Activity.SupportFragmentManager.PopBackStackImmediate("myViewTag", (int)PopBackStackFlags.Inclusive);
where "myViewTag" is the UniqueImmutableCacheTag of your View
There has to be something unconventional about my implementation, but with a deadline and little help from the community, what do you do to fix your hack, but to hack it more?
My solution was twofold:
1) instead of using FragmentManager.PopBackstackImmediate(), I implemented a while loop with the condition: activity.SupportFragmentManager.BackStackEntryCount > 0, calling Close(fragment.ViewModel) in the body. This should have fixed the bug, but it didn't.
2) The ViewModels I was requesting to Close were still not being disposed, so I had to resolve the current IMvxMultipleViewModelCache and call GetAndClear on it with the expected parameters. This forced my ViewModels to be disposed so they will be recreated on the next viewing of its Fragment.
This feels like a hack. Closing a ViewModel should dispose of it whether it's associated with a Fragment or Activity, but for some reason it wasn't. That's the key to this bug, but like I said, deadline, hack on hack.
So, I'm still new on Android Fragments, but if I got it correctly, when you remove a Fragment and stack it to the back stack with addBackStack (according to Android Developer's Fragment lifecycle) you get this portion of view destroyed and when it pops up to the screen again it has to reload all it's components.
I'm specially concerned with that because one of my fragments contains a map, which is a lot of data to reload (specially if using 3G).
In that case, is it a better practice to implement hide and show to all my fragments when manipulating them?
I just see a little problem there because I'd have to create my own stack to know the order they were called and have to be shown again.
Well, it's now a huge problem, but I wanted to hear from someone if it is worth putting effort on it to implement this approach instead of the existing back stack.
Thanks in advance!
Using the ´attach´ and ´detach´ operations are another way around to your problem. The fragment instances will still exist, but deactivated and not visible, and you can recover them using the FragmentManager
If one of your fragments contain google map, it's better to use show/hide operations with the fragment views in order to avoid google map black flickering bug. Check my answer: https://stackoverflow.com/a/25206078/2999943
I just want to ask why my app crashes with the following conditions.
I am working with fragments with only one activity. In my fragment, say FragmentA, I create views dynamically (inflating them). They work fine. But when I press home button, and go to the app again, I expect that FragmentA will be displayed but unfortunately, it throws NullPointer.
There is no errors in my android phone[GingerBread] but on my Tab, this error happens. Any help will be higly appreciated. Thanks.
You are not providing enough information to reliably answer this question, but the difference your're seeing is probably related to different behaviour of the garbage collector on the two different devices. As they are running on two different devices they will also behave differently.
The null-pointer you are seeing I would guess stems from wrongful use of member variables in your fragment.
When you go to the home screen and back your fragment will (or more accurately CAN) be recreated. Read: destroyed and re-instantiated using the argument-less constructor.
So make sure your fragment(s) are properly saving any needed state in onSaveInstanceState and restore this information in OnCreate/OnCreateView or whatever you're using.
Requirement
I have an application with 2 activities, say A and B, with navigations like A->B and B->A (on back press). My requirement is
I want a view/layout floating on screen, irrespective of which
activity is currently visible. I inflate this view on app
start(onCreate of activity A), it remains static on screen during the
transition from A->B and when B is onscreen.
So naturally this view should be inflated only once (when app starts,
onCreate of A).
What I found out
I did some searching, and from what I could find, there are 2 methods to reuse layout in android
using <include>
It just seems like a tool to write xml code of commonly used UI elements. It gets inflated every time it is used in a parent layout.
using ViewStub
I did some research on using ViewStub and It also seems a way to reuse code segment in many layouts. It also need to be inflated every time we use it in a layout except it gets inflated only when we make them visible at run time.
Another hint of my requirement
For people familiar with iPhone development you can add view's to UIWindow, which stays there irrespective of which UIViewController is currently active. I want exact behavior in my application.
My original setup
I am targeting android 2.1 and above. It seems Fragment is available from API level 11 (android 3.0) and above. One option is to use android compatibility library that enables usage of Fragment in older versions. I am currently researching on that now. But I also would like to know if there is any other methods available to fulfill my requirement, rather than change my entire project and use fragments.
I have around 30 odd activities in my application and I want this layout floating over all of them. I just made out a test case with 2 activities to make the question simple and easy.
Solution 1: FrameLayout
I think what you want to use is the FrameLayout. FrameLayout is designed to block out an area on the screen to display a single item. Child views are drawn in a stack, with the most recently added child on top.
http://developer.android.com/reference/android/widget/FrameLayout.html
Then read here about the back stack that you could use in your activity to flip back and forth between the activities using the back button:
http://developer.android.com/guide/topics/fundamentals/tasks-and-back-stack.html
Solution 2: Fragment Transactions
Rather than code two separate Activities, code a single Activity with two Fragments. Here is a blurb from the Fragments documentation:
"A fragment must always be embedded in an activity and the fragment's lifecycle is directly affected by the host activity's lifecycle. For example, when the activity is paused, so are all fragments in it, and when the activity is destroyed, so are all fragments. However, while an activity is running (it is in the resumed lifecycle state), you can manipulate each fragment independently, such as add or remove them. When you perform such a fragment transaction, you can also add it to a back stack that's managed by the activity—each back stack entry in the activity is a record of the fragment transaction that occurred. The back stack allows the user to reverse a fragment transaction (navigate backwards), by pressing the Back button."
I have a special flow of fragments in my app, so I need to be able to switch to any fragment, while keeping fragments in memory whenever possible (so if it's tight on memory, it's ok that the fragment will be released).
So far, I've succeeded doing a replace of the current fragment, but the thing is that the previous fragment is always being destroyed, so if I go back to it (using the action bar, for example), it's re-created and that takes some time.
The reason I use fragments instead of activities is the nice usage of the action bar, the ability to put multiple fragments inside the same container, the non-flexible activities-intents usage, etc...
The reason why I don't use the "Back" stack is that I wish to go to any fragment from any fragment, since the flow can change.
Here's a snippet of my code:
Fragment fragment=... ; //get the fragment from cache or create if not available yet...
FragmentTransaction ft = getSupportFragmentManager().beginTransaction();
ft.replace(R.id.mainActivity_fragmentContainer, fragment).commit();
I have also tried to use ViewPager, but since I don't want to have the sliding effect (which allows you to slide to other fragments) and since one of the fragments already include a viewPager, it's an obstacle. Disabling the sliding effect on the main viewPager somehow disables it on the other one.
BTW, I'm using the android support library for the fragments and not the native API.
my question is:
how can i achieve full control of which fragment to go to , while maximizing speed and avoiding too much memory being used for fragments ?
EDIT:
for now , i use the next workaround :
for the onDestroyView , i take the parent of the created view and remove the created view from there .
for the onCreateView , if i already have the created view from before , i return it .
however , i think it's a very risky thing to do , since i'm not sure of how fragments managing work , so it might cause weird problems . plus ,i'm not sure what will happen if android decides that it has low memory - will it destroy unused fragments (which is good) or will it cause out-of-memory exceptions (which is bad) .
I agree with your comment regarding "it's very risky". Since the consequences of your approach are not really clear, I would not recommend using this.
To better understand your issue and to give you some indications:
what do you consider to be slow? I keep switching fragments "like crazy" too, and it works OK on a tablet, however on some low-end phones it takes much longer - but is still acceptable
How much work do your fragments need to be created? ie what kind of underlying data needs to be preapared each time? (again, I have several list fragments with more than 1k entries, they get prepared each time, and it's quite fast)
how do you exaclty replace fragments? In particular do you call getFragmentManager().executePendingTransactions();
One way to accomplish your goal is to use FragmentTransaction.show and FragmentTransaction.hide. You can use Fragment.isAdded to determine whether to show or to call FragmentTranscation.add the first time. The downside is that you won't get Pause/Resume events when fragments are shown and hidden; you will need to override onHiddenChanged. You will also have to manage your own stack if you want to support back navigation.