I have a recyclerview and I have at least 3 types of cards with different properties. Logic for switching cards layout is a non issue, but I am wondering what is the best way for me to grab the data.
I guess I can add different webservice data to a list or I can add them to an array where one column is key for type of ws.
I just need some pointers about how other people would do it. My recyclerview today has 3 cards layouts and the view resides inside a fragment. I do the WS calls in the main activity.
I at first wanted to use classes but some cards will use many properties and some few. Like a card for watch widget dosent need data. Current weather needs 3 properties and weather forecast maybe 15. I am thinking maybe I should pass an array that references type of card and then grab the data (as a key)? If I use classes I would have to make very generic names and not all cards would use all of them (not that this is hard to do, but Im thinking it looks silly).
In theory I guess looking at google now shows the different types of cards with different properties from different sources. How would you guys arrange the dataset for such usage?
Maybe you could use a parent class and extend from that the classes for every different type of card. Check the viewType in your ViewHolder and cast the item to the one that represents.
Related
I want to create 3 level RecyclerView like tree view in kotlin. Is there any tutorial and suggestions please let me know.
I already tried so many times with ExpandableListView and 3 RecyclerView, but didn't find any proper solution.
By a multi-level RecyclerView, do you mean a RecyclerView with paths to different lists that branch depending upon which item has been selected? If that's the case, I would honestly recommend using a single adapter to cycle through multiple lists depending upon user input.
If you have a root list containing two items, each of which opens up its own list with its own unique set of data, you can easily implement code that notifies the adapter of which item in the root list was selected. From there, the adapter can update and switch the view accordingly. This can be applied to series of lists ad nauseam if you so choose, though I can't say I would recommend this kind of method for incredibly complex webs of lists that interact with each other.
Like Ircover said in their comment, I don't think a tree is necessary in this situation either, if only because (1) as stated, it isn't really best practice to do so for the kind of application you're making, and (2) it may unnecessarily over-complicate whatever you're trying to achieve with these branching paths in the first place. If you're willing/able to provide more information about what you're trying to do here, that may help others help you more precisely than I can :)
Full disclosure here: the blog post linked above is not a direct match that will solve your problem - it pertains specifically to displaying different types of data sets (from data classes and what have you,) but employs code that shows how different sets of data can be switched between in a single RecyclerView. Even if it isn't a god-sent solution or is only halfway helpful in solving your problem, I think it can provide some useful information to you.
Maybe a slightly dated question but looking into the same concept and I located this page https://blog.usejournal.com/multi-level-expandable-recycler-view-e75cf1f4ac4b .
They have made a single adapter class to take care of all the navigation and so far seems to be the least complicated example of an expandable RecyclerView, though not in kotlin.
I've solved this previously with nested layouts in a scrollview.
But its pretty bad performance-wise and a pain in the ass to add anything new/update the functionality.
A quick mockup:
Basically there's a few tabs, all of them have different category of settings, since this is just an app to configure a Windows/macOS application.
I'm getting a JSON string from my server, it's pretty big, roughly 3k lines, and deserialize it to a big object. Not sure yet if I want to have local SQLite database or just keep editing the object in memory, serialize it, and post it back to the server when I'm finished editing.
How the hell would one approach this? The view type depends on the data type, but sometimes I'll use a spinner to limit the range/items one can chose.
I don't think there's a depedency for marking the fields in the model, so the recyclerview would know what view to use?
In an older app, I used straight SqlLite, built list adapters, had and XML file for the activity and another one for each item.... is there a new "magic" way to do this with Room? Room I have up and running, it can create the tables and stick data in, fine. But what is(are) the proper way(s) to show the data? Is it LiveData or nothing?
For this app, we're talking about displaying small (under 100) items in a scrolling view. Each one is only showing two items of text, you'll tap and edit one of the fields, save it, and done.
A recipe list of the actual files/classes I'll need to create would be super. I've seen plenty of code snippets but there's very little clarity on where those pieces live, and the XML layout files which seem like they must exist never get mentioned.
I am new in the corporate world & from design perspective please correct me if I am doing something wrong here
I am fetching images from Flickr API.
GOAL: Show these images in two different type of view, grid view and listview. Which can be switch through the slide.
So I am using a View pager with two fragments and both of these fragments has separate listeners. So when the response came from Flickr both of these listeners are notified.
In my opinion, this saves two times calling of REST API, but I am looking for even more efficient design or flow through which
Using single listener
Rest API should be called once
Result should be store (Just in ArrayList) and share to both of views
May not choosing two separate fragments
Avoid creating Adapter object two times
Image should be stored in cache
Any tweak or suggestions will be helpful a lot, please comment if you don't understand any part or whole question.
For above problem, the tweaking you are thinking is almost right. Other than below:
What I believe you must create two different adapters to have more control over different views. For example, you might want to show with scale type crop center for an image in list view but scale type center inside for an image in grid view. There might be the different type of thing you may want to perform. So, it's a good practice to make two different adapters, to make the code more manageable.
Again the same goes for the fragment, see if actions in both the fragments are same or can be done with single variable passing. Then only go with a single fragment.
Rest of the things are perfect.
i got the following "problem".
I want to have an activity thats shows me the standings of some teams at a specific gameday.
therefor i would add a spinner and a TableLayout. At the first Start the activity should show the standings of the actual gameday but then you can choose any other gaymeday and the standing should get updated.
Whats the best way to create this activity?
assemble the whole TableLayout with all TableRows and TextViews, give them ids and update those views via id during runtime. Problem: huge unflexible hardcoded layout.xml
assemble the layout during runtime, add ids, update via ids
assemble the layout during runtime. on update remove old views and create new ones
assemble the layout during runtime. on update restart the activity
just whant to know which one is the best. or is there any other way to achieve that
thx Cheetah
If I were you, I'd actually use a GridView with an Adapter. This will abstract away all the handling of layout changes. You just have to worry about mapping your data to appropriate views. This example maps ImageViews to a GridView, but there's no reason you couldn't map to TextViews containing your data in a GridView. Also, because you're using an adapter, you can take advantage of all the Loader classes and they're asynchronous loading capabilities.
In addition, using the approach will allow you program to easily adapt as your dataset changes. You may want to add more data to the table in the future and this approach will allow you to easily do that without having to constantly change your xml layouts.
Does the number of views change? If no. Best way is to use the already existent views and update their values. Try to avoid recreating/reinflating views since that's an expensive task.