0

I'm currently developing an app for my Computing project. To put it simply, it gathers information via an SSH session from a computer and displays the CPU usage etc.

I've been wanting to add the ability to have multiple connections in the app itself, However i want it to be set up so that the user can add/remove connection whenever they like and switch between them. I would like to have it set up so all of the connections can be active at once (Probably a maximum of 8) so that background monitoring can be done.

I'm not sure how I could go about making my app "modular" like this. Any ideas would be great! :D I have it set up with 1 connection working fine for now, Having multiple connections would add a lot more use to my app.

If you'd like to take a look at my code, I have a copy of it on GitHub. It's an older version of it but the code is mostly the same. My ssh class

Thanks people!

Adam Price
  • 15
  • 5
  • I'm not sure if this ranks as "Unclear what you're asking" or "too broad", but one of those for sure. – wvdz Mar 10 '15 at 20:02

1 Answers1

1

Sort version: Use queues to connect threads.

You have, say, 9 input streams. 8 from SSH sources and one from your user. The common approach for this is to use threads. (there is probably another approach with java channels, java.nio.channels, which have callbacks). Each stream needs to have input and output independently of what is happening on the others. So, you need some sort of message queue feeding into and out of each stream. That way the rest of the app can go happily along despite a stream being blocked.

The Android UI is, like most UI frameworks, "single-threaded". When UI frameworks say they are "single-threaded" they mean one thread is used for all UI interaction in your app. So, you need a way to message between your threads which do your SSH and your one thread which does your UI. In Android you can post messages onto the UI thread. Another approach would be to do a local broadcast within the app and have listeners where needed. Yet another approach would be to use a message bug framework like Otto which is a global space in your app where each activity, or fragment, etc registers itself to get messages.

In your case, for now, I'd just fire off some Java threads and then call "post" to post the message back into some View.

The typical UI "thread" is some loop which gets UI input and calls the program code. In Android, its called the "looper". Here's an article of one way: https://developer.android.com/training/multiple-threads/communicate-ui.html and here a more general discussion article: http://www.intertech.com/Blog/android-non-ui-to-ui-thread-communications-part-1-of-5/

You might also simply want to use "runOnUIThread" to run whatever code messes with the UI. But, the local broadcast works nicely too.

Along this lines, Queues are the classic approach to integrating with ridiculous old tech like mainframes which do stupid designs like nightly batches instead of immediate processing.

TimJowers2
  • 208
  • 2
  • 10