[android-developers] Re: Design for my first android app - Need your suggestions
Is it using an RSS feed or something to get the conversion rates? Because they change all the time. On Tuesday, March 8, 2016 at 6:29:19 AM UTC-5, pruthvi bardolia wrote: > > I have been learning android for few months now, and thought to make an > app which I could ultimately launch in play store. There could not be a > better place to ask for feedback then this group. > > Kindly let me know what you think about the design. Its just a simple app > doing currency converter. > here is the link to my app design image: http://imgur.com/0eSMaFC > -- 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. To post to this group, send email to android-developers@googlegroups.com. Visit this group at https://groups.google.com/group/android-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/android-developers/2e99a537-b9b2-40a2-9296-c235a30e7f10%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[android-developers] Re: Design for my first android app - Need your suggestions
Hey! Looks good! :) I would add an action bar to keep consistency with other apps + menu for Options, to set some defaults if needed (because maybe it is so simple that does not need any options) Regards Andrzej On Tuesday, March 8, 2016 at 12:29:19 PM UTC+1, pruthvi bardolia wrote: > > I have been learning android for few months now, and thought to make an > app which I could ultimately launch in play store. There could not be a > better place to ask for feedback then this group. > > Kindly let me know what you think about the design. Its just a simple app > doing currency converter. > here is the link to my app design image: http://imgur.com/0eSMaFC > -- 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. To post to this group, send email to android-developers@googlegroups.com. Visit this group at https://groups.google.com/group/android-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/android-developers/6bf2a817-d0eb-4e2f-8e14-86d41a98a555%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[android-developers] Re: Design Problem: Client <- CustomeData -> Service
If this is just a data object being shared by two apps, i'd define a base class with the shared information and extend it where needed. If operations are needed as well (or the data structure is different), I'd define an interface of the shared information and use two different implementations of that interface on the client and the service. Also not sure why you want to use CustomData as a member, it makes more sense to extend it. On Thursday, October 17, 2013 1:40:07 PM UTC+3, Richard Zhao wrote: > > It's a special case. Client doesn't have the right to access db. > > On Tuesday, October 15, 2013 3:22:11 PM UTC+8, Jacky.Liu wrote: >> >> Your question make me think of OO database, you can make C/S both >> operate the database. >> Why bother to send the "CustomeData" back and forth . >> >> >> 在 2013年10月14日星期一UTC+8下午3时35分33秒，Richard Zhao写道： >>> >>> Hi there, >>> >>> I'm designing a client / service software. client / service are both on >>> some android. client and service communicate using messenger and data >>> format is class CustomeData. CustomeData also has some inner classes which >>> define detail structure. >>> >>> Do I need to make CustomeData as thin as possible? I intent to use it as >>> data format only recognized by both client and service. Service has >>> additional operations on CustomeData, and may store other info to it too, >>> for example _ID in DB. But client don't care what _ID is. >>> >>> I'm not sure whether I need to attach more operations on CustomeData or >>> create new objects in Service using CustomeData inner classes as a member. >>> >>> Thanks >>> Richard >>> >> -- 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/groups/opt_out.
[android-developers] Re: Design Problem: Client <- CustomeData -> Service
It's a special case. Client doesn't have the right to access db. On Tuesday, October 15, 2013 3:22:11 PM UTC+8, Jacky.Liu wrote: > > Your question make me think of OO database, you can make C/S both operate > the database. > Why bother to send the "CustomeData" back and forth . > > > 在 2013年10月14日星期一UTC+8下午3时35分33秒，Richard Zhao写道： >> >> Hi there, >> >> I'm designing a client / service software. client / service are both on >> some android. client and service communicate using messenger and data >> format is class CustomeData. CustomeData also has some inner classes which >> define detail structure. >> >> Do I need to make CustomeData as thin as possible? I intent to use it as >> data format only recognized by both client and service. Service has >> additional operations on CustomeData, and may store other info to it too, >> for example _ID in DB. But client don't care what _ID is. >> >> I'm not sure whether I need to attach more operations on CustomeData or >> create new objects in Service using CustomeData inner classes as a member. >> >> Thanks >> Richard >> > -- 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/groups/opt_out.
[android-developers] Re: Design Problem: Client <- CustomeData -> Service
Your question make me think of OO database, you can make C/S both operate the database. Why bother to send the "CustomeData" back and forth . 在 2013年10月14日星期一UTC+8下午3时35分33秒，Richard Zhao写道： > > Hi there, > > I'm designing a client / service software. client / service are both on > some android. client and service communicate using messenger and data > format is class CustomeData. CustomeData also has some inner classes which > define detail structure. > > Do I need to make CustomeData as thin as possible? I intent to use it as > data format only recognized by both client and service. Service has > additional operations on CustomeData, and may store other info to it too, > for example _ID in DB. But client don't care what _ID is. > > I'm not sure whether I need to attach more operations on CustomeData or > create new objects in Service using CustomeData inner classes as a member. > > Thanks > Richard > -- 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/groups/opt_out.
[android-developers] Re: Design questions: Menu replacement for ICS (Android 4.x)
I even resorted programatiically popping up the menu on each screen the first time they entered it, just so that they can see the options. On Dec 18, 11:36 am, Nathan wrote: > On Dec 17, 5:55 pm, MB wrote:> Hi, > > > In ICS (Android 4.x), the menu button has been replaced by barely > > noticeable 3 vertical dots making apps that rely on menu button > > difficult to use. > > I just had my first user who couldn't find that, but . . . > > Are you saying that Prior to 4.X, the users *did* know how to get to > the menu? My experience says no. > > Me: Go to the menu. > Them: Menu? > Me: Yes, push the menu button? > Them: Menu Button? > Me: Yes, that thing that looks like four straight lines where the top > one is is bit longer. > Them: I can't see that anywhere on the screen. > Me: No, it's not on the screen, its one of the hardware keys. > Them: Hardware Keys? > Me: Yes, one of those buttons next to a left arrow, a home symbol, and > a magnifying glass. > Them: That? That does something in your app? > > > I would really appreciate if other developers could share how they are > > changing their UI so that there is less reliance on the menu. > > I am thinking of adding an always visible layer of controls at the > > bottom, with an expandable "more" control like in traditional menu. > > I've put more actions on screen through use of the action bar, though > I've had to roll my own action bar for prior to 3.0. > That just means they can do more without the menu, so they are more > likely to use my app for several weeks without knowing the menu > exists. ;) > > I haven't done anything for ICS yet, cause I don't have the hardware > and I can't get the emulator to work in polynomial time. I was hoping > the ActionBar aware menu I made for HoneyComb would scale nicely. . . > > Nathan -- 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
Re: [android-developers] Re: Design questions: Menu replacement for ICS (Android 4.x)
On Dec 18, 2011, at 5:36 AM, Nathan wrote: > Are you saying that Prior to 4.X, the users *did* know how to get to > the menu? My experience says no. Oh, most definitely not. I had some problems familiarizing myself with menu/home/back buttons once I got my first Android phone too. Only pointing out the fact there's no reason to believe physical menu button went anywhere once more ICS phones arrive. -- H -- 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
[android-developers] Re: Design questions: Menu replacement for ICS (Android 4.x)
On Dec 17, 5:55 pm, MB wrote: > Hi, > > In ICS (Android 4.x), the menu button has been replaced by barely > noticeable 3 vertical dots making apps that rely on menu button > difficult to use. > I just had my first user who couldn't find that, but . . . Are you saying that Prior to 4.X, the users *did* know how to get to the menu? My experience says no. Me: Go to the menu. Them: Menu? Me: Yes, push the menu button? Them: Menu Button? Me: Yes, that thing that looks like four straight lines where the top one is is bit longer. Them: I can't see that anywhere on the screen. Me: No, it's not on the screen, its one of the hardware keys. Them: Hardware Keys? Me: Yes, one of those buttons next to a left arrow, a home symbol, and a magnifying glass. Them: That? That does something in your app? > I would really appreciate if other developers could share how they are > changing their UI so that there is less reliance on the menu. > I am thinking of adding an always visible layer of controls at the > bottom, with an expandable "more" control like in traditional menu. > I've put more actions on screen through use of the action bar, though I've had to roll my own action bar for prior to 3.0. That just means they can do more without the menu, so they are more likely to use my app for several weeks without knowing the menu exists. ;) I haven't done anything for ICS yet, cause I don't have the hardware and I can't get the emulator to work in polynomial time. I was hoping the ActionBar aware menu I made for HoneyComb would scale nicely. . . Nathan -- 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
[android-developers] Re: design patterns to develop Android
Hi Marcelo, take a look here: http://www.youtube.com/watch?v=M1ZBjlCRfz0 Cheers Ray On Apr 30, 2:44 am, Marcelo Lima wrote: > Guys, good night! > I wonder if you know some material about design patterns to develop > Android? > I will make a final post-graduate course on the subject. > Thanks > Marcelo -- 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
[android-developers] Re: Design/"flowchart" scheme for Android apps?
what's 'sequential programming'? :P (couldn't resist) I'm guessing that you're looking for a tool to help with documenting your OO architectural/design thoughts? I'd say that any tool capable of handling UML could do that. These come with many price tags, from 0$ to very expensive, and sometimes functionalty reflects this. If you want a drawing tool, take a look at StarUML (free) or Visio (not free). At the other end of the scale you'd find tools like Together, Rational Rose and others. BR Per On 7 Okt., 19:37, DanH wrote: > I'm not looking for a flowcharting tool, but rather something to > design the relationships between Activities, Intents, Providers, etc. > Android isn't a conventional sequential programming environment, and > sequential programming design tools are of little help. > > On Oct 7, 12:15 pm, Bret Foreman wrote: > > > > > I think the Rational toolset (RUP) has a generic tool for creating > > flowcharts for most languages, including Java. That's not free, but it > > would be a good thing to study before recreating the same > > functionality in open source. -- 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
[android-developers] Re: Design/"flowchart" scheme for Android apps?
I'm not looking for a flowcharting tool, but rather something to design the relationships between Activities, Intents, Providers, etc. Android isn't a conventional sequential programming environment, and sequential programming design tools are of little help. On Oct 7, 12:15 pm, Bret Foreman wrote: > I think the Rational toolset (RUP) has a generic tool for creating > flowcharts for most languages, including Java. That's not free, but it > would be a good thing to study before recreating the same > functionality in open source. -- 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
[android-developers] Re: Design/"flowchart" scheme for Android apps?
I think the Rational toolset (RUP) has a generic tool for creating flowcharts for most languages, including Java. That's not free, but it would be a good thing to study before recreating the same functionality in open source. -- 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
[android-developers] Re: Design similar to the home screen on Twitter and Facebook
The 2010 Google I/O app had that dashboard look similar to the Twitter and Facebook apps. Screenshot: http://www.androidcentral.com/official-google-io-android-app-now-available http://code.google.com/p/iosched/source/browse/trunk/res/layout/activity_home.xml I copied that for some of my apps but swapped out "android:onClick" since that doesn't work on 1.5. -seni On Jul 31, 7:40 pm, Chris Stewart wrote: > An application I'm working on has a use for a home screen like the ones in > the Twitter and Facebook Android clients. Something like a 2 by 3 grid view > that adjusts when viewed in either orientation. I'm nothing short of awful > when it comes to design and I've yet to work out a design in my layout that > resembles what I'm after. I'm curious to see if anyone has run across a > tutorial in their time researching across the web. > > Chris Stewart > cstewart...@gmail.comhttp://www.androidsdkforum.com -- 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
[android-developers] Re: Design for Battery Life
On Mar 25, 5:03 pm, Dianne Hackborn wrote: > On Thu, Mar 25, 2010 at 11:31 AM, kec6227 wrote: > > 2) This thought just came to me is that maybe I can use an alarm > > manager to chain broadcasts; I could set an alarm for the first time I > > need, then when that fires, look at the next time I need, and set an > > alarm for that, and so on. > > That is how Calendar works. > > Also you -can- register multiple intents with the alarm manager, just make > sure the intents different in some way as per intent filters, or use > different request codes. Thanks for the response. Is daisy chaining alarms actually better than adding all the alarms I want at once with different request codes? It seems that my app uses far less battery than before, because I switched to method 2 from above. I am not sure if there is actually less battery usage, or if it has just been moved out of my app. - Kenton -- 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 To unsubscribe from this group, send email to android-developers+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
[android-developers] Re: Design guidelines question; Services vs. Intent broadcasts.
Erik Hellman wrote: > Using > intents would require some re-design, which is fine by me but I'm > looking for the drawback of using this from a performance and power- > consumption point-of-view. Do broadcast intents consume more power > than direct service calls? Does sending, receiving and parsing a > broadcast intent take more CPU than a direct service call? If you are creating a music player, playing music will take up much more CPU time and battery life than either communications mechanism, probably by a few orders of magnitude. Personally, I'd focus on other issues, such as usability of whatever third-party interface you're offering. > I know it is a very general question, but I'm assuming there is a > general guideline when to use intents and when to use a service? Not especially. I'm not aware of anyone publishing any sort of performance comparison, and both the AIDL and broadcast Intent stuff is deep enough in the code base as to be difficult to follow for us mere mortals. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://twitter.com/commonsguy _The Busy Coder's Guide to *Advanced* Android Development_ Version 0.9 Available! --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Design guidelines question; Services vs. Intent broadcasts.
On Jul 6, 2:20 pm, Mark Murphy wrote: > If your service is started via bindService(), it will be stopped > sometime after the last client unbinds. > > If your service is started via startService(), it will run into somebody > tells it to stop (stopService(), stopSelf(), Android terminating the > process, gravity and a concrete floor negatively impacting the device). > > If you wish to use AIDL, but still want the service to run even after > unbinding, use both startService() and bindService(). > This is all fine. I have a working example where I use a service and publish an AIDL. However, it doesn't seem like an efficient way of designing my service to allow easy integration from third-party applications (yes, it is a quite rare sort of application). Using intents would require some re-design, which is fine by me but I'm looking for the drawback of using this from a performance and power- consumption point-of-view. Do broadcast intents consume more power than direct service calls? Does sending, receiving and parsing a broadcast intent take more CPU than a direct service call? I know it is a very general question, but I'm assuming there is a general guideline when to use intents and when to use a service? // Erik --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Design guidelines question; Services vs. Intent broadcasts.
On Jul 6, 7:58 pm, Erik Hellman wrote: > On Jul 6, 7:35 pm, Mark Murphy wrote: > > 3. If you use binding to implicitly start your service, Android will > > shut down the service when there is nothing else bound to it. > > ...and I don't want it to shut down because it will keep working even > after the user closes the UI. This is probably relevant for nearly all type of music player-like apps because they need some kind of UI to get started but still need to continue playing once that UI has been exited. Is there a way around this? When you say "implicitly" are you implying that the opposite is true when "explicitly" starting a service? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Design guidelines question; Services vs. Intent broadcasts.
mjc147 wrote: > This is probably relevant for nearly all type of music player-like > apps because they need some kind of UI to get started but still need > to continue playing once that UI has been exited. And that's a fine reason for having a service. However, it's a rare music player that is designed for multiple front-ends, so a local service would be much simpler. > Is there a way around this? When you say "implicitly" are you > implying that the opposite is true when "explicitly" starting a > service? If your service is started via bindService(), it will be stopped sometime after the last client unbinds. If your service is started via startService(), it will run into somebody tells it to stop (stopService(), stopSelf(), Android terminating the process, gravity and a concrete floor negatively impacting the device). If you wish to use AIDL, but still want the service to run even after unbinding, use both startService() and bindService(). -- Mark Murphy (a Commons Guy) http://commonsware.com | http://twitter.com/commonsguy _The Busy Coder's Guide to *Advanced* Android Development_ Version 0.9 Available! --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Design guidelines question; Services vs. Intent broadcasts.
Erik Hellman wrote: > Yes. But that is my question. What is most effective, considering > performance, power-consumption and third-party integration (in that > order); Using a service through AIDL or using Intents (with sticky > broadcasts for service state)? As Mr. Hearn indicated, this question cannot readily be answered in the abstract. Write them both ways and see how you like them. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://twitter.com/commonsguy _The Busy Coder's Guide to *Advanced* Android Development_ Version 0.9 Available! --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Design guidelines question; Services vs. Intent broadcasts.
On Jul 6, 2:01 pm, Mark Murphy wrote: > > Or register a callback AIDL object with the service. > > Or use broadcast intents for the callback-style messaging, though these > are subject to interception. > Yes. But that is my question. What is most effective, considering performance, power-consumption and third-party integration (in that order); Using a service through AIDL or using Intents (with sticky broadcasts for service state)? Security is not an issue at the moment, so we can disregard from that aspect. // Erik --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Design guidelines question; Services vs. Intent broadcasts.
Erik Hellman wrote: >> 1. You actually get return values. >> > The flow of the application is asynchronous, so i would have to poll > the service for updates in that case. Or register a callback AIDL object with the service. Or use broadcast intents for the callback-style messaging, though these are subject to interception. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://twitter.com/commonsguy Android 1.5 Programming Books: http://commonsware.com/books.html --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Design guidelines question; Services vs. Intent broadcasts.
On Jul 6, 1:35 pm, Mark Murphy wrote: > AIDL has a few huge advantages that may or may not be relevant to you: > > 1. You actually get return values. > The flow of the application is asynchronous, so i would have to poll the service for updates in that case. > 2. You don't need your service running to use AIDL -- the bind operation > can auto-start the service if it is not already running. > I already do this. The first UI/Widget that starts will also start the service if it is not already running. > 3. If you use binding to implicitly start your service, Android will > shut down the service when there is nothing else bound to it. > ...and I don't want it to shut down because it will keep working even after the user closes the UI. // Erik --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Design guidelines question; Services vs. Intent broadcasts.
On Jul 6, 1:28 pm, Mike Hearn wrote: > First and most important question - do you really need a service at > all? Many apps use services but don't actually need to run all the > time. Using a service is like a tax on your user. It's currently > invisible but it won't always be that way: expect your users to start > asking questions at some point if/when Android makes resource > consumption of apps more visible. > Yes. I absolutely need a background service since I'm doing something similar to a music player. :) > Now how to sync state between the activities and the services. > > Remember that a service is just an object representing a lifecycle > construct. It exists in the same process that your activities do, so > they can communicate in the same way any two Java objects would > communicate - via direct method calls, for instance. It's perfectly OK > to use the "local service" idiom that is shown in the API samples to > bind to a service and then cast the result to the object itself. Or if > started using an intent, you can just stuff a reference to "this" into > a static field. > > As to using intents, you don't have to do this. You can just keep > track of what the service is meant to do in a file, a database, or > whatever else is convenient. > I agree totally, but my problem is that my service will most likely be used by other applications. There could be three (or more) completely different applications using the service at the same time (a standard UI doing one type of visualization and another app doing a different visualization and a homescreen widget, all in different .apk). So the question remains. If I need to support third-party integration, is a service (published as an AIDL file) better than Intents? And if using Intents, is it better to use sticky intent or should I send very frequent "normal" broadcast intents from the service to signal its state? Thanks, Erik --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Design guidelines question; Services vs. Intent broadcasts.
Beyond agreeing with what Mr. Hearn wrote, a few other points: Erik H wrote: > Also, is really an AIDL the right way to allow third-party > integration? AIDL has a few huge advantages that may or may not be relevant to you: 1. You actually get return values. 2. You don't need your service running to use AIDL -- the bind operation can auto-start the service if it is not already running. 3. If you use binding to implicitly start your service, Android will shut down the service when there is nothing else bound to it. The combination of #2 and #3 means that I hope you can avoid the always-running service pattern. Use AIDL. If your service needs to do some work on occasion independent of any activity, use AlarmManager and WakeLocks to schedule the startup and execution of that work. After all, you're going to need them anyway, since phones go to sleep, so you may as well minimize your footprint as part of the bargain. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://twitter.com/commonsguy Android 1.5 Programming Books: http://commonsware.com/books.html --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Design guidelines question; Services vs. Intent broadcasts.
It's a bit hard to say what design is right without details on what the service actually does. First and most important question - do you really need a service at all? Many apps use services but don't actually need to run all the time. Using a service is like a tax on your user. It's currently invisible but it won't always be that way: expect your users to start asking questions at some point if/when Android makes resource consumption of apps more visible. Most of the time when people are using a permanently running service, what they really want is a service that handles inexactly repeating alarms. Now how to sync state between the activities and the services. Remember that a service is just an object representing a lifecycle construct. It exists in the same process that your activities do, so they can communicate in the same way any two Java objects would communicate - via direct method calls, for instance. It's perfectly OK to use the "local service" idiom that is shown in the API samples to bind to a service and then cast the result to the object itself. Or if started using an intent, you can just stuff a reference to "this" into a static field. As to using intents, you don't have to do this. You can just keep track of what the service is meant to do in a file, a database, or whatever else is convenient. But again, really consider whether you need an always-running service. Very few apps actually need this (things like music players being the obvious exception). --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Design
> Here is where my questions arose: Is there a way to find a suitable > "happy medium" without trial and error testing on a huge database? Profiling with real data is the right way to optimize in a perfect world. If that is unworkable here in this world, then you'll have to get out the slide rule and estimate how long various tasks will take, and more importantly which task has the largest impact on the user experience, such as responsiveness. Then optimize that one. > - Load and decompress in a non-UI thread: I understand what you mean, > and also sense this might be a good solution. Though, I do not have > any idea how to begin with this. Links to any guidelines would be > appreciated. There are various ways to do this. The cleanest way in my not particularly humble opinion would be to implement an Android Service: http://developer.android.com/reference/android/app/Service.html This service would be the one that talks with the server and provides the processed data to/from the UI. Yusuf Saib Android ·T· · ·Mobile· stick together The views, opinions and statements in this email are those of the author solely in their individual capacity, and do not necessarily represent those of T-Mobile USA, Inc. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Design
One possibility is to do it as the Market app (or also the Bing search engine for images) You first download a number of elements, and as soon as the user scrolls down to a certain point, you download more items and add them dynamically to the list. Peli www.openintents.org On Jun 24, 10:55 pm, Andy_Sthml wrote: > Thanks for good thoughts! What I did not explain was that my idea is > to eventually publish my app. Then servers of other users will be > returning data to the app - and possibly returning much more data > (list items). I do not have access to a "huge" worst-case data-source > and I do not know how to simulate one. > > Here is where my questions arose: Is there a way to find a suitable > "happy medium" without trial and error testing on a huge database? > > Some reflections on your ideas: > > - Prefetch and cache: It would be perfectly ok for the user to wait a > few secs for "loading" at application startup. I have been thinking > about reading the complete data from the server, and filling a > background array of custom data-objects with it. Then the listView > could be fed and filled from the background array independently of > what the user-selection might be (different content depending on > selection). However, I get back to the same question: How do I know > there is enough memory to hold the complete background array, and if > not - what the "happy medium" is? > > - Reusing: If only enough items for one display is loaded (added to > the ArrayAdapter) - won't this then interrupt the nice sliding feel / > momentum feel of the scrolling listview? > > - XML: No plans for XML, however, the data returned by the server is a > huge long URL-encoded text string, So after parsing out the single > elemnts with String-methods, I am currently using the URLDecoder-class > and the decode-method to get the pretty-printed strings out. I do not > see a way around this. > > - Load and decompress in a non-UI thread: I understand what you mean, > and also sense this might be a good solution. Though, I do not have > any idea how to begin with this. Links to any guidelines would be > appreciated. > > Thanks! /Andy > > On 24 Juni, 19:33, "Yusuf T. Mobile" wrote: > > > Hi Andy. Some ideas are: > > - implement the simplest design first (i.e., load everything into > > memory) and profile early and often > > - iff (if and only if) and wherre (where and only where - I made that > > one up:) it croaks, some possible optimizations are: > > - don't put thousands of items on one list. Sublists may be an > > alternative. > > - prefetch and cache data - especially the images, rather than > > loading them real-time from URLs. Loading everything is in theory the > > most efficient, but may make the user wait at first, which ruins > > responsiveness. Depending on the data characterization and use cases, > > you will have to find a happy medium. > > - reuse objects rather than incur the cost of memory allocation > > and GC. For example, if you have a custom list item class, only create > > as many as are needed to display on the screen, and update their data > > as the user scrolls up and down, rather than creating lots of new ones > > and abandoning old ones as the user scrolls. > > - don't use XML, it has many advantages, but bandwidth and parsing > > efficiency are not among them. Use a streaming (rather than tree) > > parser, with a compressed protocol. Google's protobuf may be an > > option. > > - load and decompress in a non-UI thread. You don't have to wait > > until everything is loaded and decompressed to show something, you can > > do so selectively depending on what the user is looking at and may > > soon be looking at. > > > Yusuf Saib > > Android > > ·T· · ·Mobile· stick together > > The views, opinions and statements in this email are those of the > > author solely in their individual capacity, and do not necessarily > > represent those of T-Mobile USA, Inc. > > > On Jun 23, 2:06 pm, Andy_Sthml wrote: > > > > This is mainly a design question : > > > > My app connects to a server from where data is retrieved and presented > > > in a listview. Depending on user-selection different data is retreived > > > and filled in the list. A typical list item consists of a text string > > > of up to some 50 or 60 characters depending what the server returns. > > > Additionally, a small image icon is shown next to each string. The > > > server may return any number of items from 0 up to many hundred or > > > even thousands. It is possble to ask the server to iteratively return > > > subsets of the content. The images are actually links to http- > > > addresses, but I guess this still requires/allocates memory for the > > > listview by Android. > > > > How do I design for efficiency and responsiveness, considering memory > > > consumption? > > > Are there any generic guide lines on how many list items, Strings or > > > Bytes to keep in memory? > > > > On the one hand I would like to have as many items
[android-developers] Re: Design
Thanks for good thoughts! What I did not explain was that my idea is to eventually publish my app. Then servers of other users will be returning data to the app - and possibly returning much more data (list items). I do not have access to a "huge" worst-case data-source and I do not know how to simulate one. Here is where my questions arose: Is there a way to find a suitable "happy medium" without trial and error testing on a huge database? Some reflections on your ideas: - Prefetch and cache: It would be perfectly ok for the user to wait a few secs for "loading" at application startup. I have been thinking about reading the complete data from the server, and filling a background array of custom data-objects with it. Then the listView could be fed and filled from the background array independently of what the user-selection might be (different content depending on selection). However, I get back to the same question: How do I know there is enough memory to hold the complete background array, and if not - what the "happy medium" is? - Reusing: If only enough items for one display is loaded (added to the ArrayAdapter) - won't this then interrupt the nice sliding feel / momentum feel of the scrolling listview? - XML: No plans for XML, however, the data returned by the server is a huge long URL-encoded text string, So after parsing out the single elemnts with String-methods, I am currently using the URLDecoder-class and the decode-method to get the pretty-printed strings out. I do not see a way around this. - Load and decompress in a non-UI thread: I understand what you mean, and also sense this might be a good solution. Though, I do not have any idea how to begin with this. Links to any guidelines would be appreciated. Thanks! /Andy On 24 Juni, 19:33, "Yusuf T. Mobile" wrote: > Hi Andy. Some ideas are: > - implement the simplest design first (i.e., load everything into > memory) and profile early and often > - iff (if and only if) and wherre (where and only where - I made that > one up:) it croaks, some possible optimizations are: > - don't put thousands of items on one list. Sublists may be an > alternative. > - prefetch and cache data - especially the images, rather than > loading them real-time from URLs. Loading everything is in theory the > most efficient, but may make the user wait at first, which ruins > responsiveness. Depending on the data characterization and use cases, > you will have to find a happy medium. > - reuse objects rather than incur the cost of memory allocation > and GC. For example, if you have a custom list item class, only create > as many as are needed to display on the screen, and update their data > as the user scrolls up and down, rather than creating lots of new ones > and abandoning old ones as the user scrolls. > - don't use XML, it has many advantages, but bandwidth and parsing > efficiency are not among them. Use a streaming (rather than tree) > parser, with a compressed protocol. Google's protobuf may be an > option. > - load and decompress in a non-UI thread. You don't have to wait > until everything is loaded and decompressed to show something, you can > do so selectively depending on what the user is looking at and may > soon be looking at. > > Yusuf Saib > Android > ·T· · ·Mobile· stick together > The views, opinions and statements in this email are those of the > author solely in their individual capacity, and do not necessarily > represent those of T-Mobile USA, Inc. > > On Jun 23, 2:06 pm, Andy_Sthml wrote: > > > > > This is mainly a design question : > > > My app connects to a server from where data is retrieved and presented > > in a listview. Depending on user-selection different data is retreived > > and filled in the list. A typical list item consists of a text string > > of up to some 50 or 60 characters depending what the server returns. > > Additionally, a small image icon is shown next to each string. The > > server may return any number of items from 0 up to many hundred or > > even thousands. It is possble to ask the server to iteratively return > > subsets of the content. The images are actually links to http- > > addresses, but I guess this still requires/allocates memory for the > > listview by Android. > > > How do I design for efficiency and responsiveness, considering memory > > consumption? > > Are there any generic guide lines on how many list items, Strings or > > Bytes to keep in memory? > > > On the one hand I would like to have as many items in the list as > > possible - from a users perspective *all* items returned from the > > server would be expected. On the other, sending many queries to the > > server makes the app slower. I am not sure how to handle this > > situation since I do not have a feel for what android can handle in > > terms of memory. > > > Any ideas would be of help.- Dölj citerad text - > > - Visa citerad text - --~--~-~--~~~---~--~~ You received this message bec
[android-developers] Re: Design
Hi Andy. Some ideas are: - implement the simplest design first (i.e., load everything into memory) and profile early and often - iff (if and only if) and wherre (where and only where - I made that one up:) it croaks, some possible optimizations are: - don't put thousands of items on one list. Sublists may be an alternative. - prefetch and cache data - especially the images, rather than loading them real-time from URLs. Loading everything is in theory the most efficient, but may make the user wait at first, which ruins responsiveness. Depending on the data characterization and use cases, you will have to find a happy medium. - reuse objects rather than incur the cost of memory allocation and GC. For example, if you have a custom list item class, only create as many as are needed to display on the screen, and update their data as the user scrolls up and down, rather than creating lots of new ones and abandoning old ones as the user scrolls. - don't use XML, it has many advantages, but bandwidth and parsing efficiency are not among them. Use a streaming (rather than tree) parser, with a compressed protocol. Google's protobuf may be an option. - load and decompress in a non-UI thread. You don't have to wait until everything is loaded and decompressed to show something, you can do so selectively depending on what the user is looking at and may soon be looking at. Yusuf Saib Android ·T· · ·Mobile· stick together The views, opinions and statements in this email are those of the author solely in their individual capacity, and do not necessarily represent those of T-Mobile USA, Inc. On Jun 23, 2:06 pm, Andy_Sthml wrote: > This is mainly a design question : > > My app connects to a server from where data is retrieved and presented > in a listview. Depending on user-selection different data is retreived > and filled in the list. A typical list item consists of a text string > of up to some 50 or 60 characters depending what the server returns. > Additionally, a small image icon is shown next to each string. The > server may return any number of items from 0 up to many hundred or > even thousands. It is possble to ask the server to iteratively return > subsets of the content. The images are actually links to http- > addresses, but I guess this still requires/allocates memory for the > listview by Android. > > How do I design for efficiency and responsiveness, considering memory > consumption? > Are there any generic guide lines on how many list items, Strings or > Bytes to keep in memory? > > On the one hand I would like to have as many items in the list as > possible - from a users perspective *all* items returned from the > server would be expected. On the other, sending many queries to the > server makes the app slower. I am not sure how to handle this > situation since I do not have a feel for what android can handle in > terms of memory. > > Any ideas would be of help. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: design Q: persisting activity state
It is perfectly fine to persist state in storage (via SharedPreferences, flat files, databases, etc). There are some things you will almost certainly want to store in onSaveInstanceState() (such as the current position in the list... well the framework does that for you already), and some things always go in persistent storage (such as the current preferences set by the user), and then a big gray area of things that you may handle one or the other way, depending on the behavior you want (either associated with that "instance" of the activity, or retained across launches). On Thu, Apr 30, 2009 at 11:02 AM, Eric Hackborn EH wrote: > > I have a simple app that has three windows, each with a corresponding > activity. It's very common to switch back and forth between activities, > but of course state gets wiped out of the top-most activity when the > user has finished with it, and I want that state to persist. So I have > two questions: > > 1. Currently, I'm persisting the state by saving it to the MODE_PRIVATE > SharedPreferences in onStop(), then restoring it in onCreate(). > Is this acceptable, or is there a better way to handle it? > > 2. If it is acceptable, a side effect is that the state now persists > between app invocations. Personally I like this, but I haven't > seen any guidelines for Android on whether minor settings > should persist past the life of the app. Is this a good practice > for Android or not? > > thanks, > eric > > > > -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
