Android and code bloat

[Dennis Smith V]

Ok, I'm up to the he knows enough to be dangerous with Android. The problem is, I seem to be creating huge Activities. Handle a fling or 2, a few menu items, create some threads so I can show loading dialogs, a long press... I'm up to 270 lines and I'm not 1/2 done. With my real job, this easy enough, create a few logic classes, spring inject them and I'm good.

So I understand I can create other classes to handle events and such my activity doesn't need to implement OnGestureListener, OnDismissListener, I could do that in other classes. But even then that seems like the classes are still tightly coupled. Maybe that is just the way it needs to be. I really don't know.

Any good books you can recommend for me to look at? TBH I really do not learn how to do things in books, I learn doing and googling. But reading books for code philosophy I find very helpful.

[Ulf Dittmer]

One way this can happen is if the app has just a single Activity that handles everything (and thus just one central class). Android apps should consist of several activities, each (usually) handling a particular screen/view. The activities can still communicate with one another (by using startActivityForResult instead of startActivity), but would otherwise be independent of each other.

This also has the advantage that the "back button" really takes you back to the previous application screen, instead of closing the entire app.

[Dennis Smith V]

Thanks for the input Ulf. But in this case, I'm only handling one view. It's just a view that allows users to move from image to image using swipes, it loads images via text input or voice input, if the user likes the image they can long press the image and it will set as a wall paper. (of course with a prompt)

I've had the night to think about it, and I could throw some of this into an abstract class and that would be clean a reusable. Something like an abstract swipe activity which requires you to implement left and right swipes. I could throw all of the gesture stuff there and maybe even some of the threaded loading screens which I could make generic.

[Dennis Smith V]

BTW I did this and came up with with a very nice reusable abstract Activity. onRightSwipe, onLeftSwipe and some abstract methods that will be called with in a separate thread to deal with loading dialogs. In the process I cut the code on my main activity in 1/2.

[Ulf Dittmer]

Good point. As my apps do progressively more stuff, I find myself running more of it in background threads via extending AsyncTask; thereby moving into its own class.

[Dennis Smith V]

Thanks Ulf, the Painless threading link was helpful to me. Looks like I was doing it the painful way