I know this is a broad question but it goes as follows. I have a Fragment that lists TODO tasks. Now I want to add a swipe view - a second page - that lists the already completed tasks. So basically what I want to achieve looks like this:
Just imagine that there are two static pages "TODO" and "DONE"
This means that I need to share the data between the two screens. Also note that these two pages need to have a completely different layout.
I've done research and the brand new ViewPager2 seems to be the way to go.
However, the official documentation doesn't really talk about my use case. They seem to have pages that use the same layout and don't share data between themselves:
https://developer.android.com/guide/navigation/navigation-swipe-view-2
Since ViewPager2 is completely new I decided to post a Stackoverflow question right away due to the simple fact that I am positive that my use case is the most popular one and thus, there will be more people with the same question.
Summa summarum: How does one implement two Fragments - with independent layouts - that share data and are swipe views themselves by utilizing the new ViewPager2 library.
Related
I have been reading up on the Android API and it seems like Fragments are meant to sort of modularize an Activity. So if an Activity has a ListView and DetailView then it should be split into two separate fragments and have the Activity act as the master controller.
In my previous project that I worked on we were using Fragments kind of like children of the Activity.
For example: Let's say there is a AutomobileActivity that is designed to save automobile input data to the cloud.
We have fragments like:
SedanFragment
TruckFragment
SportsUtilityFragment
These fragments take up the entire view of the Activity and only one is displayed at a time. While these fragments use methods in the Activity to call common webservices like saving automobile information, getting car information. They also do different things like the Truck may have an additional entry to set the "Bed Size" and SportsUtilityFragment may have "Tow Limit" etc.
So in a way we are leveraging a lot of re-use and modularizing, but it's not exactly what the Android API is detailing. Is this a bad way to use Fragments?
This is a very objective question and this will have a lot of different answers. In my opinion what you are doing is correct. The reason behind this is that they have a set of common webservices. If we go by the mvc approach they can all have the same controller(for calling webservices), a model class(Superclass- vehicle) with separate models which inherit from this vehicle model class. By doing this you can have an additional entry parameter which will be present in these models. Your view, the fragments can easily call the instance of these models. If you modularize in this manner, you will be making life very easy for yourselves.
I have few gwt mvp design related questions:
Can we use event bus to switch views from one presenter to other via controller using custom event?
If above is true, can the custom event (say changeViewEvent) contain name of next view, on the basis of which controller can take a decision, which presenter to show?
Is it a good design to make views reusable(as a widget) in an application, though i don't agree with this, but will be happy if someone has any thing to mention in favor of this.
PS: all my views make use of custom widgets and there is no gwt specific widgets(buttons, checkbox etc...) in views.
You can do anything you want, but you have to consider the consequences. For example, if you switch views without creating a history event, a user may be thrown out of your app when a user hits a back button expecting to see the previous view.
I very much like the Activities and Places design pattern. It takes care of all of the issues (history handling, bookmarks, tokens, etc.) You can also extend it to add animation effects when switching views on mobile devices - mgwt does that.
I have few gwt mvp design related questions :
Can we use event bus to switch views from one prsenter to other via controller using custom event ?
This is a bad practice, unless you have real good reasons to do that. Since you're changing the view without having an impact on the url, you won't know what is a the state of a view at a choosen moment, you cannot get back to a previous view in an easy way, and finally, people will have difficulties reading the code, since you're out of the "standard".
The only reference for you should be the url, you cannot assume data is loaded neither the applicatio is in a given state: each and any view may be the start of the navigation story for your users, so if you get information from any other source than the Place, you're probably doing wrong, especially if your source is an event. the only special case here is you don't want users to enter your app in a certain view state, so you 'impose' that another url is called before, and restrict the access to the view through an event starting from a given application state
If above is true, can the custom event (say changeViewEvent) contain name of next view, on the basis of which controller can
take a decission, which prsenter to show ?
as said before, you're reinventing the wheel. It's far better to adapt to the existing mechanism that is well thought and covers the majority of cases. You can put a json formatter to tokenize your url while developing so it's not a nightmare to put variables in. And when you're done, create a nicer regular url format
Is it a good design to make views reusable(as a widget) in an application, though i don't agree with this, but will be happy if
someone has any thing to mention in favor of this.
depends on what you call a View. if it's the activitie's view then youm might need that in very few cases, it's better to inherit a basic view and fork its children for each activity (even if the view does nothing, time will show it will evolve differently): this is better since the base view contains what is common without the specifics of each child activity.
Finally if you mean a composition of widgets when you say, a view, then you should definitely reuse them, it will make you obliged to improove your widgets and compositions to be in a constant improvement, this will heop you for the rest of the project, and maybe for other projects
I'm fairly new to android and am slowly adjusting to how android works.
I am in the process of creating an android application which uses a .net web service to pull back data from a sql database. I have two methods which return a json response with a list of custom objects.
I am parsing these into arrays of matching objects on the android client. I am looking to implement a multiple tier grid displaying information from these two arrays. The items in the first array will have child items contained within the second array.(one to many relationship)
I am guessing I will need to create two custom array adapters? (which will allow me to have custom layouts for each tier).
I have had a look around and struggled to find a comprehensive example of using the expandable list view. What data source will this expect? (some kind of hash table I would imagine?)
Does my approach above sound reasonable?
Any advice would be appreciated.
Thanks,
ExpandableListView expects a class which implements the interface ExpandableListAdapter as the data source. There are several implementations included in the Android SDK. The SimpleExpandableListAdapter would probably get you up and running the fastest, it uses Lists and Maps for it's data. It won't give you the ability to use different layouts for each group within the list but it will let you have a different layout for groups and children.
If SimpleExpandableListAdapter isn't enough then you are going to want to write your own adapter. I'd suggest extending BaseExpandableAdapter (this Adapter implements ExpandableListAdapter and takes care of some of the housekeeping aspects for you, it leaves the rest of the implementation to you). There is a simple example that shows how to do this in the API Demos ExpandableList1.java example.
Your implementation will likely be more complex than the example, but it should give you some idea how to do it.
Is there a listviewObject.saveViewStates(view) function I can use? I have listviews, I have other listviews with custom adapters, but neither of these save states of the view. There is a lot of dynamically generated content in these listviews, so of course, when it that row goes outside of the view, the data is reset.
I understand the concept behind a viewholder, yet I am having great difficulty retroactively fitting my listviews with them. (nullexceptions, illegalstateexceptions)
Since the common way of holding the view is to pass the view, wouldn't it make sense that the listview had a built in function that simply accepted the view as a variable? I understand that the listview was created with limited memory in mind, it just seems negligent that there wouldn't be a way to save the states built in, in contrast to the webview - which is also built with limited memory in mind - the user can force enable/disable caching, do their own memory management etc.
Insight appreciated
The whole idea of the list is that it is dynamic and can be potentially long - so have lots of rows which are invisible. Therefore the aim of the adapter approach is to only keep as many views as visible on screen and fill them with data by running getView() - which should reuse views if no longer needed.
So when you take that in the account, it becomes pretty straightforward, that it's the data model behind (stored in adapter) that should get saved/reloaded and the list views should be rebuild when list is reloaded and filled with the data from the model.
This is more in-line with the list concept.
The Wicket examples page for TabbedPanel (link) uses separate, distinct classes for each tab (TabPanel1, TabPanel2 and TabPanel3). Is there a reason to not just use three instances of the same class? If yes, what is it? I'm still fairly new to Wicket, but those classes look identical to me.
EDIT: I ran a simple example, using three objects all of class tabPanel. Each one was set to use a different label, and they did display properly.
EDIT AGAIN: After doing more experimentation and reading the later-posted answers, I realized my first example was too simple. Using one class, the tab title can be different but the logic would still be the same. That wouldn't work unless, as someone mentioned, it became a "Swiss Army Knife" class, which is poor design. And that still wouldn't address the markup file.
Wicket is designed to encourage the development of reusable Components. Consider the three different Classes as different components you'll want to use in different pages of your application with entirely different behaviour and content. Say Tab1 for contact information, Tab2 for a map and Tab3 for pictures. You really wouldn't want to create a Swiss-Army-Knife-Panel to manage all of those different purposes. So different panel-classes are used in the example.
Admittedly the example doesn't use the best values - but it might be a better idea if you start with the general principles of wicket (take special care in learning how working with models works) rather than with these special components from the wicket-extension package.
If you'd use three instances of the same class, you'd end up with the same content on each tab... Not very usefull is it?
As you have shown it is possible, and would work well where the display of the panel is controlled by the model.
Lets say you had a component that displayed and address, with an embedded google maps image of the location..
You could create 3 instances of the same "AddressWithMapPanel" passing in a different model to each, with each table being the "Home", "Work", "Other" addresses. There you can then use the tab logic to switch between viewing the different addresses, keeping the same UI changes in a central place but getting different content.