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?
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.
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.
The biggest pitfall is saving and restoring the app state when the configuration changes or the process is killed. Your app runs into UX problems and at one instance a crash, when the app is restored after the process has been killed.
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".
I may be wrong about it (because I haven't tried it enough) - Flutter feels kinda "reacty" (I think it is) and "javascriptish" to me. I was made/forced to work on react/javascript/angularjs for few months which started in the guise of "urgent help needed for 2 weeks in another team". It was trauma.
Besides I had never been able to get into anything JS or related. I started coding on C, then Python, then Java (very little Scala) and now Java and Kotlin. I dabbled with Go a little and it was nice.
Recently I had to make some changes to a react native component in one of our Android apps and it was a nightmare even though I was able to make those changes and ship very quickly. These just never made sense to me. As in - "why"? I think I am just averse/allergic to react/js/etc, or maybe I am not able to think deep enough, or something like - I am not wired a particular way :/
I've only done some light dabbling with JS (jQuery, Angular, and a few react/Vue tutorials), and I'm not much of a fan.
Flutter, however, has been awesome.
I'm actually putting the final touches on a project I've built during the quarantine with Flutter. It started out as an Android app built with Java, then I rewrote it in kotlin using the new (at the time) architecture components (which I found to be a big step forward from Java). Eventually I just couldn't find the time to finish the iOS version and decided to start fresh in flutter, and the experience has been amazing.
I find almost all of the framework much much more intuitive than either native platform's, and continually think to myself "this is how app development should have been all along."
Also, the app performance is buttery smooth :)
Anyway, clearly I'm a fan so I'd say Flutter is worth looking at. For me, perhaps the biggest advantage is that I have found the learning curve and tooling to be way easier to get through and understand than with either native platform.
I haven't dug into Flutter too heavily yet. While I really like Flutter as a portable UI toolkit I have reservations about a) Dart as a language looks a bit like a step backwards from Swift & Kotlin, at least TS is portable and useful elsewhere and b) Outside of UI work I feel like Flutter is a little lacking, there is a bit missing in terms of databases, networking, state management. Interop with native modules is also a bit messy and painful last time I checked. I'm guessing these reservations will diminish in time provided Google keeps pushing Dart and Flutter forward.
Those were some of the same concerns I've had going into it, but I've found that the plugin library for flutter is actually already surprisingly mature, both for official plugins and third party. Adding and using plugins is also easier than any other tool chain I've used.
Sqflite, rxdart, etc have worked well for me, though I will admit that this project is mostly just UI/CRUD so I've had to do very little native work.
I guess I'd say that flutter is already in a really amazing place for apps that aren't heavy on hardware-specific dependencies (like camera, AR, etc.).
I have my fingers crossed that the community will continue to grow to the point that it will flourish even if Google pulls official support at some point...
>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?
> 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.
There probably aren't many sawyers on iPhone, but still I'm curious... at this point in time, why not just a PWA for something like this? Even if the other advantages are controversial, with a PWA you can use the same app on a desktop that you use on a phone.
Exactly what I thought. Custom made administrative apps are the ideal use case for a pwa. Maybe performance and battery usage could be slightly improved by going native, but for some text based apps the benefits of pwa in terms of portability should make it a no brainer.
The App is used now by our workers in the wood warehouse to replace handwriting invoices. There is no online market place here. As a manager, if I want to know how the business does, I need to call the sales team at the warehouse and have a conversation for about 15 min, and I get no data to analyze. With this App, I am now getting near real-time info about the business without interrupting the workers and the sales team. The App is not for customers. The App is similar to the App that the waitress uses at the restaurant to take orders. The App can be adjusted to fit any other similar business field.
Maybe adjust the tagline to be something to be 'internal' or 'order tracker' to clear up the confusion?
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.
Thanks for the suggestion! I started with the Udacity course: Developing Android Apps with Kotlin. However, that was not enough. I knew exactly what I want to solve. I was facing specific problems so it was easier to google those problems and find the answers than following a course. I am not a good designer. I tried to make the design as right and as simple as the solution needs.
Not to be a Debbie downer but design wise it has issues both aesthetically and in its flow. It's hard to gauge the overall status in the order processing and functionality isn't presented in an easy to understand way. On top of that, the visual look is very dated and not very appealing. Both are relatively easy to fix and I can expand on the issues if you wish?
I was going to say, what version of Android is the demo video running? It looks like it's the Android design from 5 years ago. Definitely could use some UI enhancements.
That is a good point! Our workers have Android phones which are at least 6 years old. Later after the test period, I am planning to provide them with a tablet specifically for running this App.
My tip is not to use custom styling for buttons/text/etc just use the default Material design. It is already pretty nice, certainly better than what a non-designer can come up with. If you are interested in details, check out the design guidelines at https://material.io/, they cover a lot of stuffs from colors to padding sizes.
Thanks for your feedback. I tried to use data classes in Kotlin to remove hardcoded data from the main code. In Python, this is easy and very useful. Splitting the classes was confusing. I am sure I am going to make it better in my next App.
i think it's awesome that you solved a problem yourself and learned something new. to me, it makes sense that you built a native android app given the use-case you're describing -- offline, mobile, low-cost devices needed in industrial setting, etc. best of luck!
That's a nice pet project, congrats with HN 1st page) Out of curiosity: was it really nesessary to build a mobile app, what are the benefits compared to web-app?
The offline app is a better option than a web app since the internet can sometimes be a major problem. With this app, the workers can send the invoices to the server manually later if there was no internet at the moment of recording the invoice.
Congrats on solving your internal business problem. I did something similar for a company I worked for but using windows toughbook devices. BTW, what beer is that?
Great job. I am learning to build apps in android. Currently most of the tutorials and even books I come across have quite small examples to follow, usually 2 activity files and 2 layout files. Honestly, the progress to building a substantial app is a bit slow because the projects are so small.
This is an open question to all.
I want to know how you made the jump to 10+(activity and layout) files in a project, what resources lead you to getting to this level?
Cool to see someone’s first Android app and approach. I’ve been building hybrid app with Jetpack compose and SwiftUI. It’s also my first Android app and I was a bit surprised to see how many different ways there are to do one thing and how many are outdated compared to iOS. Compose is pre alpha and nowhere near ready for production but you can see the potential it has, there are rumours from the Android team about work already done that lets it run on other platforms. You can guess which one it likely is.
The App can be adjusted very quickly to serve similar business fields. You need only to change the products and properties in the data classes and some calculations logic. Of course, our real data is not open-sourced. I could not find similar solutions in the market so I decided to take the initiative to build one.
you are right! I used try and error with the workers. I kept in touch with them from the beginning. Besides that, I worked there during the summer break when I was a bachelor student. I have an idea of how stuff works there.
I once showed my offline repository app to an employer during an interview and got the same comment. My brain struggled to try to explain the meaning of the word 'offline'
I would never download an app just to buy stuff from a random company, even a local company I'd use (and live in a rural area now, person-to-person contact matters, I'm bought meat from local ranches, etc). Why should I fill up my phone's memory with such things? Why should I run someone's buggy and possibly malicious code on my personal machine?
Why build an "app" when you could build a website?
Is this just an exercise to give you experience? I couldn't fault the urge with everyone wanting to be employable and all but apps as substitute websites is kind of problematic thing. Most of what we're talking about is nearly static data, stuff that used to be on brochures.
I think there is a misunderstanding. The App is used now by our workers in the wood warehouse to replace handwriting invoices. There is no online market place here. As a manager, if I want to know how the business does, I need to call the sales team at the warehouse and have a conversation for about 15 min, and I get no data to analyze. With this App, I am now getting near real-time info about the business without interrupting the workers and the sales team. The App is not for customers.
That was my first thought as well, but I figured there must be something more to it and there is: this appears to be an application for the employees of the company use.
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).
The problem is that the workers are not sitting in front of the computer. They are moving around inside the warehouse with the customers. For them using a phone or tablet can be the best for them. Therefore, I chose to build an App that is simple but productive.
I've worked briefly with order picker software. It wasn't a POS but used in the same environment (roaming around a warehouse). It was a terminal application accessed in an android app with some proprietary equivalent of mosh (just this mosh-like android client was licensed at ~$10/device month).
Using an app instead of a site makes it easier for the user and you probably don't even want a browser on the device.
I put it in HN's second-chance pool (https://news.ycombinator.com/item?id=11662380) after inviting maherdeeb to expand his comment. HN readers like stories about real-world businesses, and like hearing about places that run on old technology and could benefit from software. The family business angle is interesting, and it doesn't get much more real-world than selling wood. Also, Show HN is a great place to share one's work, including as a beginner, and the community here likes providing advice and mentorship to people who are learning. (Edit: for a fine example see https://news.ycombinator.com/item?id=23484429 in this thread.)
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.
Because what makes the front page is determined by how much the people have seen it have liked to see it, and enough people have liked to see this on HN in a short enough period of time.
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.
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.