Comment by maherdeeb | Hacker News Reader

Comment by maherdeeb | Hacker News Reader

Parent Full thread

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.

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.

That is great feedback! It is really helpful and I am going to consider those points next time! Thank you very much for your time and effort.

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.

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

Thank you very much for your feedback. This will the first important point to consider in the next release.

Hey if you are starting with Android development, take a look at http://flutter.dev

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

Currently rewriting an android app that had a cpp .so for its main functionality.

It's a really great bit of kit. However I'd say also requires a bit more "up front" learning if like me you've avoided js as much as possible.

But the whole toolchain is so smooth and simple.

Then of course I'd intend to build for iOS. Not even looked into that yet

Yes Android in general has improved a lot in the last 3 years (imo). What drove me to Flutter was not having enough time to do both Android and iOS.

I've also found doing animations and prototyping with UI ideas to be much much easier and faster in flutter than in Android.

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

Your illustration about activity vs fragment is awesome. I wish I knew this before. Thank you very much!

Reply on news.ycombinator.com