0

My doubt here is how to achieve a clean and easy code to maintain over time in an Android app?, I'm trying to apply Uncle bob - clean code rules but as I keep going with development sometimes some rules must be broken, and I end with an Activity of 700 lines (I'm not using Fragment, and 700 lines seems to be a Class that "does too much things") so I want to know if someone has try an Android app with proper use of Fragment and could answer these questions:

1- does it really impact on Activity lines length (at least less than 300-500 [not strictly this numbers but a "reasonable" Class length] lines)?

2- does code keep clean and easy over the time?, not necessary with Uncle bob rules but considering best practice in OO while coding.

3- does it have a considerable impact in terms of "Performance"?

4- does Fragment help to support in a more simple way a wide fan of Screens?"

5- ignoring developer skills, what "should" be the way to go non-Fragment activities or activities with rich Fragment use?

Note: this is not an attemp of Duplication to Android - Activity vs FragmentActivity? since the topic here is not about tab format but best practice for android development.

sorry for my english ;).

Community
  • 1
  • 1
jac1013
  • 408
  • 3
  • 11
  • Nothing forces you to put every code used by an `Activity` or `Fragment` inside that class. It's rather easy to get to more than 300 since their responsibility is quite big and you'll have to put quite of lot of code inside those classes simply to interface with them. OO wise, those classes are designed with too much responsibilities. – zapl Jul 22 '13 at 16:31
  • @zapl: so what do you propose as a "good" solution for this let's say "problem" or there's really no solution for this? since things will work around no matter the code is `Activity` or `Fragment` like, but what i want to achieve is clean and easy to maintain code. – jac1013 Jul 22 '13 at 19:08
  • There is no generic solution to this. But it is usually possible to move larger code fragments that most people put directly into an Activity / Fragment into it's own encapsulated object. For example those `onClickListener`s that you assign to buttons. You can easily put that code into a different class, say an instance of a `ButtonClickHandler`. After all just basic Object Oriented programming. – zapl Jul 22 '13 at 19:49
  • yep, that's exactly what I'm doing, let's say a TextView that needs to get a Resource from R, it would be necessary the Activity to call `getResource()` or `findViewById()` or `getString()` any method related to Activity Class, that's why im concluding Fragment will do the work here, and as CommonsWare answer to my question number 4 for support a wide range of screen size. – jac1013 Jul 22 '13 at 20:02
  • Any method related to the Activity or Fragment class can be called by an external object if it has a reference to the class. E.g. `new ButtonHandler((Context) this)` can now do `getResource()` or `getString()` on its own. The difference between `Activity` and `Fragment` is basically that `Activity` is tied to the lifecycle of one `Context` (`Activity` *is* the `Context`) while `Fragment` is not. Fragments are just attached to context and can be re-used with a different context. None of them provide any benefit when it comes to encapsulating functionality into other classes to keep code clean. – zapl Jul 22 '13 at 20:16
  • i know i can pass an instance of the context to the classes (im doing it actually), but i dont want to have an Activity variable per new class where i want to encapsulate functionality (i know it's the same instance so in terms of performance it won't affect) I know it's a must too, but if I'm going to implement it would be with the Observer pattern and not just an `Activity activity` in every class, that Activity should act as a Observer or Listener to those classes and have a meaningful name, making it with the `Activity activity` member in every class sounds like a bad approach for me. – jac1013 Jul 22 '13 at 20:31

2 Answers2

1

You are conflating the use of fragments with the use of FragmentActivity.

FragmentActivity is a subclass of Activity designed for use with the backport of fragments from the Android Support package. You usually only use FragmentActivity if you are using the backport. If you are using fragments, but your android:minSdkVersion is set to 11 or higher, you can usually skip FragmentActivity.

With that in mind:

does it really impact on Activity lines length (at least less than 300 lines)?

That is impossible to say. It is equivalent to asking whether a Restaurant that subclasses Business will be longer or shorter than a Restaurant that subclasses FoodSupplier. It all depends on your code.

That being said, it is certainly possible that the use of fragments will reduce the lines of code in the activity. IMHO, that's not a good reason to use fragments.

does code keep clean and easy over the time?, not necessary with Uncle bob rules but considering best practice in OO while coding.

That is impossible to say. It is equivalent to asking whether a Restaurant that subclasses Business will be "clean and easy" compared to a Restaurant that subclasses FoodSupplier. It all depends on your code.

