19 ms·

After developing a few Android apps as an agency dev, we settled on a common structure that helped keep our code relatively clean. Each activity would have an

by shruubi 10y ago

After developing a few Android apps as an agency dev, we settled on a common structure that helped keep our code relatively clean. Each activity would have an associated fragment, the idea was that the activity would be responsible for loading the fragment as the current view and other lifecycle functions as well as being the entry-point for any external data-loading (through creating and calling of services). The fragment would initiate with a reference to the parent activity as a context, and would be responsible for view-centric things like displaying content and adding event handlers, which would more often than not use the context reference to call some remote API. I suppose you could think of it in terms of Model/Controller/View-Controller but I'm sure there is a more correct model for thinking about it (and it probably is more straight MVC anyways). The problem I've found with Android is that Google has created almost it's own language when it comes to Android app architecture, which creates a lot of confusion, especially for developers who just assume that all frameworks use the MVC concept (laugh if you will, but this is a thing). Even though google is quite behind when it comes to the app market, I think there is still time for them to come out with a new set of documentation which outlines the "correct" (the "Google-blessed" one at least) structure for Android apps so that we as a development community can start moving away from the "everything-and-the-kitchen-sink goes in the current activity" style of Android development.

jc4p 10y ago
What you described sounds a lot like what I used to do for years. It works fairly well, and you can tack a headless Fragment onto it for things that you don't want directly connected to an activty's lifecycle (rotating the screen mid user sign-up shouldn't restart the HTTP call, etc). This works well, and I'm at the point where I develop it without thought while creating new apps, but I've been playing with a less constrained DI flow instead using Dagger 2. The more business logic and multiple copies of shared UI elements in different Fragments are directly connected to their parent Activity, the harder it is to re-arrange and re-use them. I've been working on migrating all core elements of our application into a shared library project, and that would've been impossible with a closely tied codebase.
- jwatte 10y ago
  Have you tried putting all logic into a service, and only using fragments and activities foot display?
  - jc4p 10y ago
    To be honest with you all my experiences with Services have made me never want to use them.
    - christop 10y ago
      Binding services is pretty horrible, but I've very rarely had to do it. Using an IntentService is pretty straightforward and covers most use-cases of running something in the background. Though RxJava has quite reduced the amount of interaction I do with Android core components like Services.
- bschwindHN 10y ago
  > rotating the screen mid user sign-up shouldn't restart the HTTP call, etc This was the very first thing I struggled with when making my first (and to be honest, only) Android app. I was making an HTTP call in a background thread and when the screen rotated, the app crashed. Making this kind of basic functionality harder to program is such a big turn-off for the platform, and seriously lowers my confidence in the correctness of what I've written. I ended up writing this gross code (https://github.com/bschwind/skritter-android/commit/6fdffab111629cb79d732789b83a088e9c335eea https://github.com/bschwind/skritter-android/commit/6fdffab1...). That's probably not the recommended way to solve it now, or maybe it is. I don't know because everyone seems to have their own special solution to the problem, and we're lacking solid, idiomatic solutions to basic problems an app developer faces. For the small Android work I do now, I just stay in my own little NDK world. Edit: It also seems I was pretty frustrated with the android API at the time, lots of colorful print statements :)
  - jc4p 10y ago
    I used to use AsyncTask way more, I now stick to other ways to doing background processing. What you have is pretty close to what I described as a "headless fragment", it's a pretty common (but ugly, imo) paradigm, from the looks of it you either made something similar to or followed this: http://www.androiddesignpatterns.com/2013/04/retaining-objects-across-config-changes.html http://www.androiddesignpatterns.com/2013/04/retaining-objec... Nowadays I've pretty much drunk the RxJava kool-aid. For this kind of thing, I would make the HTTP method exist inside of an Observable which would be observed on a shared single instance Looper provided via Dagger.
AReallyGoodName 10y ago
There's a few issues with this though. Take various animations such as the one on the toolbar that some Google apps have (the arrow that spins into a hamburger and back again). Easy to do if you're just loading different fragments into a Framelayout, impossible to do with activities as you reload the entire toolbar on an activity change. It's a general problem in the Android world. Some things can only be done as an activity whilst others as fragments. In fact this is a problem even on Googles own apps. Right now if i tap things in the nav panel of the Gmail app it's a crap shoot whether i open a fragment or activity. Things like inbox/sent are loaded as fragments. Things like settings are loaded as activities with a completely different loading in animation. Help is different again. Lots of different ways of loading in a view all coming from options in the same menu. It's pretty fucked up form a UI perspective.
- saturn_vk 10y ago
  > There's a few issues with this though. Take various animations such as the one on the toolbar that some Google apps have (the arrow that spins into a hamburger and back again). Easy to do if you're just loading different fragments into a Framelayout, impossible to do with activities as you reload the entire toolbar on an activity change. I haven't even found an easy way to control the state of that animation, even if I use only one activity.
  - gagege 10y ago
    There are benefits other than cross-platform development to using web views or React Native or something that gets rid of the Android guts.
  - AReallyGoodName 10y ago
    Well it's easy enough to transition into arrow and hamburger ObjectAnimator arrowRotateAnim = ObjectAnimator.ofFloat(mDrawerArrowDrawable, "progress", 0.0f, 1.0f); arrowRotateAnim.setDuration(Constant.NAV_ARROW_TIME); arrowRotateAnim.start(); and vice versa on progress where mArrowDrawable is a DrawerArrowDrawable object. I set NAV_ARROW_TIME to 300 and it seems the same as what google has.

by shruubi 10y ago

jc4p 10y ago

What you described sounds a lot like what I used to do for years. It works fairly well, and you can tack a headless Fragment onto it for things that you don't want directly connected to an activty's lifecycle (rotating the screen mid user sign-up shouldn't restart the HTTP call, etc). This works well, and I'm at the point where I develop it without thought while creating new apps, but I've been playing with a less constrained DI flow instead using Dagger 2. The more business logic and multiple copies of shared UI elements in different Fragments are directly connected to their parent Activity, the harder it is to re-arrange and re-use them. I've been working on migrating all core elements of our application into a shared library project, and that would've been impossible with a closely tied codebase.

jwatte 10y ago
Have you tried putting all logic into a service, and only using fragments and activities foot display?
- jc4p 10y ago
  To be honest with you all my experiences with Services have made me never want to use them.
  - christop 10y ago
    Binding services is pretty horrible, but I've very rarely had to do it. Using an IntentService is pretty straightforward and covers most use-cases of running something in the background. Though RxJava has quite reduced the amount of interaction I do with Android core components like Services.
bschwindHN 10y ago
> rotating the screen mid user sign-up shouldn't restart the HTTP call, etc This was the very first thing I struggled with when making my first (and to be honest, only) Android app. I was making an HTTP call in a background thread and when the screen rotated, the app crashed. Making this kind of basic functionality harder to program is such a big turn-off for the platform, and seriously lowers my confidence in the correctness of what I've written. I ended up writing this gross code (https://github.com/bschwind/skritter-android/commit/6fdffab111629cb79d732789b83a088e9c335eea https://github.com/bschwind/skritter-android/commit/6fdffab1...). That's probably not the recommended way to solve it now, or maybe it is. I don't know because everyone seems to have their own special solution to the problem, and we're lacking solid, idiomatic solutions to basic problems an app developer faces. For the small Android work I do now, I just stay in my own little NDK world. Edit: It also seems I was pretty frustrated with the android API at the time, lots of colorful print statements :)
- jc4p 10y ago
  I used to use AsyncTask way more, I now stick to other ways to doing background processing. What you have is pretty close to what I described as a "headless fragment", it's a pretty common (but ugly, imo) paradigm, from the looks of it you either made something similar to or followed this: http://www.androiddesignpatterns.com/2013/04/retaining-objects-across-config-changes.html http://www.androiddesignpatterns.com/2013/04/retaining-objec... Nowadays I've pretty much drunk the RxJava kool-aid. For this kind of thing, I would make the HTTP method exist inside of an Observable which would be observed on a shared single instance Looper provided via Dagger.

AReallyGoodName 10y ago

There's a few issues with this though. Take various animations such as the one on the toolbar that some Google apps have (the arrow that spins into a hamburger and back again). Easy to do if you're just loading different fragments into a Framelayout, impossible to do with activities as you reload the entire toolbar on an activity change. It's a general problem in the Android world. Some things can only be done as an activity whilst others as fragments. In fact this is a problem even on Googles own apps. Right now if i tap things in the nav panel of the Gmail app it's a crap shoot whether i open a fragment or activity. Things like inbox/sent are loaded as fragments. Things like settings are loaded as activities with a completely different loading in animation. Help is different again. Lots of different ways of loading in a view all coming from options in the same menu. It's pretty fucked up form a UI perspective.

saturn_vk 10y ago
> There's a few issues with this though. Take various animations such as the one on the toolbar that some Google apps have (the arrow that spins into a hamburger and back again). Easy to do if you're just loading different fragments into a Framelayout, impossible to do with activities as you reload the entire toolbar on an activity change. I haven't even found an easy way to control the state of that animation, even if I use only one activity.
- gagege 10y ago
  There are benefits other than cross-platform development to using web views or React Native or something that gets rid of the Android guts.
- AReallyGoodName 10y ago
  Well it's easy enough to transition into arrow and hamburger ObjectAnimator arrowRotateAnim = ObjectAnimator.ofFloat(mDrawerArrowDrawable, "progress", 0.0f, 1.0f); arrowRotateAnim.setDuration(Constant.NAV_ARROW_TIME); arrowRotateAnim.start(); and vice versa on progress where mArrowDrawable is a DrawerArrowDrawable object. I set NAV_ARROW_TIME to 300 and it seems the same as what google has.