[Groxx]

The thing that would've saved me the most time and frustration in the long run for all mobile development (well, all dev period, but mobile especially as they tend to be moving targets):

Ignore the framework. Write your app how you want to write it, then attach it to the framework as needed. Don't restrict yourself to what the framework supplies or how it thinks about things.

It'll dramatically decrease craziness in your core logic in the long run. Framework versions and bugs can lead to strange lifecycle callbacks, weird interactions between the N flavors of how to build UI components, etc, and if your core logic is chopped up to deal with all of this it can become very hard to make important changes. Such as updating to a newer version of the framework so your app isn't removed from the stores.

It'll pretty much always be more up-front code and work, but you'll be left with a far clearer system in the end.

[rmdashrfstar]

Related to this is “clean architecture”. Your code should not be dependent on a feature-laden framework. You should focus on writing your business domain and rules, then separately orchestrate your domain, and connect the UI and other external frameworks as interfaces to the lower, or more generic, levels of your application.

This is a general software design principle that allows for your UI to be free to change without affecting your core logic and rules, while also making all of your code more unit testable.

[richard78459]

With React hooks or android component life cycle its hard separate the framework and logic. How do you do it ? Any recommended books or other resources ?

[Groxx]

React's behavioral features are relatively difficult, I'll grant, but it's entirely possible to use it as a relatively dumb "render X efficiently for me" target. If you're using hooks heavily, you're deeply entangling your code with the framework - that's your choice, but yeah, it comes with consequences as well as benefits.

Android lifecycles are probably the main target of my comment tbh. They're abysmally complex and make any kind of state management incredibly error-prone.

As a tradeoff for that complexity and losing a lot of control, if (and only if) you go all-in on them, you get decent state reviving after process death, which can do really slick things like "app crashed" -> it just appears to go back one screen.

Instead, you can write your app as e.g. an in-memory singleton somewhere. You can even do that in a different thread if you want, leaving your UI impossibly smooth (at increased risk of "tap x" -> "nothing happens"). Design your own lifecycle that makes sense for your app (which probably looks very little like the Android lifecycle, especially when you throw in fragments...) and trigger/wait on the external world of the Android framework as needed. Odds are pretty good that you'll take multiple things from Android and combine them into one in yours, and potentially vise versa (e.g. multiple actions from your app become view updates in a single activity, rather than multiple activities. or do everything in one activity, it's often far better performance anyway, and much easier to control in fine-grained ways. importantly, your core logic doesn't care, unlike if you put that logic in the activities).