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)
I think the PR is pretty far already, a few TODOs remain, but i think its already quite useable - check it out!
Try the debug apk
everything else should be according to mockups, only this small improvements:
- extended section rows to scroll horizontally and show a few more items
- the Continue section displays paused episodes from the queue first (and last played first), but the order of the queue, if an episodes is started, is respected.
- the setting features checkboxes to hide the sections and a reset option
- added add podcast icon to the toolbar
- added navigation to episodes screen to the “get suprised” section
- added shuffle button to “get suprised” section
?? Search is currently in the toolbar, should it be always in the toolbar or should I add a separate view like on the Discovery page?
I was thinking the user is used to search from the toolbar to search local and to not be confused with the new podcasts search online (Discovery) it might be sensible to leave the search in the toolbar on the home screen as well…what do you think?
?? Also should the “get surpised” be limited to episodes 2y or newer, bc sometimes i get some from over 10y ago? 
SwipeActions work pretty great now and are available in Inbox, Episodes, PodcastFeeds and can be customized for each screen via a toolbar dialog. Also on the first swipe the dialog opens with a default suggestion so nothing unexpected happens. Should there be an settings option to completly disable swipe actions? Or wait until somebody actually has a “usecase” not to use SwipeActions? 
https://photos.app.goo.gl/4749ELRBq5bVMqSc9
Here’s a quick demo with three possible workflows
(Default, inbox/queue, continue/episodes)
I think this opens up really cool customizability on one screen 
UPDATE: fixed a few issues and added swipe actions dialog
1 Like
Looks really nice 
@everybody, are we sure about sections titles ? After viewing video :
- review the news : sounds weird to me, should just be “new episodes”
- get surprise : same, at minimum shouldn’t it be “be surprised” ? But It would probably better to just label it “Random unread” so it’s easier to understand what is listed ?
In fact I looked back at comments and I agree with myself! Quoting me :
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”
I actually think the current titles are quite nice and understandable
Did a few more bug fixes i think thats pretty much it*, please let me know if you find anything not working as expexted and UI/UX wise what do you think, maybe icons or colors needs to be refined (surley SwipeActions), so if you have any suggestions, feel free to offer them here
*a bit of code cleanup needs to be done to fix the CI errors and i think a few unit tests broke as well
After close to one year after the last reply, we can revisit the home screen 
I just had a bit of time and revived @ueen’s home screen PR. You can follow the progress here: Home Screen by ByteHamster · Pull Request #5864 · AntennaPod/AntennaPod · GitHub
This is how it currently looks (basically the same as @ueen’s work. My recent changes were under the hood only)
Now when using it for a bit while implementing, I am not sure I like the new way of showing the episodes. It does look more interesting than our existing lists but also has a few problems:
- Font size of the title is very small (12dp). I think it’s the smallest text we have in the app and I don’t think that is good for accessibility. Making it larger makes it impossible to read most of the title.
- The items are missing information like size, duration and playback position. This is especially interesting for the “Continue listening” part, where one probably wants to know how much is left.
- The lists do not support the new swipe actions that we are currently introducing everywhere else.
- It is a bit unclear what part of the cards should have what action. Currently, tapping anywhere on the whole card starts playback. Personally, I expected the card to open the episode details and only the play button to play. The play button is pretty small, though, so only the button might be hard to tap.
I think I would vote for using the basic episode lists like everywhere else in the app to avoid these problems.
Other thing I noticed: There now is a very prominent button to go to the statistics screen (next to “Check your classics”). I would rather expect that to link to the subscriptions screen because that’s a screen people use on a daily basis. The statistics are sometimes nice to look at, but not a regular thing that needs to be linked so prominently. Given that the statistics button is a lot more prominent in 2.6.0 already, I think it can be removed from the home screen.
1 Like
Awesome, it’s been a while but I’m glad we’re moving forward.
Just a few ideas, for the queue I think it makes sense to just have play on tap, I think you probably know what’s in there and want to continue listening (if not the still queue list is just one click away). Maybe a long click could open the episodes details page, to accommodate that use case.
Statistics I think can be fun, also for new users to discover, but it could be hidden (maybe by default) as well - as all sections can be moved or hidden on the settings button on the top right.
In general I’m sympathetic to your notion to have the episode list, I just want to share again my setup, where I have the episode list (kind of like a subscription box familiar from YouTube or classic RSS readers) which also allows the incredibly powerful SwipeActions, I basically never use any other screen at all, which is super handy.
One final thought, as intuitions and use cases differ, maybe we could consider offering different default configurations of the home screen on initial setup, I have in mind
- a more spotify oriented version (kind of like the current proposed design, maybe even with a added discover section)
- what I have, a somewhat rather traditional chronological subscription box (I found this to be the default expectation for some)
- as a third I think we should release the home as a public alpha/beta and instruct users to customize and see what they come up with or even what’s still missing for them
I actually removed both the “half screen” thing and the custom sort order for now because it didn’t immediately work or had edge cases. When trying to implement each and every feature in a single PR, it becomes too much work to review and test everything. It’s better to have a home screen that is not as feature-packed than to have the PR stay open for yet another year. The rest can then be added incrementally – maybe even integrating user feedback already.
That already opens the context menu
Hmm half screen is difficult to do right, I can see that, but the custom order and show/hide menu was working quite well I think and I did a few revisions as well. I think (optional) customizing is the main point of a unified home screen - to fit different use cases&preferences, so maybe you can point to specific issues you identified so they can be fixed, otherwise I would highly encourage adding it back in. 
My problem with the custom order was that I added a new screen and it did not show up at all (not even in the settings dialog) if one has already touched the order of the existing screens. I then changed the setting to work the other way around (like the nav drawer) – it now stores the sections that are hidden, not the sections that are shown. So show/hide is still there, just the sorting was removed (for now). It should still be possible to add it back at some point but I would rather try to get something ready to merge first before adding more extensive configuration.
Ah I see, but that should be easy to fix, just have an array/list of all sections, sort based on the preference and then all new added sections will be pushed to the bottom, no?
Yeah, it’s not a hard fix. It’s just one more thing to implement and to test. I was not 100% happy about the design of the settings screen as well and thought removing the setting for now would make it more likely that the home screen is ready to be merged in the near future. The shorter the PR, the easier to review/test