Description
I've encountered type mismatch issues with two functions: vodCategories() and vodItems(category: vodCategories.first). These seem related to how data types are handled in comparison to the API responses I receive from an Xtream API.
vodCategories Type Mismatch
When calling vodCategories(), I receive a TypeError indicating a mismatch between expected String and received int type for categoryId.
Error Message:
Error: TypeError: 583: type 'int' is not a subtype of type 'String'
Relevant Code:
/// The ID of the category.
@JsonKey(name: 'category_id')
String categoryId;
The API clearly returns category_id as an int whereas the library expects a String.
vodItems Type Mismatch and Missing Fields
When using vodItems(category: vodCategories.first), I encounter an issue where the library expects certain types that don't match the API's responses, and it also seems to be missing handling for some fields (e.g., tmdb_id).
Error Message:
Error: type 'String' is not a subtype of type '?num'
rating is expected to be a double but comes as a String.
Missing handling for tmdb_id.
Expected Behavior
The library should accurately parse the API's responses, accommodating for the actual data types returned by the API, including handling int where it expects String and vice versa, and it should not omit fields like tmdb_id.
Suggested Fixes
Dynamic Data Type Handling: It would be beneficial for the library to automatically handle data type conversions when the type of a received value does not match the expected type. For instance:
If the library expects an int but receives a String for category_id, it should automatically convert the String to an int.
Similarly, if a field like rating is expected to be a double but comes as a String encapsulated in quotes, the library should parse and convert it to double.
Additional Field Handling: The library should also introduce handling for additional fields such as tmdb_id that are present in the API response but are not currently accounted for. This ensures that all relevant data provided by the API can be utilized by the library.
Environment
Dart/Flutter version: Last
Library version: xtream_code_client: ^1.0.3
Conclusion
Although I would be keen to help solve these issues directly, I must admit that my current technical abilities do not quite match the level needed for such tasks. I want to express my gratitude to the developer for their efforts in creating this library. Although it hasn't fully met my needs yet, I recognize the potential it has to significantly aid my projects with the right adjustments. I hope my feedback will be useful in further refining the library, and I look forward to any guidance or updates that might help address these issues. Thank you for considering my suggestions.
Description I've encountered type mismatch issues with two functions:
vodCategories()
andvodItems(category: vodCategories.first)
. These seem related to how data types are handled in comparison to the API responses I receive from an Xtream API.vodCategories
Type Mismatch When callingvodCategories()
, I receive aTypeError
indicating a mismatch between expectedString
and receivedint
type forcategoryId
.Error Message:
Relevant Code:
API Response:
The API clearly returns
category_id
as anint
whereas the library expects aString
.vodItems
Type Mismatch and Missing Fields When usingvodItems(category: vodCategories.first)
, I encounter an issue where the library expects certain types that don't match the API's responses, and it also seems to be missing handling for some fields (e.g.,tmdb_id
).Error Message:
API Response Example:
Issues Identified:
rating
is expected to be adouble
but comes as aString
.tmdb_id
.Expected Behavior The library should accurately parse the API's responses, accommodating for the actual data types returned by the API, including handling
int
where it expectsString
and vice versa, and it should not omit fields liketmdb_id
.Suggested Fixes
int
but receives aString
forcategory_id
, it should automatically convert theString
to anint
.rating
is expected to be adouble
but comes as aString
encapsulated in quotes, the library should parse and convert it todouble
.tmdb_id
that are present in the API response but are not currently accounted for. This ensures that all relevant data provided by the API can be utilized by the library.Environment
Conclusion Although I would be keen to help solve these issues directly, I must admit that my current technical abilities do not quite match the level needed for such tasks. I want to express my gratitude to the developer for their efforts in creating this library. Although it hasn't fully met my needs yet, I recognize the potential it has to significantly aid my projects with the right adjustments. I hope my feedback will be useful in further refining the library, and I look forward to any guidance or updates that might help address these issues. Thank you for considering my suggestions.