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.
Related
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.
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.
I'm still trying to understand what is the correct way of implementing MVC. This example #oracle says that view has access to the controller. And another tutorial #leepoint is indicating that the view has access to model. Are these different variations of the the MVC? In my case I was following the tutorial at Oracle site with some modifications(I have added a function in AbstractController getModelProperty, which will allow me to retrieve the value of the fields of the current registered models, but it also could me sense to pass the model as parameter(like indicated at leepoint tutorial) to simplify and probably optimise the data access for the view.
Thanks in advance.
Views are bound to models. Since views render models, they have to have intimate knowledge of the model, there's simply no way around it. Some views are generic, and these have "generic" models. Here, you may try and conform your actual model to the generic one so that the "generic" view can use your data. But even with these generic models, the views are still tightly bound to them.
Models manage data, the state. While a view has intimate knowledge of the model, the model is view agnostic. It simply doesn't care. This way you can have several views for the same model.
However, a model must inform others of changes to the model. Typically in java you use PropertyChangeListener's. This mechanism lets the model just shout out changes wholesale, and anyone interested can listen for these changes and act on them, for example your view.
A simple example is that you game object can take damage from a bullet, and it's reduced to below 50% health. The view can see that health has been reduced and change the image of the model (say adding smoke, or whatever).
The Controller typically is bound tightly to the view and the model. It knows the capabilities of the view (like it's size, and other areas of interest), and it knows how to change the model. Such as when mouse is clicked, the controller converts the mouse point in to a coordinate relative to the view, and from that determines what object was clicked. Once it determines the object that was clicked, it can set the model for the object to, say, "selected".
The model then broadcasts out that it's "selected" property has changed. The view sees this, finds the bounding rect for the model that changed, and invalidates that rectangle on its display.
Finally, Java comes around and tells the view "Hey, Rect 10,10,100,100 needs to be painted". And the view find the models in that rect, paints the new view of the object with a "selected" border, or whatever.
Thats how the whole cycle works.
It's both. MVC has a triangular relationship with each other, with the Controller on the top. The newer way to go is using MVP, where the Presenter sits between the model and the view.
It's better if you can keep as much of the model knowledge out of the view and only feed it information specific to it's viewing task. It does make your life easier in the long run.
... says that view has access to the controller.
yes, the view holds a reference to the controller for user gestures. (in a gui, the view and controller sometimes end up lumped together).
... that the view has access to model.
yes, the view usually holds a reference to the model(s) (it might have more than one).
... Are these different variations of the the MVC?
there are a bunch of variations.
... but it also could me sense to pass the model as parameter(like indicated at leepoint tutorial) ...
usually the model has views that are observers and the view updates itself when it receives an update message as opposed to being called directly by the controller. the former decouples the view more from the controller.
The Swing libraries are a very good implementation of the MVC pattern. Just study the API for a bit and it will all fall into place for you.
The Wikipedia Article on MVC nails the relationships pretty well: View has the Model, Controller has both the View and the Model, Model knows nothing about both View and Controller.
In some cases it may be advantageous to simplify the pattern by combining View and Controller.
I am looking to create an app with plugin functionality. What I want is to allow a separate plugin "app" to provide me with the view, and take care of the updating of the view that I will use in my list adapter. Essentially, I want the separate app to take care of the bindView and newView methods of my adapter.
I am looking at RemoteViews, but I am not sure if that is exactly what I need, if it would work, or maybe it's what I have to use, since it would be cross-process.
Thanks for your help.
RemoteViews is the only thing vaguely practical, because you are communicating between processes.
Performance will be awful. Getting a ListView to behave quickly when everything is in one process takes a bit of work. Going across process boundaries for every row will either be very slow and memory intensive. This is why, for example, ContentProvider returns its full result set on a query(), to avoid dozens or hundreds of extra RPC calls.
I strongly suggest you reconsider your proposed architecture.