Android Architecture - How to handle multiple device services in background?









up vote
0
down vote

favorite












Before you hit the wall of text below, my main question is: What is a better way to structure this application?



In theory my app is kind of simple. I set up a VPN using a Bluetooth device or a USB device. USB takes precedence if both devices are available. The UI only displays availability and connected state of each device (as well as an event/debug log). This app will almost always run in the background.



I am new to Android AND Java so I've had some difficulty learning the nuances. But I have done a lot of reading and experimentation. Right now, my MainActivity holds the logic for managing custom USB and BT services that extend VpnService and this works pretty well. But I do have some issues related to the life-cycle of Activities and Services - mainly, I am having trouble handling ALL of the use cases which has led to robustness issues as I pair/connect/disconnect the BT/USB devices.



I am considering re-writing this application but can't think of a way to ensure I won't have the same issues. I have a pretty good handle on the life-cycle of Activity and Service components - so I was thinking that the app would be better structure if I moved the control-logic out of the UI activity into a persistent service that controls the USB and BT services. But I am struggling with making a decision on how to handle the various asynchronous device events that may occur while I am trying to handle blocking/async operations. The prime example here is when I am trying to connect to the (already paired) Bluetooth device and the USB device is attached. I need to make sure that the BT connect finishes, if it succeeds then I need to disconnect it (and wait for that to finish), then connect the USB device and start the VPN. Due to the unpredictability of the BT connect, I'd also like to be able to have a timeout on operations so that I can cancel them if they take longer than they should. Most of my attempts at this kind of functionality don't seem to work. I think that the events (intents) I am trying to send are blocked until operations finish.



So, hopefully you're still with me.. How would you structure this app? I have a lot of intent-filters (USB/BT device events) to manage and I need to carefully control the order of operations - letting each operation finish, check its result, and then figure out what to do next based on ALL events that have occurred up to the time that the decision is being made.



Thanks,
Stauff4










