| Motivation: My family owns a company that sells sawn wood and plywood products. Although I am currently not engaged in its business, I am very interested in finding out how the family business does. Moreover, I would like to put data-driven options on the table to improve the company in the future. The company is still following the 19th-century best practice. The workers handwrite all invoices, and technology has no role in making decisions. Besides that, there is no clear strategy about passing experience to the next generation. I want to change that by creating a pipeline that makes transferring data, experience, and insight happened near real-time. Design: I am very interested in the community's feedback regarding my App and code design: I used activities instead of fragments. I had the feeling that the fragment was not the best option because the navigation plan can be too complex. am I right? I used a class to initiate my data classes and share them between different activities instead of using the intent to share data. Do you think my option was correct and what could be the best practice for sharing data classes between activities? When choosing the products, I used only a single activity and used code to change the design of the activity. I thought it that can be faster than using many activities and keep the download size smaller. Does it make sense? For more info you can check the demo here:
https://www.youtube.com/watch?v=8MdLv3h-j-o My background: I am a Data Scientist, and I come from Python World. My programming experience is good enough to tackle advanced challenges especially in the case of Machine Learning and Deep Learning. As a problem solver, I enjoy utilizing all possible resources to come up with a valuable solution. I believe that DS people can perform better when they have the right communication channels with developers and stockholders. That is why I am here. If you have any questions, suggestions, or feedback, I would be happy to answer. |
- 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.