does it have a considerable impact in terms of "Performance"?

Not usually.

does Fragment help to support in a more simple way a wide fan of Screens?"

If by "wide fan of screens", you mean "a wide range of screen sizes", then yes, fragments can help with that. In fact, that's the #1 reason for using fragments, IMHO. However, fragments alone do not magically help with screen sizes, any more than having capital letters in method names magically helps with screen sizes.

ignoring developer skills, what "should" be the way to go FragmentActivity or Activity?

As stated previously, you usually only use FragmentActivity if you are using the backport of fragments. If you are using fragments, but your android:minSdkVersion is set to 11 or higher, you can usually skip FragmentActivity.

If your question really is "should I be using fragments in my app?", the answer is "probably, but it depends upon the app".

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • you are right about this `"should I be using fragments in my app?"` i'll fix my question. – jac1013 Jul 22 '13 at 16:35
  • I fix the `Class length issue`, what I'm trying to tell is to not have an Activity with let's say 2000 lines, for me that's a mess to work in. – jac1013 Jul 22 '13 at 16:42
  • @user1322142: "what I'm trying to tell is to not have an Activity with let's say 2000 lines, for me that's a mess to work in" -- it is conceivable that fragments will help, but as a side effect. There is nothing stopping you from refactoring your code in other ways, using ordinary Java classes, that reduces the lines of code in any one given class. – CommonsWare Jul 22 '13 at 17:13
  • CommonsWare:"There is nothing stopping you from refactoring your code in other ways, using ordinary Java classes, that reduces the lines of code in any one given class." you are right but... doing so will involve a heavy overuse of the Observer pattern (since we need some `Activity methods` in those new `non-Activity-ordinary-Java-classes`) specifically the Class I'm talking about (the 700 lines one) implements 6 interfaces, and those are for Background Process issue, those 700 lines are purely View code (I'm using an MVC grasp) that's why i wonder does Fragment would help me in my case? – jac1013 Jul 22 '13 at 18:07
  • @user1322142: Code related to the widgets would tend to move into the fragments. – CommonsWare Jul 22 '13 at 18:08
  • I'll buy that, another thing: package organization for fragments? same rules of ordinary Java package organization? or anything special to take into consideration? – jac1013 Jul 22 '13 at 18:37
  • @user1322142: "package organization for fragments?" -- I recommend sturdy well-labeled corrugated cardboard boxes. :-) "anything special to take into consideration?" -- as with activities, if you do not have your fragments in the package that you declared in your manifest, you will need to manually import your `R` class. Otherwise, there are no particular rules here. – CommonsWare Jul 22 '13 at 18:39
  • "I recommend sturdy well-labeled corrugated cardboard boxes. :-)" oh god... haha, well of course I won't need to manually import my `R` class for sure, thanks CommonsWare. – jac1013 Jul 22 '13 at 18:45
0

Yes, fragments are the way to go. They help spread your code around in a logical way so you don't have a 700 line activity, they keep your code easy because each fragment will have its own class usually, and they do, to answer your 4th question, make it easy to have "A wide fan of Screens".

I recommend this video to help get you started. For any beginners, this video is a great explanation of how to use fragments ( I know because I had a hard time figuring out how to use them until I watched this video). It is called "Programming Android with Fragments" by Andrew Ruffolo:

http://www.youtube.com/watch?v=KyXvq_kwfzg

This video demonstrates the power of fragments. You still need a main activity of some kind, but this main activity acts kind of like a container for the fragments, and most of the functionality of your app is handled by the fragments and their corresponding classes.

I have never used activities because I started app development after fragments were added to android, but it seems like fragments help break down your app in the same way that methods and inner classes help break down your classes, and the same way that classes help break down a project or program. I am not sure if this was possible or as simple using only activities before fragments were added.

scottysseus
  • 1,922
  • 3
  • 25
  • 50
  • with activities it still possible to break things, but it's a bit harder, because the Observer pattern is a must for doing it, not everyone know this pattern (at least how to implement it) and still the coupling between classes is not so loose and that bring us to question ourself if a class is really only doing the "things" that should do, what you are telling here could be the answer, but i need to hear an opinion from someone who develop with activities-without fragment and activities-with-fragment, in my practice i've been doing the first one. – jac1013 Jul 22 '13 at 18:17