I didn't dig too deeply into the code itself and the logic flows, but at a very high level I could start with some project organization feedback that might make your life easier down the road:
- You don't have to use a Navigation Component in order to use Fragments. You can still use a single-activity model that just manually calls the fragment manager to make fragment transactions if your app is simple enough to not require a full Navigation graph. The overall reduction in complexity with single-activity are still very worth it, imo. Much easier to attach interfaces than deal with activity results and scene transitions if you don't need to.
- You don't have to just have one "app" module in your project. You don't even have to call it "app." You can rename the module to whatever you want, like "wood-client" or something more informative than "app." You could create a second module called "wood-data", and then have all of your data classes defined in separate files in a "model" package. I don't see much reason to pack all your data classes into one file. Android Studio is a fully fledged IDE built on IntelliJ IDEA with things like shift-shift search, and ctrl+o. no reason to compact things into one file.
- Speaking of packages, you should think better about your package naming scheme. "com.example.woodinvoicetest" is messy to call it "example," and confusing to call it "<something>test" when it's not actually a test code package. A simple starting point could be something like "com.woodinvoice.client," "com.woodinvoice.common," "com.woodinvoice.data," etc.
- Don't worry about download size right now unless you are packaging a lot of graphics content into your APK, like bitmaps and large icons or something. This is a problem for future you to deal with, honestly. You don't have enough workflows yet to worry about app size. You're not building a social/consumer app, so user dropoff for a long download time doesn't mean anything to you right now.
Having dealt with fragmentManager and supportFragmentManager a lot, I highly recommend using Navigation Component. It may be confusing to set it up initially, but once you do it, it makes navigation really easy to handle.
- You don't have to use a Navigation Component in order to use Fragments. You can still use a single-activity model that just manually calls the fragment manager to make fragment transactions if your app is simple enough to not require a full Navigation graph. The overall reduction in complexity with single-activity are still very worth it, imo. Much easier to attach interfaces than deal with activity results and scene transitions if you don't need to.
- You don't have to just have one "app" module in your project. You don't even have to call it "app." You can rename the module to whatever you want, like "wood-client" or something more informative than "app." You could create a second module called "wood-data", and then have all of your data classes defined in separate files in a "model" package. I don't see much reason to pack all your data classes into one file. Android Studio is a fully fledged IDE built on IntelliJ IDEA with things like shift-shift search, and ctrl+o. no reason to compact things into one file.
- Speaking of packages, you should think better about your package naming scheme. "com.example.woodinvoicetest" is messy to call it "example," and confusing to call it "<something>test" when it's not actually a test code package. A simple starting point could be something like "com.woodinvoice.client," "com.woodinvoice.common," "com.woodinvoice.data," etc.
- Don't worry about download size right now unless you are packaging a lot of graphics content into your APK, like bitmaps and large icons or something. This is a problem for future you to deal with, honestly. You don't have enough workflows yet to worry about app size. You're not building a social/consumer app, so user dropoff for a long download time doesn't mean anything to you right now.