This week's book giveaway is in the Agile and Other Processes forum.
We're giving away four copies of The Little Book of Impediments (e-book only) and have Tom Perry on-line!
See this thread for details.
Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Android and code bloat

 
Dennis Smith V
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Rancher
Posts: 42969
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Rancher
Posts: 42969
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Ulf, the Painless threading link was helpful to me. Looks like I was doing it the painful way
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic