• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Apps What design patterns do you use?

Q

QuickNick

Newbie
Good day, friends.

What design patterns do you use in your applications?

We use pureMVC framework: from activity methods we send notifications, mediators handle notifications, proxies and layouts. It wasn't proved to be 100% satisfactory for me, and I'm willing to use something else.

What did you recommend?
 
A little more details.

Suppose we have complex activity with the complex layout and async tasks.
Where do you set listeners, build dialogs, turn async tasks on, publish results from separate thread? In which class?
 
Good question! I think what patterns you use are up to you.

Patterns in essence, are really just logical ways to solve common problems. The pattern you use, depends on the problems you will face.

Personally I have found the Factory pattern very helpful.

I have also found it extremeley helpful to use POJOs (Plain Old Java Objects) to encapsulate data. As opposed to Java beans with lots of getters or setters. get/set is verbose and harms readability (IMHO). You also take a very small performance hit accessing a method over a property.


Anyways, android already is "kinda" MVC-based so I think the PureMVC framework might be excessive.

(Adapters = Model, Layouts = View, Activity = Controller)

The biggest problem I have found is that you need to avoid the "God anti-pattern" with Activities. They tend to fill up with code quickly. Personally I dont use ASyncTasks because I find Runnables and threads to be easier and more powerful and flexible.

Threads can also be separated out from an Activity to help reduce the clutter. I highly reccommend mastering the use of passing around Handlers and Context (Application - Context, be careful with Activity Contexts, you can cause memory leaks). But once you know how to use handlers to pass messages your Threads and Activities and Adapters and Models will be all working harmoniously just like the messaging systems of PureMVC (think of Handlers as Mediators)


Iterator stuff is of course always useful in Java. As are related Queue/Memento and other patterns.


hth
 
Thanks, it was very interesting and informative answer :)

Current code of our application looks like spaghetti (previous developer doesn't like design patterns but likes God objects) even with pureMVC, so I decided to fix it - that's why I asked about patterns.

I found out that my solution is called MVP (Model-view-presenter - Wikipedia, the free encyclopedia): different managers, services are model (thanks to you I've found out that adapters should be in model too), activity is presenter, layouts are view. I save and load preferences in activity, set listeners in layouts, and make internal calculation/playing sound/etc in model.

There is one interesting task. I have 3 different activities, all of them should use one model (for sound analysis). This model sends results in short periods of time (every 200-500 miliseconds). And result should be sent only to visible activity. What structure should I use - is it service? Or maybe something else?
 
Service can work well for that yeah. Just need to be careful about how the service is started or stopped. Check the API docs, there is a lot of info on the Service class.

You may want to set a custom BroadcastReceiver that will start the Service if it doesnt exist.

This BroadcastReceiver would also allow an activity to register and unregister as an observer. Then you activity could register itself in onResume(), and unregister in onPause()

And I guess when I think of MVC I really mean MVP -- I never had the controller handing user input, mine was always a middle man. And i personally made the model mostly a dumb data store with the adapter "protecting" it.

(I think Android does this too, and it's sort of why Models are called Adapters in Android).

"Business" logic (or just "logic") I try to put in commands (command pattern) -- Something like a runnable would work fine for this purpose. Or even a static class/factory. Basically anywhere I could seperate out the concern. This would also lead to better (functional) cohesion.

This also allows for using delegates and responders to handle server interaction or IO.

Then, I would have the controller handle events sent from the views and route them to the proper command. Almost like a Service Locator pattern.

I'm trying to use the command pattern more, but it takes a lot of time. It is GREAT for de-coupling and modularity though.

I'm also slowly trying to move toward more dependancy injection for the same reasons, but I dont think my Java is that good yet. (I learned coding in ActionScript hehe :) )


Basically, while not the strict dictionary definition of MVC, I always thought of it like this in my mind:

Model - A model or structure to represent how the data should exist
View - what the user views aka the UI
Controller - the class that controlls the interaction between the model and view

This made it easy to remember and implement for me, although I know this is a bit off from what someone writing a book on MVC would say they are. But mostly MVC and Java and small talk was written durring the time of client-server interaction.

Views were web pages, models were SQL databases with prepared statments for transaction processing, and controllers were middleware languages like php and Java.

This just doesnt exist in the same way in current application programming. The frontend itself can have very complex MVC type architecture, without ever needing a server.



Long story short though, I love thinking about this stuff, but sometimes you gotta just use any pattern that seems obvious and get coding :)
 
Now, I'd like to ask about place of Dialogs and BroadcastReceivers in the MVP/MVC architecture.

As I understand, BroadcastReceiver is clearly controller. ContentProvider is model.
And what about Dialogs? Are they controllers or views?

Another question. What way is best for initialization of AlertDialogs?
I've inited AlertDialog by AlertDialog.Builder right in the Activity method onCreateDialog(int id), but activity becomes too big very soon. It's look like I should try this way: create new class MyAlertDialog which extends AlertDialog, init it and so on.

What will you suggest, friends?
 
For applications, I use the obvious OOP paradigm, as well as MVC concepts.

For games, however, I usually use a lot of different concepts, including OOP, COP (CBA), Singleton (As mentioned above), and more.

With that said, worrying too much about design patterns can be a bad thing. In the end, you want to do what you need to do and do it in the most efficient way. This is an especially common train of thought for game programming and other performance demanding applications. If the most efficient way of doing what needs to be done ends up straying from your normal design practices, then you shouldn't be hesitant to do it in that most efficient manner.
 
QuickNick said:
Now, I'd like to ask about place of Dialogs and BroadcastReceivers in the MVP/MVC architecture.

As I understand, BroadcastReceiver is clearly controller. ContentProvider is model.
And what about Dialogs? Are they controllers or views?

Another question. What way is best for initialization of AlertDialogs?
I've inited AlertDialog by AlertDialog.Builder right in the Activity method onCreateDialog(int id), but activity becomes too big very soon. It's look like I should try this way: create new class MyAlertDialog which extends AlertDialog, init it and so on.

What will you suggest, friends?
Click to expand...

@QuickNick : Did you find the solution to above ?
 
You must log in or register to reply here.
Back
Top Bottom