Show HN: My first Android App – order-taker for family company that sells wood

- 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.

> 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?

This is where fragments come into picture. You break up parts of your UI in fragments then swap then in and out of your activities. You can also use multiple fragments to compose the UI in an activity.

A good way to think of this is to consider an activity as a Room. All the various tables, furniture, etc inside the room become fragments that you can move in and out of rooms according to your need. To extend this analogy a bit more, you can use multiple activities to separate the various logical parts of your app. Similar to how an apartment has many rooms, with each room having a separate function.

Btw, This is the kind of thing that got me into programming as a kid. An excellent use of technology to solve a personal pain point in a traditional business. Keep working on it.

In my opinion, this is probably the most important chapter in the android developer guide: https://developer.android.com/guide/components/activities/ac...

When a user puts the app in the background, the app is at risk of being closed. Who knows, maybe someone gets a call in the middle of an invoice creation. Or someone wants to check an email from a customer again.

> I used a class to initiate my data classes and share them between different activities instead of using the intent to share data.

The problem here is, that the data class gets lost if you only keep it in memory without persisting it. The good thing about intent data is, that the intent data is stored even between process kills.

A good way to test this behavior is to go into the android developer settings and set "Background process limit" to "No background processes".

What learning resources did you use when building this? Personally whenever I've looked at building an app, I find the concepts for layout and communication entirely opaque and unintuitive.

An android app that the workers use to collect orders from the customers. After confirming the payment, the App sends the data to the remote server.

So customers aren't meant to install this app. Though, honestly, looking at the video, it still seems like a website could do the same job. Maybe they need it to work offline (and are not aware of/don't want to bother with the web tech that tries to deal with that).

When we put a submission in the second-chance pool, it gets a random placement on the front page. If we guess wrong about what people will find interesting, it soon falls off. This one has gotten quite a few upvotes already, though, so my guess is that I guessed right, at least for some! If you don't think it's interesting, that's fine—nothing interests everyone—but please don't post unsubstantive comments about it, especially not in Show HN threads. Those have special rules (https://news.ycombinator.com/showhn.html), because sharing one's work on the internet puts a person in a vulnerable position.

Instead, simply look at some of the other things there are to read here. If you run out, I recommend the 'past' link in the top bar. It will take you back to the major threads of recent, and not so recent, days.

Edit: there's actually another reason why this is interesting: it's unpredictable. The best things on HN are the ones that you can't predict from any existing sequence (https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...). I'd say "my family has a business selling wood products which still operates on hand-written invoices, and I decided to learn Android programming by writing some software to try to help with that" is on the one hand a classic HN story, yet on the other hand has elements that are quite uncorrelated. A good mix of familiar and unfamiliar makes for a satisfying HN story.

Almost everything is 'on-topic' if we decide it's interesting, and that's why HN is my #1 visited site by a long stretch.