I get that. We currently have two list entry types, no? Unless I’m missing something, my proposal would keep that (update the list entry types, rather than creating new ones).
We currently only have one layout where we can enable/disable the cover and the drag handle. The one you are proposing moves around all UI elements, so it would need a completely different layout.
Hello,
I’ve updated the proposal following the feedback:
What was updated:
- Continue listening now has more episodes, to not be just a replication of the miniplayer while still providing access to the queue (if the queue is empty, something should be shown in the two empty spots nudging the user to use the queue - will work on that).
- Add extra criterium to Rediscover screen (not recently played)
- Section with most-listened podcasts follows statistics setting
- Minor text changes (e.g. ‘episodes’ > ‘inbox’)
- I changed ‘Look at the latest’ to ‘Review the new’, but actually not a fan of it, because you can’t take action there. So I would change it back.
- Added screen/fragment for changing the layout (allowing the user to change the order and hide sections)
To be done/discussed:
- Not sure if the local search screen would need/benefit from a mock-up? I mean: we have local search already.
- Discussion about the section titles: @ByteHamster said the ‘Continue’ section would be too long in German, @Matth78 suggested to rename ‘Check your classics’ to ‘Most played podcasts’. I wanted to keep a consistent pattern between all titles, but that may be difficult. Maybe a mix may be easiest & nicest after all:
- verb + what
Continue listening, Look at the latest, Check your classics, Rediscover podcasts, Get surprised - verb
Continue, [something for latest], [something for classics], Rediscover, Surprise - description
In your queue, New episodes, Most-listened, Forgotten podcasts, Random suggestions - a mix
(Spotify does this: ‘Jump back in’, ‘Made for [name]’, ‘Recently played’, ‘Good morning’)
Continue listening/Up next, New episodes, Most played, Rediscover, Surprise yourself
- verb + what
Ok, I thought there were two already. Discussion for another thread, then 
I kept them in the mock-up because I like this new layout and was too lazy to ‘correct’ it (there’s a lot of details in these so it’s relatively much work).
1 Like
My suggestions for section titles :
- look at the lastest : “Recent episodes” or “What’s new”
- check your classics : either “Your top podcasts” or “Most played podcasts”. Classics sounds too serious,
- rediscover podcasts, maybe : “Podcasts to catch up”
In your mockup there is one caveats for me : if it is a home screen I really feel it would be better to have all in one screen without need to scroll to see all sections. 
I don’t see how to fit it all and keeping all sections. I would say my less favorite one is “get surprised”. Even without it, would all fit?
Another point about vertical space, there will be less than in your mockup if there is mini player, and potentially a bottom buttons toolbar (to potentially replace drawer menu)
I like it in English. Not sure (yet) how it’d translate into Dutch. So I guess you’re in favour of the ‘mixed’ approach (from my list above).
I see why you’d want that and you’re right about the limited vertical space, but I don’t think it would be possible to make everything fit. And even then: my boyfriend’s phone (and with him, many others) has a rather small screen. He’d still have to scroll, even if we’d make it fit on your screen (well, depending on the size of your screen, but you get my point haha).
I don’t think we should compromise usability/elements on the page in order to make it all fit. E.g. Spotify’s home screen is scrollable, too, so it’s not uncommon.
If indeed the user could reorder & disable the sections (which would be cool but not sure if feasible), I would hope this already would make it as best for you as possible (you could hide for example the section with random episodes).
I first thought to always keep ‘search’, but maybe it should be possible to turn that on/off, too (allowing you to give more space).
Hi all,
I can get started on the implementation.
You currently already have 4 open PRs. I would suggest to get those finished and merged first before you start another one.
1 Like
Sure, i’ve updated several of them. I believe one of them can already be merged.#5097
And episode multi select is ready to be reviewed. Hopefully you have time later this week.
#5097 is not done. It always shows “network error”, even if it could also have other causes.
Sorry, I meant #5036 Hide keyboard when not searching by peakvalleytech · Pull Request #5036 · AntennaPod/AntennaPod · GitHub
That one currently has the fix commented out 
Please have a look at the comments there.
Ok. Will deal with that soon.
Started here [WIP] Home by ueen · Pull Request #5167 · AntennaPod/AntennaPod · GitHub
Please check if it’s going in the right direction (very early stage).
@ByteHamster code wise, do you think that’s a sensible approach (LinearLayout in ScrollView and then filled up with the section Views (RelativeLayout) with RecyclerViews that display the covers (scrollable horizontally).
For the EpisodesFragment on the home screen, I was thinking it could be optional (hidden by default) and is only displayed if the sections cover less than 50% of the homescreen height while I think there should be a requirement of at least one section that’s selected in the HomeScreenSettings 
(For now it includes my unified Episodes screen and the new Inbox to test if it can be integrated in the Home screen, I could separate them later if this is going forward)
I build the basic infrastructure and further views could subclass HomeSection and can be easily added in the HomeFragment, I might need some help with specific behavior (DB access) and implementing EventBus to update the recyclerview items in the Home screen sections as I’m not that familiar yet with the inner workings of AP, so I would be glad if someone more experienced could take over at some point
Sorry, this I don’t understand. What does this mean? Are you doing something different from what is in the mockups?
This was a suggestion to include my paused episodes usecase Episodes screen proposal - #51 by ByteHamster take look there for the discussion and take a look at the apk in the PR above to see what I’m working on
Sorry for the late reply.
I hope that it does not get too hard to separate them again. I would suggest to focus each PR on a single feature at a time.
I will have a look at the code in the next few days. Generally, a ScrollView could lead to inefficiency when there are many items because it keeps all of them in memory instead of recycling views that are out of view. Not sure if that would be a problem for us.
Uhm, yeah, the EventBus things in general could need a rework. Currently, most fragments catch like 5 different events and do the exactly same thing for all of them - which makes me wonder if we even need so many events. Not sure yet how to efficiently rework them, though.
I wonder if there would be a clean way to reuse code between the fragments and their home screen counterparts. Probably not easy to do it cleanly.
To be honest, I was mostly thinking of making the episodes a “normal” home screen section (but with a configurable number of episodes shown). I have not looked at the code yet but it looks like they are some kind of special case now.
Ok, will have a look. But in general I’m hoping you’re basing your work off of the mock-ups (which I guess you could also simply say if you do or not, but ok, I’ll have a look). Of course I’m making them because I like doing it. But if then they’re ignored I might better spend my time on different things within AntennaPod or do this kind of stuff for different projects all-together. (Aside from respecting earlier discussions and not wasting time on development before there’s consensus.)
Should be easily possible, as I created a separate HomeFragment.
Won’t be an issue as we only have a few (I think up to 5) sections that are always at least partially on the screen, so not much recycling anyway…
Yea, I think LiveData would be nice, don’t know how it could be done with the manual underlying DB though…
Currently only the episodes screen is an FragmentContainer and indeed kind of separate, I thought of just adding FragmentContainers to the scrollable LinearLayout but after some SO searching that doesn’t seem to be a good idea…
But I think that’s actually kind of good, I could imagine that you could select what fragment you want in the bottom half (none, more sections (default) or the inbox or episodes or the queue) this would only be displayed if two or less sections are selected (minimum one) so only the bottom half fragment will be scrollable, not the Home Screen, default will of course be as the mockup above.
Well I’m basing it on the mockups, I thought that goes without saying, just take a look at the apk (of course it’s not finished yet)