What I did:
Today, I fixed a small UI issue on the ArticleScreen. Afterward, I implemented logic to open the article feed for the selected screen. I noticed that when opening several tags in a row, only the tag was displayed on the screen.
After debugging, I found that the instance of Voyger's ScreenModel was identical for every open screen. I use the Koin factory method to create instances and expect that each time I open a new screen, a new ScreenModel will be created for it. However, something goes wrong.
My initial thought was that I might have sent incorrect parameters in koinViewModel() and Voyager didn't recognize the parameters as being different. I converted the models to data classes, which should have prevented this behavior. However, this didn't resolve the issue. I found a solution in the Voyager sample with Koin integration:
class KoinScreen : Screen {
override val key: ScreenKey = uniqueScreenKey
@Composable
override fun Content() {
val screenModel = getScreenModel<KoinScreenModel>()
ListContent(screenModel.items)
}
}
I couldn't find the exact code where the key was used, but I believe defining the scope correctly is crucial for this class. By default, the key is a string related to the class name. As a result, If I open several identical screens, they will share the same SreenModel. This line of the code prevents this behavior: override val key: ScreenKey = uniqueScreenKey. Finally, I added logic to fetch user data by ID.
What I will do:
- Update README file with description of project.
- Fix comment element
- Implementation of WebView to display stub content
- Theme configuration for Lottie animation
- Create public collection of API calls in Postman
If you want to join the project, just leave a comment here, or write a message in LinkedIn.
What help I'm looking for:
Designer (create design of application in Figma)
Android/KMM developer
Any other help related to the project.
My timeline:
Day 1. Deep breath and dive.
Day 2. Networking layer.
Day 3. Loading of articles.
Day 4. ArticleItem.
Day 5. Localization.
Day 6. Work on Sunday.
Day 7. First week.
Day 8. Enjoying coding.
Day 9. Expect/actual.
Day 10. TODOs.
Day 11. Friday evening.
Day 12. Frustration.
Day 13. Blocker
Day 14. Monday
Day 15. Reactions
Day 16. Feed
Day 17. stringWithFormat
Day 18. Comment
Day 19. 1 percent
Day 20. A bit of progress
Day 21. Pagination
Day 22. Lottie animation
Day 23. Sorting of articles
Day 24. Step by step
Day 25. Broken endpoint?
Day 26. After party
Day 27. Burnout
Day 28. Opportunity for growth
Day 29. Hard work
Day 30. Old code
Day 31. Technical debt
Day 32. API calls
Day 33. Generic response
Day 34. Response
Day 35. Coderabbit
Day 36. What is the power of Pull Request?
Day 37. Search challenge
Day 38. Search items
Day 39. A party
Day 40. Fixing UI
Day 41. Surpassed record
Day 42. Monday
Day 43. Composition
Day 44. Timestamp
Day 45. Time manipulation
Day 46. Broken pipelines
Days 47-48. Broken API
Day 49. Organization card
Day 50. GitHub Universe
Day 51. Article Screen
Day 52. Collapsing Toolbar
Day 53. Plan
You can find more useful content on my LinkedIn page, on X, in Medium or Mastodon.
See you tomorrow.
Top comments (0)