share|improve this question

























    up vote
    0
    down vote

    favorite












    Before you hit the wall of text below, my main question is: What is a better way to structure this application?



    In theory my app is kind of simple. I set up a VPN using a Bluetooth device or a USB device. USB takes precedence if both devices are available. The UI only displays availability and connected state of each device (as well as an event/debug log). This app will almost always run in the background.



    I am new to Android AND Java so I've had some difficulty learning the nuances. But I have done a lot of reading and experimentation. Right now, my MainActivity holds the logic for managing custom USB and BT services that extend VpnService and this works pretty well. But I do have some issues related to the life-cycle of Activities and Services - mainly, I am having trouble handling ALL of the use cases which has led to robustness issues as I pair/connect/disconnect the BT/USB devices.



    I am considering re-writing this application but can't think of a way to ensure I won't have the same issues. I have a pretty good handle on the life-cycle of Activity and Service components - so I was thinking that the app would be better structure if I moved the control-logic out of the UI activity into a persistent service that controls the USB and BT services. But I am struggling with making a decision on how to handle the various asynchronous device events that may occur while I am trying to handle blocking/async operations. The prime example here is when I am trying to connect to the (already paired) Bluetooth device and the USB device is attached. I need to make sure that the BT connect finishes, if it succeeds then I need to disconnect it (and wait for that to finish), then connect the USB device and start the VPN. Due to the unpredictability of the BT connect, I'd also like to be able to have a timeout on operations so that I can cancel them if they take longer than they should. Most of my attempts at this kind of functionality don't seem to work. I think that the events (intents) I am trying to send are blocked until operations finish.



    So, hopefully you're still with me.. How would you structure this app? I have a lot of intent-filters (USB/BT device events) to manage and I need to carefully control the order of operations - letting each operation finish, check its result, and then figure out what to do next based on ALL events that have occurred up to the time that the decision is being made.



    Thanks,
    Stauff4










    share|improve this question























      up vote
      0
      down vote

      favorite









      up vote
      0
      down vote

      favorite











      Before you hit the wall of text below, my main question is: What is a better way to structure this application?



      In theory my app is kind of simple. I set up a VPN using a Bluetooth device or a USB device. USB takes precedence if both devices are available. The UI only displays availability and connected state of each device (as well as an event/debug log). This app will almost always run in the background.



      I am new to Android AND Java so I've had some difficulty learning the nuances. But I have done a lot of reading and experimentation. Right now, my MainActivity holds the logic for managing custom USB and BT services that extend VpnService and this works pretty well. But I do have some issues related to the life-cycle of Activities and Services - mainly, I am having trouble handling ALL of the use cases which has led to robustness issues as I pair/connect/disconnect the BT/USB devices.



      I am considering re-writing this application but can't think of a way to ensure I won't have the same issues. I have a pretty good handle on the life-cycle of Activity and Service components - so I was thinking that the app would be better structure if I moved the control-logic out of the UI activity into a persistent service that controls the USB and BT services. But I am struggling with making a decision on how to handle the various asynchronous device events that may occur while I am trying to handle blocking/async operations. The prime example here is when I am trying to connect to the (already paired) Bluetooth device and the USB device is attached. I need to make sure that the BT connect finishes, if it succeeds then I need to disconnect it (and wait for that to finish), then connect the USB device and start the VPN. Due to the unpredictability of the BT connect, I'd also like to be able to have a timeout on operations so that I can cancel them if they take longer than they should. Most of my attempts at this kind of functionality don't seem to work. I think that the events (intents) I am trying to send are blocked until operations finish.



      So, hopefully you're still with me.. How would you structure this app? I have a lot of intent-filters (USB/BT device events) to manage and I need to carefully control the order of operations - letting each operation finish, check its result, and then figure out what to do next based on ALL events that have occurred up to the time that the decision is being made.



      Thanks,
      Stauff4










      share|improve this question













      Before you hit the wall of text below, my main question is: What is a better way to structure this application?



      In theory my app is kind of simple. I set up a VPN using a Bluetooth device or a USB device. USB takes precedence if both devices are available. The UI only displays availability and connected state of each device (as well as an event/debug log). This app will almost always run in the background.



      I am new to Android AND Java so I've had some difficulty learning the nuances. But I have done a lot of reading and experimentation. Right now, my MainActivity holds the logic for managing custom USB and BT services that extend VpnService and this works pretty well. But I do have some issues related to the life-cycle of Activities and Services - mainly, I am having trouble handling ALL of the use cases which has led to robustness issues as I pair/connect/disconnect the BT/USB devices.



      I am considering re-writing this application but can't think of a way to ensure I won't have the same issues. I have a pretty good handle on the life-cycle of Activity and Service components - so I was thinking that the app would be better structure if I moved the control-logic out of the UI activity into a persistent service that controls the USB and BT services. But I am struggling with making a decision on how to handle the various asynchronous device events that may occur while I am trying to handle blocking/async operations. The prime example here is when I am trying to connect to the (already paired) Bluetooth device and the USB device is attached. I need to make sure that the BT connect finishes, if it succeeds then I need to disconnect it (and wait for that to finish), then connect the USB device and start the VPN. Due to the unpredictability of the BT connect, I'd also like to be able to have a timeout on operations so that I can cancel them if they take longer than they should. Most of my attempts at this kind of functionality don't seem to work. I think that the events (intents) I am trying to send are blocked until operations finish.



      So, hopefully you're still with me.. How would you structure this app? I have a lot of intent-filters (USB/BT device events) to manage and I need to carefully control the order of operations - letting each operation finish, check its result, and then figure out what to do next based on ALL events that have occurred up to the time that the decision is being made.



      Thanks,
      Stauff4







      android service bluetooth architecture usb






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Nov 9 at 20:22









      Luke Stauffer

      11




      11



























          active

          oldest

          votes











          Your Answer






          StackExchange.ifUsing("editor", function ()
          StackExchange.using("externalEditor", function ()
          StackExchange.using("snippets", function ()
          StackExchange.snippets.init();
          );
          );
          , "code-snippets");

          StackExchange.ready(function()
          var channelOptions =
          tags: "".split(" "),
          id: "1"
          ;
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function()
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled)
          StackExchange.using("snippets", function()
          createEditor();
          );

          else
          createEditor();

          );

          function createEditor()
          StackExchange.prepareEditor(
          heartbeatType: 'answer',
          convertImagesToLinks: true,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: 10,
          bindNavPrevention: true,
          postfix: "",
          imageUploader:
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          ,
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          );



          );













           

          draft saved


          draft discarded


















          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53232802%2fandroid-architecture-how-to-handle-multiple-device-services-in-background%23new-answer', 'question_page');

          );

          Post as a guest















          Required, but never shown






























          active

          oldest

          votes













          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes















           

          draft saved


          draft discarded















































           


          draft saved


          draft discarded














          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53232802%2fandroid-architecture-how-to-handle-multiple-device-services-in-background%23new-answer', 'question_page');

          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          Kleinkühnau

          Makov (Slowakei)

          Deutsches Schauspielhaus