Skip to content

jozefv-git/jozefv-git

Folders and files

NameName
Last commit message
Last commit date

Latest commit

Β 

History

2 Commits
Β 
Β 

Repository files navigation

πŸ“° WhatsNew

Browse the news from around the globe! Filter, search, save and much more!

Expected Guest user flow

Introduction Screen Articles Screen Detail Article Screen Filter Screen List Screen with filters
whatsNew_Guest_Intro whatsNew_Guest_Articles whatsNew_Guest_Article_Detail whatsNew_Guest_Filters whatsNew_Guest_Articles_Filtered

Expected Authorized user flow

Registration Screen Login Screen
whatsNew_Registration whatsNew_SignIn
whatsNew_Authorized_List.mp4
whatsNew_Authorized_Filter.mp4
whatsNew_Authorized_Search.mp4
whatsNew_Authorized_Profile.mp4

πŸ”‘ Features

  • Articles browsing
  • Advanced filtering options
  • Article saving
  • Article share 🌐
  • Custom design / dark mode πŸŒ“
  • Anonym / Registered user browsing

πŸ’» Technologies

  • Kotlin
  • Jetpack Compose
  • Coroutines / Flows
  • Koin
  • Coil
  • Ktor
  • EncryptedSharedPreferences
  • Room + FTS4 πŸ’Ύ
  • Adaptive navigation
  • JUnit
  • Turbine
  • Ktor Client Mock
  • SOLID / MVI / UDF
  • Custom design style

πŸ“– Project Structure

Application follows single module architecture, however, it is divided by features. Each feature represents own "standalone" part (functionality) of the app. Feature is further divided by three common layers - Data, Domain and Presentation. Feature should not have access to other feature. The exceptions are "core" and "app" feature. Core feature can be accessed accross the app - and its contains logic shared among the different features and components, however default Data, Domain and Presentation layering must be complied. Core feature cannot depend on any other feature. App feature acts like a "glue" between the features - their main focus (in this application) is to navigate between the screens and initialize our DI modules.

  • Data layers contains concrete implementations for our business logic abstractions which are defined in the Domain Layers.
  • Domain layer should stay free of any external dependencies and contain only pure business logic and may include models and abstractions.
  • Presentation layer is used to react to user interaction and provide the most actual visible content (state) for the user.

What to keep in mind

Features may access core feature as long as they don't break layer pattern. The layer pattern is as follow:

  • Domain layer can be accessed from the Presentation and Data layer.
  • Domain layer cannot depend on Presentation or Data layer and should be free of any external (ex. android) dependencies.
  • Presentation and Data layer cannot access each other. If we combine these rules together with core feature, we will get behaviour as follow:
  • feat_profile.presentation can access core.presentation and core.domain.
  • feat_profile.domain can access core.domain.
  • feat_profile.presentation cannot access core.data or feat_profile.data

Others

  • WhatsNew contains basic Unit and Integration tests πŸ§ͺ
  • WhatsNew feat_articles contains one shared viewModel for multiple screens of the same feature.

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published