Re: [android-developers] Which pattern is most common for apps that involve communication with servers?
You know, I don't. My apps aren't open source, and I came up with it myself, not borrowed from a library. But it's not rocket science, I'm sure you understand the pattern. -- K On Friday, February 20, 2015 at 4:39:32 AM UTC+3, Kristopher Micinski wrote: I agree, that sounds like a useful pattern. I *think* that's relatively close to how Volley is implemented (though I haven't read the implementation fully), too. Do you have any pointers to open sourced code that would provide an example of such a behavior? If not, no big deal: I can certainly write one myself, and am not asking you to open-source code from your codebase. Kris On Thu, Feb 19, 2015 at 4:17 PM, Kostya Vasilyev kman...@gmail.com javascript: wrote: A service turned inside out A mediator class that manages a pool of threads, submits / cancels / executes task objects, manages the wake lock (based on having tasks). And a service whose only responsibility is to do startForeground / stopForeground when it's told to. All in the same process. This way I don't have to bind to a service (which is asynchronous) and it's easier to manage state in the UI, to indicate to the user what the app is doing, and to queue up tasks when necessary. -- K -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups Android Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [android-developers] Which pattern is most common for apps that involve communication with servers?
Agreed, thanks for the heads up! Kris On Fri, Feb 20, 2015 at 6:21 AM, Kostya Vasilyev kmans...@gmail.com wrote: You know, I don't. My apps aren't open source, and I came up with it myself, not borrowed from a library. But it's not rocket science, I'm sure you understand the pattern. -- K On Friday, February 20, 2015 at 4:39:32 AM UTC+3, Kristopher Micinski wrote: I agree, that sounds like a useful pattern. I *think* that's relatively close to how Volley is implemented (though I haven't read the implementation fully), too. Do you have any pointers to open sourced code that would provide an example of such a behavior? If not, no big deal: I can certainly write one myself, and am not asking you to open-source code from your codebase. Kris On Thu, Feb 19, 2015 at 4:17 PM, Kostya Vasilyev kman...@gmail.com wrote: A service turned inside out A mediator class that manages a pool of threads, submits / cancels / executes task objects, manages the wake lock (based on having tasks). And a service whose only responsibility is to do startForeground / stopForeground when it's told to. All in the same process. This way I don't have to bind to a service (which is asynchronous) and it's easier to manage state in the UI, to indicate to the user what the app is doing, and to queue up tasks when necessary. -- K -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups Android Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups Android Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [android-developers] Which pattern is most common for apps that involve communication with servers?
Right, that's a good point I did not mention. I'm interested in knowing what percentage of apps use a framework like this rather than facilities purely within the vanilla Android framework. I can do some rough calculations in a while by grabbing a bunch of apps and running some analysis on them, Kris On Thu, Feb 19, 2015 at 3:13 PM, TreKing treking...@gmail.com wrote: On Thu, Feb 19, 2015 at 2:03 PM, Kristopher Micinski krismicin...@gmail.com wrote: I was wondering if there were any other patterns that app developers used that I hadn't thought about, Use a library like Volley or Retrofit. - TreKing - Chicago transit tracking app for Android-powered devices -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups Android Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups Android Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[android-developers] Which pattern is most common for apps that involve communication with servers?
I am trying to get an idea of what most developers use to interact with web services. The two main patterns I see in apps is to either create: - Create an AsyncTask to make restful requests, and then do something with `onPostExecute`, or to - Create a service, and then have some API between the app and the service, perhaps backed by a database. I would suspect that for simple cases, the first thing would suffice, and for more advanced cases, the second might be necessary. I was wondering if there were any other patterns that app developers used that I hadn't thought about, Kris -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups Android Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [android-developers] Which pattern is most common for apps that involve communication with servers?
On Thu, Feb 19, 2015 at 2:03 PM, Kristopher Micinski krismicin...@gmail.com wrote: I was wondering if there were any other patterns that app developers used that I hadn't thought about, Use a library like Volley or Retrofit. - TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups Android Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [android-developers] Which pattern is most common for apps that involve communication with servers?
A service turned inside out A mediator class that manages a pool of threads, submits / cancels / executes task objects, manages the wake lock (based on having tasks). And a service whose only responsibility is to do startForeground / stopForeground when it's told to. All in the same process. This way I don't have to bind to a service (which is asynchronous) and it's easier to manage state in the UI, to indicate to the user what the app is doing, and to queue up tasks when necessary. -- K 2015-02-19 23:30 GMT+03:00 Kristopher Micinski krismicin...@gmail.com: Right, that's a good point I did not mention. I'm interested in knowing what percentage of apps use a framework like this rather than facilities purely within the vanilla Android framework. I can do some rough calculations in a while by grabbing a bunch of apps and running some analysis on them, Kris On Thu, Feb 19, 2015 at 3:13 PM, TreKing treking...@gmail.com wrote: On Thu, Feb 19, 2015 at 2:03 PM, Kristopher Micinski krismicin...@gmail.com wrote: I was wondering if there were any other patterns that app developers used that I hadn't thought about, Use a library like Volley or Retrofit. - TreKing - Chicago transit tracking app for Android-powered devices -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups Android Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [android-developers] Which pattern is most common for apps that involve communication with servers?
I agree, that sounds like a useful pattern. I *think* that's relatively close to how Volley is implemented (though I haven't read the implementation fully), too. Do you have any pointers to open sourced code that would provide an example of such a behavior? If not, no big deal: I can certainly write one myself, and am not asking you to open-source code from your codebase. Kris On Thu, Feb 19, 2015 at 4:17 PM, Kostya Vasilyev kmans...@gmail.com wrote: A service turned inside out A mediator class that manages a pool of threads, submits / cancels / executes task objects, manages the wake lock (based on having tasks). And a service whose only responsibility is to do startForeground / stopForeground when it's told to. All in the same process. This way I don't have to bind to a service (which is asynchronous) and it's easier to manage state in the UI, to indicate to the user what the app is doing, and to queue up tasks when necessary. -- K 2015-02-19 23:30 GMT+03:00 Kristopher Micinski krismicin...@gmail.com: Right, that's a good point I did not mention. I'm interested in knowing what percentage of apps use a framework like this rather than facilities purely within the vanilla Android framework. I can do some rough calculations in a while by grabbing a bunch of apps and running some analysis on them, Kris On Thu, Feb 19, 2015 at 3:13 PM, TreKing treking...@gmail.com wrote: On Thu, Feb 19, 2015 at 2:03 PM, Kristopher Micinski krismicin...@gmail.com wrote: I was wondering if there were any other patterns that app developers used that I hadn't thought about, Use a library like Volley or Retrofit. - TreKing - Chicago transit tracking app for Android-powered devices -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups Android Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups Android Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
