Opinion on multithreaded app design

[Robione]

I'm kind of a hobbyist programmer that has decided to take on a big task. I know there are many ways to satisfy application requirements but because of my hobbyist status I was looking for advice from more experienced coders that have completed bigger projects.

From memory the UI/main thread cannot open sockets. Another thread is needed for that. So from my little experience with the erlang language I liked the idea of modules and message passing. So I approached the design like that.... every module (thread with a particular purpose) has a looper to handle any messages it receives.

i.e. The app is being created. It looks for valid login credentials and if present sends a login message to the network module. The network module processes the response and sends a message to the UI module to do whatever, change activities. (Something so simple probably can be done from the network module but you get the idea.)

Is this approach overkill? I'm not very familiar with android objects. I have done some reading in the developer reference but it's been sporadic and over a decent amount of time. Not everything pops into my mind that might be useful.

(For example if I wrote a game... playing sounds already threaded? So I don't need a sound module? Tried to separate the graphics from the UI thread and could not get it to work. This question and experience has me wondering if the approach is usable... although my current app is a lot simpler (UI and networking).)

Thanks

 

[Deleted User]

Hi and welcome to the forums. There's already something which does exactly what you want and it's called AsyncTask. A class designed to do a task on a separate thread, and allows updating of UI components on the main thread.

https://developer.android.com/reference/android/os/AsyncTask.html
http://www.vogella.com/tutorials/AndroidBackgroundProcessing/article.html#asynctask

 

[Robione]

Thanks for the reply.

I read your links. I probably looked at that in the past.

I read that creating sockets is "expensive." (It's all relative I guess.) So to minimize what I could I thought keeping the connection open would make it easier on the server. (I'm thinking my app might be successful and thousands of connections would be in place simultaneously.) This is where the idea of the module came from. It would have the socket member, set it up, manage the connection, send/receive, etc.

But from your links, if I understood correctly, I could have the socket as a member variable in the UI thread and pass it to doInBackground() to achieve the same behavior?

 

[Deleted User]

Thanks for the reply.

I read your links. I probably looked at that in the past.

I read that creating sockets is "expensive." (It's all relative I guess.) So to minimize what I could I thought keeping the connection open would make it easier on the server. (I'm thinking my app might be successful and thousands of connections would be in place simultaneously.) This is where the idea of the module came from. It would have the socket member, set it up, manage the connection, send/receive, etc.

But from your links, if I understood correctly, I could have the socket as a member variable in the UI thread and pass it to doInBackground() to achieve the same behavior?

You could do that, and yes it would improve the performance of the client app. But I'm not sure that holding thousands of connections open on the server would be a great thing.
Rather than using a direct socket connection, could you consider using a HTTP connection to a web service? Web servers are great at managing simultaneous network connections, it's their primary job.