Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Alert for outdated course calendars on the course home screen #416

Merged
merged 4 commits into from
May 7, 2024

Conversation

shafqat-muneer
Copy link
Contributor

LEARNER-9955: iOS - Alert for outdated course calendars on the course home screen

We need to display an alert for outdated course calendars on the course home screen. Currently, on the iOS application, this alert is shown within the dates tabs only.

Demo:

Simulator.Screen.Recording.-.iPhone.15.-.2024-04-26.at.09.16.16.mp4

@@ -140,6 +143,9 @@ public class CourseContainerViewModel: BaseCourseViewModel {
do {
if isInternetAvaliable {
courseStructure = try await interactor.getCourseBlocks(courseID: courseID)
Task {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

getCourseBlocks is async function, why are you using Task there? Don't we need to wait for dates before will set isShowProgress and isShowRefresh to false?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the course home screen, we are executing the getCourseDates API call solely to determine whether to display an outdated calendar alert or not. There is no UI population involving dates at this stage. Hence, we can optimize the loading time of this screen by running the getCourseDates API call on a separate thread. Once we receive the response regarding the dates, we can then decide whether to present the outdated alert or not.

Additionally, it's essential to populate getCourseBlocks before invoking getCourseDates because the getCourseDates method involves offline population of courseStructure.

forgotvas
forgotvas previously approved these changes Apr 26, 2024
Copy link
Contributor

@forgotvas forgotvas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@shafqat-muneer
Copy link
Contributor Author

@volodymyr-chekyrta @saeedbashir Kingly review the changes made in this pull request? Thank you.

@saeedbashir
Copy link
Contributor

@volodymyr-chekyrta @saeedbashir Kingly review the changes made in this pull request? Thank you.

@shafqat-muneer I'm not sure how but all of the old simulator environments are deleted from my machine. I'm downloading the simulator environment and will review when it's done.

@volodymyr-chekyrta
Copy link
Contributor

@volodymyr-chekyrta @saeedbashir Kingly review the changes made in this pull request? Thank you.

@shafqat-muneer I'm not sure how but all of the old simulator environments are deleted from my machine. I'm downloading the simulator environment and will review when it's done.

Same with me

Comment on lines 146 to 148
Task {
await courseDatesViewModel.getCourseDates(courseID: courseID)
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@shafqat-muneer, I don't know if this can be tested. We can't check what's going on inside the Task.
And this dependency on CourseDatesViewViewModel 🤔.
But I can't offer a good solution right now. Only we could send notification to CourseDatesViewModel instead of calling it directly.
What do you think?

In any case, the calendar flow will be heavily modified in FC-0047, so we can probably make do with this approach for now.

Comment on lines 274 to 283
courseDatesViewModel: CourseDatesViewModel(
interactor: r.resolve(CourseInteractorProtocol.self)!,
router: r.resolve(CourseRouter.self)!,
cssInjector: r.resolve(CSSInjector.self)!,
connectivity: r.resolve(ConnectivityProtocol.self)!,
config: r.resolve(ConfigProtocol.self)!,
courseID: courseID,
courseName: courseName,
analytics: r.resolve(CourseAnalytics.self)!
)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we create CourseDatesViewModel manually instead of injecting it via r.resole(...)?
And with this approach, we will have 2 different instances of CourseDatesViewModel for CourseHome. Is this ok?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

image

Maybe we can pass here the previously injected VM?

image

@shafqat-muneer
Copy link
Contributor Author

@volodymyr-chekyrta I've restructured it by using notifications approach 🎉
All set for another round of review.

Copy link
Contributor

@volodymyr-chekyrta volodymyr-chekyrta left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@shafqat-muneer Thank you!
LGTM! 🏎️ 🚀

Copy link
Contributor

@saeedbashir saeedbashir left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍

@shafqat-muneer shafqat-muneer merged commit bd9f081 into openedx:develop May 7, 2024
3 checks passed
@shafqat-muneer shafqat-muneer deleted the Shafqat/LEARNER-9955 branch May 7, 2024 16:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants