Summary
This is one part of the full Swiftfin Local Downloads feature that we would like to implement. The full feature does not require that all of the work be completed in a single PR, so I am creating individual Issues to track each part of the overall work that needs to be completed. This is to better allow contributors to divide and conquer rather than waiting on a single contributor to complete all of the work on their own.
Breaking this out from #364 into issues.
Create a new Protocol for something like MediaItem or like ItemViewable (name up for debate) that covers how the BaseItemDto it utilized for the various ItemViews. Migrate the ItemView and ItemViewModel to use the new protocol in place of the existing BaseItemDto. Finally, create a DownloadItemDto (name also up for debate) that conforms to this same protocol and contains all of the relevant information that we need to populate views in the same fashion as the current BaseItemDto.
Similar to how the Poster protocol works for BaseItemDto & ItemPerson.
Expectations
- A new
ItemViewable-type Protocol containing the necessary components for ItemViews
Example (Incomplete):
protocol ItemViewable {
// MARK: - Identity
var id: String { get }
var name: String { get }
var type: BaseItemKind? { get }
// MARK: - Metadata
var overview: String? { get }
var tagline: String? { get }
var displayTitle: String { get }
var genres: [String]? { get }
var studios: [StudioDto]? { get }
var premiereDateYear: String? { get }
// MARK: - Relationships
var parent: ItemViewable? { get }
var children: [ItemViewable]? { get }
var people: [BaseItemPerson]? { get }
var specialFeatures: [ItemViewable]? { get }
var similarItems: [ItemViewable] { get }
// MARK: - Media Info
var runTimeLabel: String? { get }
var presentPlayButton: Bool { get }
// MARK: - Artwork
func imageSource(_ type: ImageType, maxWidth: Int?) -> ImageSource
func imageSource(_ type: ImageType, maxHeight: Int?) -> ImageSource
- A new
DownloadItemDto object conforming to the new Protocol
- Should also conform to
Poster for PagingLibraryView
Acceptance Criteria
ItemViews should continue to work without issue.ItemViews should now be based on a more generic protocol opposed to the existing BaseItemDto
Collaboration Note:
If you choose to work on this feature, please be prepared to actively engage with feedback. We appreciate timely responses so the work can progress smoothly, and we may reassign a PR if it becomes stalled. This ensures contributors can continue building Swiftfin efficiently while maintaining momentum.
Summary
This is one part of the full Swiftfin Local Downloads feature that we would like to implement. The full feature does not require that all of the work be completed in a single PR, so I am creating individual Issues to track each part of the overall work that needs to be completed. This is to better allow contributors to divide and conquer rather than waiting on a single contributor to complete all of the work on their own.
Breaking this out from #364 into issues.
Create a new
Protocolfor something likeMediaItemor likeItemViewable(name up for debate) that covers how theBaseItemDtoit utilized for the variousItemViews. Migrate theItemViewandItemViewModelto use the new protocol in place of the existingBaseItemDto. Finally, create aDownloadItemDto(name also up for debate) that conforms to this same protocol and contains all of the relevant information that we need to populate views in the same fashion as the currentBaseItemDto.Similar to how the
Posterprotocol works forBaseItemDto&ItemPerson.Expectations
ItemViewable-type Protocol containing the necessary components forItemViewsExample (Incomplete):
DownloadItemDtoobject conforming to the new ProtocolPosterforPagingLibraryViewAcceptance Criteria
ItemViews should continue to work without issue.ItemViews should now be based on a more generic protocol opposed to the existingBaseItemDtoCollaboration Note:
If you choose to work on this feature, please be prepared to actively engage with feedback. We appreciate timely responses so the work can progress smoothly, and we may reassign a PR if it becomes stalled. This ensures contributors can continue building Swiftfin efficiently while maintaining momentum.