Very basic loader question.
My WIMMOne watch uses Android 2.1 (version 7).
There are no orientation changes, etc. with a watch. The small screen does not have room for any layout changes. So no need to deal with any kind of layout change.
The app I am working on now simply reads from a cursor, and displays an open ended scrolling list. My first app had a fragment and that was a pain. So I decided since I don't need fragments I will do away with the complexities of fragments.
I START WITH:
public class PhoneListActivity extends Activity
implements LoaderManager.LoaderCallbacks <Cursor>;
THEN:
protected void onCreate(Bundle savedInstanceState)
{ super.onCreate(savedInstanceState);
setContentView(R.layout.phone_list_activity);
FINALLY:
getLoaderManager().initLoader(0, null, this);
BUT:
Because it is 2.1 I need to use:
getSupportLoaderManager().initLoader(0, null, this);
BUT: -
That generates compile errors, so I need to use:
public class PhoneListActivity extends FragmentActivity . . . (not just Activity)
BUT: -
It immediately crashes on load in the ContentProvider.
Postings in various sites refer to "Activities and ActivityFragments".
SO: QUESTION 1: Can my main class use "extends FragmentActivity" without setting up a separate fragment (ie: leave it just as an Activity).
QUESTION 2: If not, does that mean that to use a loader I must set up a separate fragment and deal with the issues of fragments?
Many thanks,
Clark
The answer is YES.
I redid part of the program and it now works without using fragments. It has the open ended scrolling being loaded from a cursor and basically the same structure above
I think something in handling my cursor was causing it to crash.
Clark
Related
I have an app with four main pages, switched through a tab bar (no "back" button).
One page has a lot of content (ScrollView) and takes quite a few seconds until it's rendered. I handle that by showing a "loading" overlay while the work is done. But for that specific page I'd like to keep the view alive, so that when the user switches to another page and comes back later, the page is ready without loading everything again.
I'm not sure how to do that in MvvmCross, though.
I did read the documentation and from what I understood the View Presenter would be the right way to do it, since the docs say:
"Another kind of presentation changes your app can request through
hints includes clearing / modifying the BackStack, changing a root
while maintaining the existent views, … possibilities are really
endless. Once again your app is king here!"
I guess I would need to create a custom MvxPresentationHint for that, but I don't quite get it :(
How or rather where would I access and store/load the View?
I'm generally still quite unfamiliar with MvvmCross (how it works under the hood) and especially customization of Mvx classes, even though I've been using it for a while.
Any explanation and preferably code examples beyond what's written in the documentation would be extremely appreciated!
It isn't meaningful to attempt to "store" a view in MVVM. The XF view is a representation of what will be created with native (e.g. "Android" or "iOS") widgets. Creating and measuring/laying out those native widgets is what is slow. MVVM View Presenter won't speed up that logic.
Instead of "store", you need "keep alive":
For a ContentPage called MyPage, when you create it, store it in a static variable. Then re-use that variable. If you never need more than one of these, you can store it in the class itself.
Modify the "code behind", MyPage.xaml.cs:
public partial class MyPage : ContentPage
{
// Singleton Pattern.
private static MyPage _it;
public static MyPage It {
get {
if (_it == null)
_it = new MyPage();
return _it;
}
}
// "private", because calling this directly defeats the purpose. Instead, use `MyPage.It`.
private MyPage()
{
InitializeComponent();
}
}
To create it, whereever you would put:
new MyPage()
instead put this:
MyPage.It
For instance, you might do PushAsync(MyPage.It);
This will always return the SAME INSTANCE of MyPage. So once it has been created, it keeps its state.
IMPORTANT: Note that the constructor is only called ONCE. Any code that needs to be done each time the page appears, put in override .. OnAppearing() method.
LIMITATION: Views "expect" to be part of the visual hierarchy when they are manipulated. If you attempt to alter the page or its view model while it is not on the screen, you may encounter problems. Those are beyond the scope of this answer - create a new StackOverflow question with the details of any problem you encounter.
I'm trying to override the NavigationView behavior:
public partial class CustomizableNavigationView : NavigationView
{
public CustomizableNavigationView()
{
// This gets called
}
protected override void OnApplyTemplate()
{
// This doesn't
}
}
It works on UWP, but not on Android. On Android, it doesn't call OnApplyTemplate and the screen remains blank, there's not content. Questions:
Why doesn't OnApplyTemplate get called on Android? I see that here: https://platform.uno/docs/articles/implemented/windows-ui-xaml-frameworkelement.html it says OnApplyTemplate() is on all platforms
There's no error or anything displayed in the Output panne in VS while running with debugger. Should there be any in this case? Do I need to enable something to log errors?
I noticed that if I don't use partial it gaves me error saying partial is required. This is required only on Android, why is that? A more in-depth explanation would help a lot to understand how things work.
Once I figure out why OnApplyTemplate is not called, I want to do this:
base.OnApplyTemplate();
var settingsItem = (NavigationViewItem)GetTemplateChild("SettingsNavPaneItem");
settingsItem.Content = "Custom text";
My hunch is this won't work on Android. Am I correct? :)
Jerome's answer explains why OnApplyTemplate() was not getting called, to address your other questions:
You can configure logging filters for Uno, this is normally defined in App.xaml.cs. Warnings should be logged by default.
The partial is required because Uno does some code-gen behind the scenes to create plumbing methods used by the Xamarin runtime. Specifically because the control is ultimately inheriting from ViewGroup on Android, it's a native object, and requires special constructors that are used only by Xamarin's interop layer. There's some documentation in progress on this.
Try it and see. :) GetTemplateChild() is supported, and setting ContentControl.Content in this way is supported, so I would expect it to work.
At current version (1.45 and below), the application of styles is behaving differently from UWP. We're keeping track of this in this issue.
The gist of the issue is that Uno resolves the style using the current type and not DefaultStyleKey, and cannot find an implicit style for CustomizableNavigationView.
A workaround for this is to either create a named style from the default NavigationView style, or create an implicit style that uses CustomizableNavigationView as the TargetType instead of NavigationView.
I'm using a leanback BrowseFragment to implement a simple android tv app. I have two PageRows which are backed by custom fragments. When I switch between the two in the browse navigation area, the content side of the screen goes blank briefly before the new fragment's views appear. How can I fade from one view to the other without a delay in between?
I see some references to "entrance transition" in the docs which I think is what I need, but I can't find any examples of what to do in those callbacks.
https://developer.android.com/reference/android/support/v17/leanback/app/BrowseFragment.MainFragmentAdapter.html#setEntranceTransitionState(boolean)
I tried to implement setEntranceTransitionState on my PageRow Fragment's MainFragmentAdapter, but it is never invoked:
class GuideFragment: Fragment(), BrowseFragment.MainFragmentAdapterProvider {
val fragmentAdapter = object: BrowseFragment.MainFragmentAdapter<GuideFragment>(this) {
override fun setEntranceTransitionState(state: Boolean) {
Log.v("TEST", "setEntrance($state)")
fragment.setEntranceTransitionState(state)
}
}
override fun getMainFragmentAdapter() = fragmentAdapter
}
There is no way to do this when using BrowseSupportFragment.
If you look at the implementation of swapToMainFragment(), you'll see that while scrolling the content is set to an empty fragment. When SCROLL_STATE_IDLE is reached, a regular fragment transaction is used to replace the child fragment with the new content.
leanback has a lot of limitations, It is better to fork the official code and create your own repo and modify it; we did the same in our app.
I have been reading about fragments lately, and almost everyone says that we should use it. I still can't understand the concept very well. I have read this, but I still have some questions.
First: A fragment must be related ( if its the right word) to an activity, let say MainActivity, the fragment has its own layout, the MainActivity has its own two. So what will be displayed on the screen? the fragment layout or the MainActivity or Both??
Second: If I want to convert an existing code to use fragments, what are the main changes?
Third: If I want to have more than one fragment, do I have to add a class that extends Fragment for each fragment I want to create??
Forth: onCreateView of the class that extends Fragment returns a view, is it correct to create a view inside it and return it for the main activity to add it to its layout??
Any help is appreciated.
Here are some tips about fragments what i understand so far , it might help you to understand Fragments :
1: About your first Question, yes both(Activity and Fragment) has their own layouts but Activity layout is act as base layout for fragments but this also depends on the layout you are working. If i state a simple example of HelloWorld app(which automatically created when you first create your Project in eclipse in updated adt), then you saw there Activity act as base and fragment layout show over it.
2: If you want to change the existing code to use fragments,firstly it depends upon the complexity of your code, and after that you have to change various things like if you are supporting api level 10 and below than you have to use Extra Libraries.there are lots of changes to be made but these all depends on your requirements.
3: Yes you have to create a Class which extends Fragment or any other Sub Class of Fragment. This Class is just like your Activity Class in which you have a xml layout to work with.
4: Yes you have to define a view inside OnCreateView() to return it to the activity to add to its layout or to show the UI.
Fragments are just like Activities , the pain comes when you working with Nested Fragments. and the life cycle of fragments are little different than Activity .
Note :please tell me if you have other queries or in case of any doubt about above written statements.
First:
In the layout of MainActivity you can embed multiple fragments layouts. You can even reuse these fragment layouts in any other activity. Ah, Good feature!
Second:
If I want to convert an existing code to use fragments, what are the
main changes?
To use fragments in your existing code you just need to,
The fragments will be added to the activity using the <fragment> element in the layout or can be added dynamically.
To check if the fragment is already part of your layout you can use the FragmentManager class -
DetailFragment fragment = (DetailFragment) getFragmentManager().
findFragmentById(R.id.detail_frag);
if (fragment==null || ! fragment.isInLayout()) {
// start new Activity
}
else {
fragment.update(...);
}
If a fragment is defined in an XML layout file, the android:name attribute points to the corresponding class.
To dynamically add fragments to an existing layout you typically define a container in the XML layout file in which you add a Fragment.
For this you can use, for example, a FrameLayout element.
FragmentTransaction ft = getFragmentManager().beginTransaction();
ft.replace(R.id.your_placehodler, new YourFragment());
ft.commit();
A new Fragment will replace an existing Fragment that was previously added to the container.
If you want to add the transaction to the backstack of Android, you use the addToBackStack() method.
This will add the action to the history stack of the activity, i.e., this will allow to revert the Fragment changes via the back button.
Third:
If I want to have more than one fragment, do I have to add a class
that extends Fragment for each fragment I want to create??
To define a new fragment you either extend the android.app.Fragment class or one of its subclasses,
for example, ListFragment, DialogFragment, PreferenceFragment or WebViewFragment.
Forth:
onCreateView of the class that extends Fragment returns a view, is it
correct to create a view inside it and return it for the main activity
to add it to its layout??
No need to return it to the main activity to add it to its layout. Just use FragmentTransaction's replace inside Main Activity followed by commit to be done.
I'm trying to understand how to preserve fragment view state when fragments are used within navigation tabs. In my efforts, I've come across two problems that I cannot find any proper solutions to.
I have two tabs, Tab1 and Tab2. Tab1's layout is defined by FragmentA and Tab2's layout is defined by FragmentB.
I've followed the approach given here (edit: documentation has changed since this question was asked).
The first problem: Even though my views have IDs, their states are not fully restored when a fragment is re-attached (after a tab switch rotation). In particular: an EditText with an ID does indeed save its entered text, but it does not save its enabled status. Also, buttons do not save if they are enabled or disabled even though they have IDs. I've found two possible workarounds for this problem:
Use hide()/show() instead of attach()/detach() when switching tabs.
in onPause(), save the current fragment view state in a View instance variable of the fragment via getView(). In onCreateView(Bundle savedInstanceState) check if this field is non-null and if that is the case return the value of this field. This solution seems hacky, and I've been told that it might also introduce a memory leak in my app.
The second problem: Consider the following user interaction:
User starts on Tab1 and does some changes that put the view state of Tab1 in a different state than its default state (and we want the fragment to save this view state through tabswitches and device tilts).
User then goes to Tab2. User then tilts her/his device (still at Tab2).
User then swaps to Tab1 (at the new screen orientation).
Now, the problem is: when the user initially swaps from Tab1 to Tab2, the fragment is detached and thereby its view discarded (even though the fragment instance still lives). When the user then tilts the device, the activity - and thereby both FragmentA and FragmentB associated with it - are destroyed. Since FragmentA at this point does no longer have a view (remember: it was detached), we cannot save the state of its view elements (e.g., what buttons are enabled/disabled) during the call to FragmentA.onSaveInstanceState(Bundle savedInstanceState). How do you recover fragment view state in a situation like this? Is the only viable solution to save every single view element's different status flags as SharedPreferences? This seems way too complicated for such an "everyday job".
Problem 1:
Android does not save your view enabled state by default. It seems only things which are directly influenced by user actions (without additional code) are saved. For a normal View, no information is saved, and for a TextView, of which EditText is a subclass, the entered text is saved (if freezesText is set).
If you want to anything else to be saved, you will have to do it yourself. Here is an question with some answers that show how to implement custom view state saving. You can stick with attach/detach if you follow that approach.
Problem 2:
You are right in that Fragment.onSaveInstanceState(Bundle) can be called after your view has already been destroyed. However, this is not where you should be saving your view state. Android will call View.onSaveInstanceState() right before it destroys your views when detaching a fragment. It saves this state and gives it back to you when you attach the fragment again. This is exactly what happens when you flip between tabs normally with no rotations. Fragment.onSaveInstanceState(Bundle) is not called when detaching. Even if you rotate the device, the view state saved as a result of the detach will persist. If you implement View.onSaveInstanceState() as directed above, your view state will be saved and restored properly, even in the Tab1-Tab2-rotate-Tab1 scenario.
Side note:
The example code in the docs seems to have some problems when you try to rotate. The lifetime of the TabListener is the same as that of the Activity - a new one is created every time you rotate. This means it also loses its internal reference to the fragment, every time you rotate. Added fragments are recreated automatically and so there is no need for the TabListener to try to create a new instance and add it, after rotation. Instead, of the internal reference, it should just try to find the fragment with the appropriate tag in the fragment manager. After rotation it will still exist.
The other problem is with that the selected tab is not saved, but this is noted at the bottom of the example. You could save this in Activity.onSaveInstanceState(Bundle).
private ViewPager viewPager;
viewPager = (ViewPager) findViewById(R.id.pager);
mAdapter = new TabsPagerAdapter(getSupportFragmentManager());
viewPager.setAdapter(mAdapter);
viewPager.setOnPageChangeListener(new ViewPager.OnPageChangeListener() {
#Override
public void onPageSelected(int position) {
// on changing the page
// make respected tab selected
actionBar.setSelectedNavigationItem(position);
}
#Override
public void onPageScrolled(int arg0, float arg1, int arg2) {
}
#Override
public void onPageScrollStateChanged(int arg0) {
}
});
}
#Override
public void onTabReselected(Tab tab, FragmentTransaction ft) {
}
#Override
public void onTabSelected(Tab tab, FragmentTransaction ft) {
// on tab selected
// show respected fragment view
viewPager.setCurrentItem(tab.getPosition());
}
#Override
public void onTabUnselected(Tab tab, FragmentTransaction ft) {
}