**** BEGIN LOGGING AT Thu Jan 08 02:59:57 2009 Jan 08 04:29:51 argh, stupid android won't build anymore. what's the deal. Jan 08 05:42:00 does that "More" icon automatically appear after you have 6 or more menu items? Jan 08 05:51:01 jasta: yes Jan 08 05:51:31 damn, i was hoping to get it to appear as the 5th item Jan 08 05:51:48 may be add an empty menu item Jan 08 05:51:52 i wonder if it will be intelligent about item groups if the first group has only 5 Jan 08 05:51:59 eww, no. that would be terrible. Jan 08 05:52:23 i found menu's are a bit rigid as of 1.0 Jan 08 05:59:43 i thought of a menu item to add for the 5th one Jan 08 06:00:06 "Empty"? ;) Jan 08 06:00:48 except now i'm confused about checkable items. i had assumed they were like those ones in the phone app Jan 08 06:00:51 but they appear not to be Jan 08 06:03:05 yeah, the menu's are weird Jan 08 06:03:32 you can't even choose an menu icon Jan 08 06:04:15 hmm.. not the icon Jan 08 06:04:27 i mean you can't customize what gets displayed as a menu item Jan 08 06:08:05 you shouldnt be able to. if you want to, your UI design skills need work :) Jan 08 06:09:10 heh Jan 08 06:09:56 jasta: one of the built in apps does it Jan 08 06:10:06 what ya say bout dat? Jan 08 06:11:00 may be even t-mo apps do it.. check with your t-mo android designer. bwahahahha Jan 08 10:36:17 . Jan 08 13:24:00 * eldenz just spotted GridView.AUTO_FIT : D Jan 08 13:24:38 who was that asking about floating items Jan 08 13:45:48 hi Jan 08 13:46:07 eldenz: I need to have a floating screen, if you're offering tips and hints ;-) Jan 08 13:49:40 gcinzh, mahGrid.setColumnWidth(160); mahGrid.setNumColumns(GridView.AUTO_FIT); Jan 08 13:50:03 thanks Jan 08 13:50:06 will automatically use 2 in portrait and 3 in landscape (i.e., if width is 320 or 480 respectively) Jan 08 13:50:17 * gcinzh sees eldenz is in Switzerland too! Jan 08 13:50:56 \ð/ Jan 08 14:06:35 eldenz: written much Android-specific stuff yet ? Jan 08 14:07:26 a few small things and currently working on something slightly bigger :) Jan 08 14:08:06 but i have too many ideas and not enough time :| Jan 08 14:08:22 what's your day job - Java stufF? Jan 08 14:08:56 no i'm a student Jan 08 14:09:04 ah ok Jan 08 14:09:10 you live in the java world? ;) Jan 08 14:10:04 Nope, but trying my hand at writing something and learning as I go ;) Jan 08 15:15:30 jsharkey, I think I have a clue about the problem with downloading packages sometimes, which fail to install. Jan 08 15:17:30 Occassionally, the downloaded file is also gzipped. I think that the downloader looks for files with the same or similar name on the sdcard, and automatically renames the file. I suspect that the downloader expects to take the original file and "gunzip" it once the download is complete (which is braindead, but I'm only guessing here anyway). Jan 08 15:18:03 If the original name doesn't exist, nothing is changed, even though the new file is in the wrong format. Jan 08 15:19:42 In any case, my speculation aside: GZIPed files aren't detected at the downloader or the installer. The unpacker doesn't understand them either, so getting the Manifest fails, et c. Jan 08 15:20:32 I'm sure the web server gzips the stream. That may be the right workaround -- disabling that on the server. Jan 08 15:45:17 michaelnovakjr: http://code.google.com/p/android/issues/detail?id=1732 Jan 08 15:45:34 michaelnovakjr: I have something working now. I documented it. Thanks again for you help. Jan 08 15:45:55 I strongly urge all developers using the android.database.sqlite.SQLiteOpenHelper class to review this report. Jan 08 15:46:54 excellent, yea... it could be problematic for developers if only half the tables get created for some reason Jan 08 15:52:25 michaelnovakjr: looking at my recommended implementation results in, "well of course", but the documentation and readily available example (notepad) fails to convey the importance of proper implementation strategy. As a new comer it caught me off guard as it's not entirely clear which burdens the helper class carries on our behalf (which isn't much). And had I not had an unrelated bug which got me looking here, I would of had a horrible Jan 08 15:52:25 bug lying in wait. I suspect others do as well. Jan 08 15:53:09 exactly, i'm sure a few of my apps have it Jan 08 15:53:27 goode morning Jan 08 15:53:33 morning Jan 08 15:54:20 im back but this time i think im a little bit on track still need help though Jan 08 15:54:25 BlindOracle, Jan 08 15:54:38 BlindOracle, olla Jan 08 15:55:20 ?como esta? Jan 08 15:55:48 can some one tell me how to apply this http://developerlife.com/tutorials/?p=369 Jan 08 15:55:58 BlindOracle, no esp Jan 08 15:57:30 akuma55: I'm sorry, I don't have time to teach java 101. I strongly urge to you learn Java first. And, poke around on anddev.org. You've find various intro tutorials for beginners to both java and android. Jan 08 15:57:37 ^^ Jan 08 15:58:34 sorry again then for the loose of time :( Jan 08 15:59:14 akuma55: anddev.org is an excellent resource. Spend a couple of days reading there and you'll get a leg up. Jan 08 16:02:26 I updates someone else's bug report, but I fear it won't get attention. In any case, that adds a repeatable example of the http-downloaded-package bug. http://code.google.com/p/android/issues/detail?id=1085 Jan 08 16:09:11 CardinalFang: I just saw your new information. Good data. I'm puzzled about the reason why files don't always get unzipped (small size, maybe, which would make some gzip-detection fail in the http stack). Jan 08 16:10:39 jbq: got the 5D MkII :) Jan 08 16:11:03 romainguy: heh. put the new firmware in? Jan 08 16:11:19 I did Jan 08 16:25:55 I need helping making an intent filter in the manifest that matches currectly to an intent Jan 08 16:26:22 what's the intent? Jan 08 16:26:43 here is an example one using digg Jan 08 16:26:44 Intent { action=android.intent.action.VIEW data=http://feeds.digg.com/digg/popular.rss type=application/rss+xml } Jan 08 16:27:06 the code is calling intent.setDataAndType(Uri, mimeType) Jan 08 16:28:23 you should be able to handle that action and type Jan 08 16:29:36 ok here is my intent filter Jan 08 16:29:37 http://pastebin.com/m774c6c83 Jan 08 16:30:03 i'm missing the actual URI in this intent filter which is probably the problem. But where would that go? Jan 08 16:30:18 there is a path attribute for intent filters. Does path = URI Jan 08 16:31:45 http://pastebin.com/m7471a981 Jan 08 16:32:09 not sure though Jan 08 16:32:38 jbq, I'd expect size-detection to be in a web server, but not in a client. The client shouldn't even need to sniff it -- the HTTP headers should say what it's delivering. Jan 08 16:32:46 let me try that Jan 08 16:34:14 the reason i have the default category however was because the code that i'm trying to match the intent with is not a startActivity. Instead its this: packageManager. queryIntentActivities(intent, PackageManager.MATCH_DEFAULT_ONLY) Jan 08 16:35:16 Can someone tell me why we have to use "values-en-rUS" for the US value folder ? Jan 08 16:35:24 and not "values-en-US" Jan 08 16:35:30 what means the "r" Jan 08 16:35:36 Region. Jan 08 16:35:41 ah thanks Jan 08 16:35:57 different values for different regions? really? Jan 08 16:36:14 Yeah you have the possibility for it Jan 08 16:36:22 It's languages you're matching. We can only describe them as LL and LL-CC, language and country. Jan 08 16:36:23 I guess that makes sense if you have some sorta regionalized server Jan 08 16:37:11 zhobbs_: Brilliant! Thank you! Jan 08 16:37:27 zhobbs_: Worked perfectly. That is exactly what I needed to tie webkit to my app :) Jan 08 16:37:30 famast: cool, surprised it actually worked :) Jan 08 16:37:38 zhobbs_: Me too! Jan 08 16:40:09 anno^da_, ISO 639-1 and ISO 3166-1 Jan 08 16:41:54 anno^da_, http://tools.ietf.org/html/rfc4646 Jan 08 16:46:10 romainguy, meh, I'm still using my good old 350D :) Jan 08 17:11:27 What's a good way to get a uniq id for each user/phone without requiring more permissions? Is there a serial number available? Jan 08 17:36:44 I sure wish I could get more info about MediaPlayer's buffer.... Jan 08 17:37:41 a percentage as an int isn't that useful....I'd really like to get the exact position in the stream that is being played (byte) Jan 08 17:38:24 doesn't it tell you the time? Jan 08 17:38:31 not byte position but you do get time... Jan 08 17:38:36 maybe not for streams hmm Jan 08 17:38:43 yeah, you can get the time Jan 08 17:39:04 having a hard time translating that into the exact spot in the stream Jan 08 17:39:52 could you feed the media player a specific amount of bytes and have it call the onFinished (orOnComplete whatever it is) when its done playing those bytes? Jan 08 17:40:08 then you would know exactly how many, of course only when its done playing them Jan 08 17:40:09 yeah Jan 08 17:40:23 that's true...would just cause a skipping effect Jan 08 17:40:39 its not a bug its a feature Jan 08 17:40:49 :) Jan 08 17:59:49 zhobbs_: the joys of MediaPlayer :( Jan 08 18:01:34 jt436: yep...it needs to be a bit more flexible...finally got a local http server working so I can play shoutcast Jan 08 18:13:20 olá a todos, alguem ai tem vontade em ajudar a construir um site para ajudar a comunidade Android? Jan 08 18:13:27 tenho o dominio android-br.com Jan 08 18:13:51 brummbrumm Jan 08 18:14:47 ? Jan 08 18:28:13 zhobbs_: the MediaPlayer is such a piece of junk ;) Jan 08 18:30:20 wonder if there will be any MediaPlayer api changes coming with cupcake or 1.1 or whatever the next release is Jan 08 18:31:11 i already looked; there are not. Jan 08 18:31:28 though they claim there are numerous bug fixes, it's hard to identify where they are considering we just got one big dump of code and no git history Jan 08 18:45:30 Can someone recommend me a 22" or 24" TFT display? (no TN panel and not for gaming) Jan 08 18:45:50 whatever's on sale at Dell? Jan 08 18:45:54 * ctate ducks. Jan 08 18:46:00 ctate: +1 Jan 08 18:46:10 Well ok :-). That would be easy. *g* Jan 08 18:46:11 (seriously, that's how i bought my monitor) Jan 08 18:46:27 the quality is fine and the prices can be quite good Jan 08 18:46:45 and if you say "not for gaming" it means your quality demand is pretty minor Jan 08 18:47:17 ctate: not necessarily :) Jan 08 18:47:31 okay, unless you're French or something. Jan 08 18:47:38 :D Jan 08 18:47:46 or you do graphics & stuff ;) Jan 08 18:47:47 (if you have *color* requirements, you need to shop carefully) Jan 08 18:47:52 are you crazy? dell is way overpriced. Jan 08 18:48:07 jasta: their sale prices are not nearly as bad Jan 08 18:48:07 ctate: Well I really care about the quality :) Jan 08 18:48:23 ctate: let's say that if you want an affordable good quality 30", you don't have much of a choice :) Jan 08 18:48:24 ctate: yes but their sale prices merely reflect regular prices elsewhere. sale prices elsewhere are much better then as well. Jan 08 18:48:29 i like newegg but i have to pay sales tax there Jan 08 18:48:42 i use newegg, but its tax free for me. Jan 08 18:48:48 exactly :) Jan 08 18:49:06 well maybe you shouldn't live in sucky california then :) Jan 08 18:49:33 Ok lets ask romainguy what would you recommend :D Jan 08 18:49:47 * jbq recommends a good old 21" CRT :D Jan 08 18:49:49 anno^da_: Dell 30" :) Jan 08 18:49:52 :D Jan 08 18:49:54 ahaahahahahahaha Jan 08 18:49:54 ha ha ha Jan 08 18:50:11 its a nice display :) Jan 08 18:50:11 jbq: and a forklift to get it onto the table? Jan 08 18:50:12 with this new camera I need 3 or 4 30" @!# Jan 08 18:50:22 CRT ahhh never anymore :) except for playing old FPS games ;) Jan 08 18:50:27 ctate: actually, the last ones that were made weren't that heavy. Jan 08 18:50:34 oh good Jan 08 18:50:43 * jasta has two viewsonic widescreen 24's :) Jan 08 18:50:45 and a good one you can run at 90fps, woo woo Jan 08 18:51:28 Well ok I have to test them again since I'm very picky regarding the quality of the picture and a lot displays making strange noises :) Jan 08 18:51:43 let's all just get HDTV projectors against the wall in front of our desks. Jan 08 18:51:51 :D Jan 08 18:51:59 that would be sweet actually hehe Jan 08 18:52:01 they are "very" silent :P Jan 08 18:52:49 you can always check e.g. Toms Hardware for reviews, newegg ratings on current models, etc. to get an idea of what's considered good Jan 08 18:54:43 Yeah true. I already read all the german review sites. Just tried to get perhaps one or two new display names from the normal user site :) Jan 08 19:16:49 anybody in here have some spare rime Jan 08 19:16:54 time* Jan 08 19:23:06 akuma5, Are yuo trying to get someone to commit to something blindly? No thanks. Jan 08 19:28:40 akuma5: can you please stop already Jan 08 19:29:02 post on a freelance site... not here Jan 08 19:31:01 It's a shame I really did have some spare rhymes, dawg. Jan 08 19:31:55 im getting errors i just need some help with Jan 08 19:32:10 im use the library Jan 08 19:32:33 just wont to know why there not working Jan 08 19:33:19 i would be nice if had a little ass Jan 08 19:33:33 * CardinalFang stifles a guffaw. Jan 08 19:35:23 akuma5, Welcome to IRC. No one will commit to helping. Show us you already did your homework and show us you care about our time more than your own, and then ask smart questions. Jan 08 19:36:21 and because it's irc we'll still give you a hard time Jan 08 19:40:56 hello i been useing irc for years and if i am correct it is a place descus and even give and get help i have read alot up on what i am trying to do this my fist time trying dev a program and i have already installed eclipse and the android plugin along with the sdk but i found out how to use my G1 as my debuger and i am trying to use the tools in the library and ever thing i try gives me a eara and its not a nice feeling Jan 08 19:40:56 im just a simple guy with a goal Jan 08 19:41:20 jasta: Any idea what impact your IMAP keepalive implementation has on battery life? Done any testing? Jan 08 19:44:10 akuma5, I'm about to give up on you, and instead say snarky things like "you'll find programming is easier with a keyboard that has punctuation symbols". Just ask already. Jan 08 19:45:03 CardinalFang: he's already been referred elsewhere many times Jan 08 19:45:05 akuma5: then ask your question about your error Jan 08 19:45:28 Ah. Jan 08 19:46:32 CardinalFang: and snarky comments have previously flown his way. ;) Jan 08 19:47:45 BlindOracle, I suspect the cost on battery depends on whether the radio is already fired up, and whether it's 3G, or Wifi, or what. Jan 08 19:50:06 CardinalFang: yes, of course, but he's added additional socket traffic on what would otherwise be an idle TCP connection. So I'm wondering he's analyzed the battery cost of periodic traffic for each of the use cases (wifi, 3g, 2g). Jan 08 19:53:24 hi Jan 08 19:55:00 BlindOracle: yes, very little impact. when you implement this stuff efficiently, the CPU can still sleep often Jan 08 19:55:10 jasta: At line 352, you may want to consider adding, "mSocket.setKeepAlive( true ) ;" Jan 08 19:55:14 and the radio is idle most of the time as well, so in a power saving state. Jan 08 19:55:25 jasta: that's what I suspected but nice to hear it affirmed Jan 08 19:55:36 people often confuse push services with being very battery intensive but the reality is that the response to the notification is what has the greatest effect Jan 08 19:56:02 as in, getting your e-mails in real time causes you to turn on the screen and read them as they arrive Jan 08 19:56:29 jasta: based on questions from google devs I suspect in the future, setKeepAlive( true ) will also have benefits for you and it won't hurt to enable now. Not for your class of connection. Jan 08 19:56:40 not only that...if you average a new email every minute wouldn't that take more bandwidth than if you just had it auto check every 10 minutes? Jan 08 19:56:53 my very ultra simple demo which actually exchanges no data or offers any real notification (it just keeps the connection up), impacts battery in such a minor way i cant even detect it Jan 08 19:57:16 BlindOracle: the TCP keep alive feature is different, and has a minimum frequency of 2h. Jan 08 19:57:17 "Unhandled event loop exception" is the error but it has a big desription but the thig is it does that for all the scripts i use from the library any idea why? Jan 08 19:57:19 jasta: I'm with ya... preaching to the choir. For this class of connection, IMHO, I think this makes lots of sense - especially now that I understand what's going on under the covers Jan 08 19:57:23 s/bandwidth/battery/ Jan 08 19:58:07 zhobbs_: well, it's a difficult question to answer numerically but in general push services are going to be more efficient than a short interval poll. Jan 08 19:58:13 because the poll requires more resources to actually perform Jan 08 19:58:17 akuma5, Do you know what exceptions are? Jan 08 19:58:27 ill google it Jan 08 19:58:42 since each time you connect you lose state you must perform local queries and such to establish your state. then you have to perform all the overhead of checking that state with whatever service you're connected to, etc. Jan 08 19:58:43 jasta: that frequency is changeable and I strongly suspect defaults are changing in the future to something smarter than 2hours. Jan 08 19:58:48 likely yielding more load Jan 08 19:59:17 An exception is an event that occurs during the execution of a program that disrupts the normal flow of instructions. Jan 08 19:59:28 BlindOracle: no, the TCP standard requires that TCP keep-alives are sent no earlier than 2h. Jan 08 19:59:30 jasta: http://code.google.com/p/android/issues/detail?id=1726 Jan 08 19:59:38 akuma5, until you care enough to find out what the pieces of that error means, you're be in far over your head. Jan 08 19:59:39 jasta: and it has less load than you doing it at the application layer Jan 08 19:59:40 you are confusing TCP keep alive with an application layer keep alive. Jan 08 19:59:49 (i think) Jan 08 19:59:54 jasta: and provides additional benefits at the application layer Jan 08 19:59:58 jasta: not at all Jan 08 20:00:02 jasta: no confusion at all Jan 08 20:00:05 then you havent read the TCP RFC :) Jan 08 20:00:08 akuma5, Programming isn't easy. Jan 08 20:00:19 because it is a violation of it to send those keep alives at an interval of less than 2h. Jan 08 20:00:22 jasta: I not sure why you keep taking wild left turns when we talk about this stuff Jan 08 20:00:58 jasta: it is not a violation to change these values Jan 08 20:01:06 hehe, hang on, i will show you. Jan 08 20:01:18 jasta: and that value often differs from OS to OS to boot Jan 08 20:01:33 i understand that linux LETS you change the value Jan 08 20:01:44 CardinalFang, i know nether is running a linux base server and secureing it but i know it Jan 08 20:01:50 but doing so causes you to be out of compliance with the formal TCP specification. Jan 08 20:01:56 i will show you why if you give me a minute :) Jan 08 20:02:05 jasta: and they often are because for many 2h is too long Jan 08 20:02:17 akuma5, Great! I know how to cook waffles. It won't help me program, though. Jan 08 20:02:24 jasta: it is a recommendation Jan 08 20:02:54 jasta: and besides, I'm not sure why you confuse app keep alive with OS keep alive Jan 08 20:03:02 OS = stack Jan 08 20:03:27 actually, its part of TCP, not the OS or the stack. anyway, i am not confusing them. you suddenly started discussing the TCP keep alive so i changed what i was talking about. Jan 08 20:03:54 i was trying to tell you that i have looked into using the TCP keep alive, and learned that the formal protocol requires keep alive intervals at or greater than 2h, so i stopped looking there. Jan 08 20:04:02 I was talking TCP keepalive because it makes sense to use it Jan 08 20:04:22 whereby you're implementing an application level keepalive Jan 08 20:04:25 likewise, for my purposes, IMAP has an application layer timeout mechanism built into its spec, so TCP keep alives wouldnt work regardless Jan 08 20:04:51 furthermore, for applications where connectivity is questionable, keepalives make even more sense. Which is exactly this environment. Jan 08 20:05:15 jasta: right, but that means you have to wait up to ~30 minutes to even learn if you have a valid connection or not. Jan 08 20:05:40 and until that interval passes, isConnected() may continue to tell you, you are connected when you are in fact not connected Jan 08 20:06:16 that's not entirely accurate. if an orderly reset occurs you will be notified. similarly if android loses connectivity (EDGE/3G, or Wi-Fi) you will be notified via its internal mechanism. Jan 08 20:06:24 which means email notification may be 30 minutes late Jan 08 20:06:33 so the only event which will cause this discrepency of an abruprt and disorderly loss of connectivity along the way to the server. an unlikely event. Jan 08 20:06:33 that's a big if Jan 08 20:06:56 is there also a way to store a list in the preferences? Jan 08 20:06:59 disorderly loss of connectivity is common Jan 08 20:07:04 and even if it does occur, odds are that is a failure that won't be corrected by another connection attempt Jan 08 20:07:14 jasta: not true Jan 08 20:07:50 can you please qualify how you mean disorderly loss of connectivity is the common case? what experience do you have to suggest this? Jan 08 20:08:06 this commonly occurs...this is not a corner case as you seem to assert Jan 08 20:08:15 i blieve you to be false, and i'd stake my decade of advanced networking experience on it :) Jan 08 20:08:39 jasta: I've been writing networked apps for many, many years. Jan 08 20:08:56 only a disorderly loss of connectivity at the server would cause this, the cellular network will alert you gracefully via android mechanisms. similarly, if you have a disorderly shutdown, the server is likely unreachable for a length of time anyway Jan 08 20:09:03 because somehow, it's offline. it didn't just close your connection. Jan 08 20:09:05 or restart. Jan 08 20:09:17 I have been involved in publicly visible network servers for many years. Jan 08 20:10:04 so what condition do you precisely believe to be common that causes a disorderly shutdown? also, how do you justify that increased radio activity for a shorter window keep alive (either at the application layer or at the TCP layer) would be advantagous? Jan 08 20:10:29 All it takes is a crash/reboot/fail over, etc....the cool thing is, the timer will typically activate after service has been restored which means you app can now restore the connection as it has detected loss of connection in a shorter interval. Jan 08 20:11:18 i would not consider my work exchange server crashing, rebooting, or failing a common case. are your companies IT guys drunk on the job? :) Jan 08 20:11:27 as is, should something happen, for example IMAP IDLE, you won't know about it until your timer expires. With TCP keepalive at sane values for the environment, you would know about it and reconnect in a shorter duration... Jan 08 20:11:40 furthermore, i would not consider that case even worthy of increasing battery usage significantly. Jan 08 20:11:44 jasta: strawman Jan 08 20:12:05 Balachmar, I don't think so. Your only recourse may be to define a prefix and a length, and iterate over getFoo(prefix+i.toString) . Jan 08 20:12:12 jasta: it's up to you. I'm just making a suggestion. These things happen fairly commonly. Jan 08 20:12:18 you only won't know about a disorderly shutdown, let's be sure we are clear about that. any failure at the cellular network will be discovered quickly as will an orderly shutdown Jan 08 20:12:51 jasta: I have no idea why you're under that impression Jan 08 20:13:12 BlindOracle: my experience very strongly disagrees with you. as does Google's, clearly. also, i would not violate the TCP RFC :) Jan 08 20:13:15 btw... Jan 08 20:13:16 @CardinalFang: You mean just to add a seperator between the values and put them in a string? Jan 08 20:13:22 By "cellular" do you mean the link+transport level? Jan 08 20:13:39 jasta: enabling a feature specifically part of the TCP specification does not violation TCP RFCs Jan 08 20:14:03 Balachmar, No, pickling them together is hard. I suggested putting putting each value into its own named slot. Jan 08 20:14:10 you are correct regarding the TCP keep alive interval. the RFC actually claims that it MUST default to no less than 2h, but nothign about it being lower. regardless, android doesnt allow you to configure it lower afaik. Jan 08 20:14:29 jasta: another strawman Jan 08 20:14:41 but my point remains valid that you are increasing battery usage for the case where your server explodes. Jan 08 20:14:48 jasta: as I said, I strongly suspect the values will be lowered in the future to reflect the operating environment Jan 08 20:15:05 and not even to handle that case better, only faster. Jan 08 20:15:10 jasta: battery hit will be a fraction of what you're already imposing Jan 08 20:15:15 CardinalFang: Aah I see, that is also a possibility yes! Jan 08 20:15:17 Thanks Jan 08 20:15:17 as it's handled at the stack Jan 08 20:15:40 jasta: point being, they compliment each other Jan 08 20:15:59 jasta: it doesn't have to be an either-or situation Jan 08 20:17:17 jasta: like I said, just a suggestion Jan 08 20:17:58 i don't understand how you think it will be a fraction of what you're already doing. for the case where you aren't getting any e-mail, reducing the keep alive interval will have a linear relationship to battery performance. if you halve the interval, youre using twice the battery to keep that connection alive. Jan 08 20:18:12 remember, the CPU is asleep. you are waking it up to send your keep alive. Jan 08 20:19:30 jasta, how asleep is the CPU? Do you know if it's using the new clockless voodoo? Jan 08 20:19:36 jasta: but it occurs at much lower level meaning much less code runs and runs for much shorter duration. Not using it means worst case, you don't know about new mail for 30 minutes. Jan 08 20:19:42 man this is juicy. you know how long its taken me to read this convo between jasta and BlindOracle? Jan 08 20:19:59 CardinalFang: i actually haven't investigated how it sleeps. i would love to know, but i just haven't spent the energy to find out yet :) Jan 08 20:20:13 CardinalFang: i do know that the AlarmManager is the only mechanism present to the java layer which can wake it, though. Jan 08 20:20:24 and akuma5 is back. Akuma5: tell me what that error was and i will see if i can help Jan 08 20:20:27 CardinalFang: I'm holding my tongue on that too...I keep hearing mixed reports about the CPU sleeping Jan 08 20:20:34 (Fun fact: My first and only patch that made it into the Linux kernel was about resetting interrupt zero to the standard jiffy rate after sleeps, on some buggy BIOSes.) Jan 08 20:21:08 only patch i've bothered to write for inclusion in to the Linux kernel was the thrustmaster rumble support :/ Jan 08 20:21:15 and i kinda abandoned it :< Jan 08 20:21:25 That was like 1997. /me shakes his fist at the kids on his lawn. Jan 08 20:21:28 but fortunately it looks like others have taken over Jan 08 20:21:41 <- does not actually like rumble Jan 08 20:22:01 CardinalFang: ya, I too have wondered if the tickless stuff is part of the standard kernel Jan 08 20:22:07 BlindOracle: the overhead involved in the timing and the cpu waking is presumably higher than a margin difference in the load once awake. i cannot say that with confidence though as i don't know what the timing mechanism is. Jan 08 20:22:18 BlindOracle: tickless is part of the standard kernel on x86/amd64 Jan 08 20:22:27 BlindOracle: dunno about other architectures Jan 08 20:22:30 zinx: but it's a compile option Jan 08 20:22:37 BlindOracle: so is everything else. Jan 08 20:22:42 Heh. Jan 08 20:22:54 zinx: point being, I don't know if it was enabled and/or supported on ARM Jan 08 20:23:05 BlindOracle: if you mean a standardly enabled option, there is no such thing. Jan 08 20:23:13 BlindOracle: there is only can it support and can it not support Jan 08 20:23:27 what the end result of whatever vendor chooses is entirely their own :/ Jan 08 20:23:48 hmm, that wasn't worded very well. Jan 08 20:23:52 zinx: in this case, what's running on the g1/adp1 Jan 08 20:24:00 BlindOracle: /proc/config.gz Jan 08 20:24:29 CONFIG_NO_HZ=y Jan 08 20:24:40 zinx: great...that have it included....and enabled...cool Jan 08 20:24:46 that means like, infinite gigahurtz, right? Jan 08 20:24:53 ten billionty eleven? Jan 08 20:24:55 included = proc/config support Jan 08 20:25:02 vol: over 9000 Jan 08 20:25:12 ITS OVER NINE THOUSANNNNNDDD!?!! Jan 08 20:25:20 BlindOracle: yeah, i thank whoever enabled config.gz on the G1 :D Jan 08 20:25:35 agreed! :) Jan 08 20:25:58 well hopefully jasta has some food for thought Jan 08 20:42:54 sorry, had to step away Jan 08 20:43:14 round 2! Jan 08 20:43:41 BlindOracle: i already knew all these things you discussed actually. the argument we had was me not agreeing with you that it was a viable option. Jan 08 20:43:43 famast: heh Jan 08 20:45:15 if you could get away from the application layer keep alive completely *AND* if android allowed you to configure it, it might be a different story. but you can't :) Jan 08 20:45:41 jasta: that's fine. Your choice. The mechanism exists for exactly these types of issues. IMHO, ultimately, it boils down to battery draw and desire to simply use. Again, IMHO, the battery draw is likely not worth discussion. But since I don't have numbers to spout, that's that Jan 08 20:47:51 so if you make a socket connection your saying this radio can sleep for two hours? Jan 08 20:47:59 <-- has not had 10 years of networking experience Jan 08 20:48:06 also, TCP keep alives carry one big problem in most stack implementations: they are not configurable per connection. meaning that if you were to use them critically, you'd have to ensure that every application using this mechanism agreed on an acceptable interval. Jan 08 20:48:39 famast: in theory, yes. t-mobile carrier network won't let you idle for quite that long, though. Jan 08 20:48:42 t-mobile's* Jan 08 20:48:52 jasta: those applications wouldn't use SO_KEEPALIVE. Jan 08 20:49:03 but if you don't send any data neither side will know if the other peer is really there or not. Jan 08 20:49:48 jasta: that's right...and that's why some connections hang for days, weeks, etc...and that's why IMAP servers typically toss idle connections Jan 08 20:49:50 BlindOracle: but you don't know what those applications are. if it was configurable by any app, you would have to trust that no app makes a configuration choice you don't agree with. Jan 08 20:50:06 jasta: keepalive ONLY used on sockets which request it Jan 08 20:50:19 i thought the timeout was far less because isn't there a vulernability with that. If you have thousands of people making connections then not responding for two hours.... Jan 08 20:50:23 vol: lol Jan 08 20:50:28 i know that: but every app that requests it has to use the same interval because of the way the stack is implemented in Linux. Jan 08 20:50:29 wrong channel ;D Jan 08 20:50:33 you get overflows Jan 08 20:50:41 haha morrildl Jan 08 20:50:58 and that combined with an apps ability to change the interval would be catastrophic. one app could manipulate intervals for all apps that depend on this facility. Jan 08 20:51:27 jasta: I don't believe that is the case under linux (which is really what we're talking about here). On Linux, the proc values only set the default values. You can then use setsockopt to change those values on a per socket basis. Jan 08 20:51:59 ?? Jan 08 20:52:04 * SuperSaiyajin wishes that instead of saying "are now known as", it said "transforms into" Jan 08 20:52:22 BlindOracle: that's possible, i haven't researched that recently. however, what we're REALLY talking about is Android, and you cannot even get to setsockopt from there :) Jan 08 20:52:24 * michaelnovakjr agrees Jan 08 20:52:26 jasta: but in this case, simply using a value smaller than what carriers typically use to close/terminate/kick idle connections is a plus. and in IMAP's case, it's a plus because it allows you to recover and grab mail faster than worst case is other wise. Jan 08 20:52:30 ...IMO Jan 08 20:52:50 jasta: you can get to setsockopt Jan 08 20:53:01 not from the java layer. Jan 08 20:53:04 jasta: setsockopt(fd, IPPROTO_TCP, TCP_KEEPIDLE, &value, sizeof(value)); Jan 08 20:53:05 jasta: just not through java...but through JNI Jan 08 20:53:35 jasta: as for the Linux TCP stack wrt. keepidle timing.. Jan 08 20:53:38 keepalive even Jan 08 20:53:40 BlindOracle: you would advise a design that relied on JNI for a keep alive? :) Jan 08 20:53:50 and as I said, I strongly suspect (no, that's not gospel) future releases will have sane (given the environment) defaults Jan 08 20:54:02 jasta: as described in tcp(7) Jan 08 20:54:16 jasta: I'm saying that's one such option Jan 08 20:54:19 jasta: i think he would suggest a proper Java interface to it first :P Jan 08 20:54:31 zinx: hehe, of course. Jan 08 20:57:18 while we're on the topic of networking, has anyone else noticed that Android will report connection success (Socket#connect() will complete without throwing an exception) when the host is not accepting connections. Then, after an attempt to exchange data you will see a Connection reset by peer exception thrown... Jan 08 20:57:30 jasta: you are of course correct in that ideally, the android platform should expose such options...but as short fall would be for the defaults to be changed such that they get the sane (for the environment) defaults Jan 08 20:58:08 jasta really? I've seen some connection refused exceptions in that case Jan 08 20:58:23 jasta: ouch. Jan 08 20:58:36 michaelnovakjr: i'm positive. i've been able to demonstrate it several times. Jan 08 20:58:42 interesting Jan 08 20:59:03 in fact, it's doing it right now. my IP address changed and t-mobile's DNS network takes AGES to catch up... Jan 08 20:59:13 jasta: was the server simply in a listen but perhaps delayed in issuing an accept causing a client side timeout or something odd like that? Jan 08 20:59:20 so jasta.dyndns.org used by my persistent connection demo is pointed somewhere old, and yet the connection succeeds Jan 08 20:59:31 it fails several seconds after i force it to send a ping. Jan 08 21:00:07 BlindOracle: no, i tested it with nc not even running, and confirmed with wireshark that the ICMP response was delivered. t-mobile's network must just discard it. Jan 08 21:00:59 very strange behaviour Jan 08 21:01:15 you're saying ICMP made it but connection request did not? Jan 08 21:01:47 am sorry....having trouble following what you're saying Jan 08 21:07:51 no the connection request makes it. i see a SYN packet from t-mobile, then i send SYN/RST, but the phone interprets the SYN/RST coming back as a connection success. Jan 08 21:08:20 or so it seems, i cant packet sniff the phone of course Jan 08 21:08:30 maybe it doesnt get the RST bit from t-mobile... Jan 08 21:08:55 but regardless, the connect call succeeds. if you attempt a send(), it will fail a few seconds later with connection reset. Jan 08 21:09:23 if you say nothing (write no data), it will just stay open like that for at least a few minutes, possibly longer i didn't pay attention Jan 08 21:09:38 <_avatar> yeah, i've observed the same behavior. Jan 08 21:10:25 it appears that the carrier network is being optimistic, assuming connections succeed before it gets confirmation that they did. Jan 08 21:10:39 either that or google folks busted the TCP stack implementation in Android :) Jan 08 21:13:46 jasta: I've read tcpdump has been ported... Jan 08 21:14:02 i don't have root on my phone yet. waiting for t-mobile to send me one. Jan 08 21:14:37 i rooted a friend's rc30 tmobile phone for him, simple process Jan 08 21:15:36 i just dont feel like messing with it. i'm gonna hand this phone off to my girlfriend in a week when i start at t-mobile Jan 08 21:15:43 nice Jan 08 21:15:51 jasta: I'd bet on the optimistic implementation at t-mobile as that would drastically decrease latency and improve application times for times like browsers where lots of connections are made Jan 08 21:18:25 thats what i was thinking as well. for protocols like HTTP this makes some order of sense, especially if connection build-up is expensive as it is on EDGE/3G. Jan 08 21:18:49 that way you can begin transmitting the initial request before waiting for any response from the initial connection request Jan 08 21:18:57 in the very likely event that it succeeds, it will go through more quickly Jan 08 21:20:41 jasta: agreed Jan 08 21:24:32 shoutcast over http is streamed by polling the server right? Jan 08 21:24:43 you have to constantly engage in new requests? Jan 08 21:26:28 arg...just did the math...I've been network coding for 15-16 years. Jan 08 21:26:32 now get off my lawn Jan 08 21:26:47 :P Jan 08 21:27:08 BlindOracle: thats some tough math Jan 08 21:27:34 jt436: heh...I find to think of a frame of reference to get the start year...had to go back to OS/2 Jan 08 21:28:50 wow your old :P Jan 08 21:29:14 famast: ya I know... one 19 year kid loafs and the other is a Marine Jan 08 21:29:41 ah they are missing the sheer joy of programming Jan 08 21:30:19 heh...I'm not sure they see it that way Jan 08 21:30:27 anyone have any ideas for writing a visualizer for playing audio? I don't see a way to access the raw audio stream...so don't really see how you'd go about it Jan 08 21:30:28 but the Marine is hating life Jan 08 21:31:00 zhobbs_: whoever made that delightful ringtone maker app figured out something, ask them : ) Jan 08 21:31:35 vol: that access audio files right? Jan 08 21:31:44 vol: not the same as realtime stream processing Jan 08 21:31:58 zhobbs_: I cheated to display audio data, made things much quicker. Jan 08 21:32:12 but I also knew what to expect from the audio Jan 08 21:32:33 I suppose you have a point there :\ Jan 08 21:33:00 jt436: was just thinking if you can get some type of notification from the player as it gets blacks, you know the bit rate so you can pseudo walk the stream...just won't be realtime Jan 08 21:33:14 blacks = blocks Jan 08 21:33:16 hehe Jan 08 21:33:34 racist. Jan 08 21:33:41 hehe Jan 08 21:33:55 maybe I was thinking of crayons Jan 08 21:33:57 :P Jan 08 21:35:40 A visualizer would be cool, all though it would bother me knowing that my battery power is being drained for something like that Jan 08 21:36:01 I bet you took out all of the crayons in your box except for pink, because you didn't like the other colors Jan 08 21:36:04 didn't you Jan 08 21:36:21 exactly, they never tasted right Jan 08 21:36:28 vol: lol...power to the crayons! Jan 08 21:37:05 we had textas instead of crayons Jan 08 21:37:53 * jt436 wonders who went to google "texta" ;) Jan 08 21:37:58 man, t-mobile's dns servers are soooooo slow to update Jan 08 21:38:03 * Falcon4ever raises hands Jan 08 21:38:14 jt436: was wondering if that was "Texas" or what Jan 08 21:38:46 sweet, my gf is gonna be in california all next week. i can finally get some work done Jan 08 21:38:51 haha Jan 08 21:39:06 make sure to tell her that Jan 08 21:40:14 romainguy_: here's my daily reminder to post that code :0 Jan 08 21:40:31 like I said yesterday, I need to remove some usages of private APIs Jan 08 21:40:46 i know, im just trying to motivate you :) Jan 08 21:41:05 motivation is not an issue Jan 08 21:41:06 time is :) Jan 08 21:41:18 romainguy_: alright...I've read about it several times but have no idea what it is...what code? Jan 08 21:47:24 yea i'm curious too what code Jan 08 21:47:35 whatcha working on back there Jan 08 21:57:01 this : http://www.progx.org/users/Gfx/shelves_2.mp4 Jan 08 21:58:06 nice Jan 08 22:03:14 very nifty Jan 08 22:03:17 i like the bookshelf Jan 08 22:08:38 nice Jan 08 22:09:27 the interesting thing about the source code is all I did to make scrolling and loading fast Jan 08 22:26:35 <_avatar> jasta: earlier you mentioned your keepalive alarm in your service had no real impact on your battery life; can you remind me how long you alarm's interval is? Jan 08 22:26:42 romainguy_: what i really like is the fade-in you did for images when they appear Jan 08 22:26:57 _avatar: my interval is 28 minutes, to comply with IMAP's specification (which recommends 29 minutes) Jan 08 22:27:23 jasta: I'm using the TransitionDrawable but in 1.0 the API doesn't let you use it correctly, hence the use of private APIs Jan 08 22:27:29 <_avatar> jasta: ok, thanks Jan 08 22:27:35 of course it does actually impact battery life, and you need to balance how much activity it has with whether push notifications are really worth it, etc. Jan 08 22:27:37 I'll just copy/paste TransitionDrawable from release-1.0 into my app :) Jan 08 22:27:43 <_avatar> jasta: of course :P Jan 08 22:28:13 but in my experience, a do-nothing keep alive service seems to have no real impact. Jan 08 22:28:34 romainguy_: i did that for FastScrollView :) Jan 08 22:29:26 romainguy_: is TrainsitionDrawable how you fade in the images? Jan 08 22:29:28 <_avatar> i was thinking about doing something similar, but every 5 minutes for my service to check the state of my connection. i guess i'll need to do some testing to see if that's too often Jan 08 22:29:37 jasta: yes Jan 08 22:30:18 jasta: if you ever make your axml2xml script work again, that'd be awesome btw :) Jan 08 22:30:27 I kinda erased my AndroidManifest.xml by mistake Jan 08 22:30:28 _avatar: i would not recommend a 5 minute interval. if you caught my conversation with BlindOracle, our difference of opinion was in the nature of how likely ungraceful failure at the server was. Jan 08 22:30:32 and all I have is the binary version :)) Jan 08 22:30:50 romainguy_: hehe, i could probably make it work quite easily now that code is available for the compiler :) Jan 08 22:31:09 <_avatar> sorry, i didn't catch the conversation. i came in the beginning, then was distracted, then had to reboot. Jan 08 22:32:14 _avatar: the important point was that with a long keep alive interval (such as mine at 28 minutes), it could take up to that time to detect a dead peer. Jan 08 22:33:30 assuming you are using the connectivitymanager locally on android, this could only happen in the event the server has disappear or become unreachable abruptly. an orderly shutdown (if the service was restarted, for instance) would alert you without a keep alive, but for instance unplugging the cable or abruptly losing power would not. Jan 08 22:33:39 you would only know that happened when you attempt to send your keep alive and it is not responded to. Jan 08 22:34:04 so if this is an issue for you, you can shrink your keep alive interval to close the window some, but at the cost of extra overhead. Jan 08 22:34:34 for me, i consider 30 minutes an acceptable window to detect a dead server, considering that i believe this type of disorderly shutdown to be rare. Jan 08 22:34:48 and moreover, even when it does happen, the server is likely to remain offline for at least some length of time anyway. Jan 08 22:34:57 <_avatar> well, my client and server have the ability to ping each other, and if a response isn't received after a certain interval, either can hang up Jan 08 22:35:36 <_avatar> so on the client end if i haven't heard a ping from the server after some duration, it can disconnect, then schedule a reconnect attempt after some time has passed Jan 08 22:36:15 right, but my point is that those intervals affect battery performance. Jan 08 22:36:20 <_avatar> obviously. Jan 08 22:36:43 <_avatar> that's why i was asking about how long your interval was Jan 08 22:36:43 short intervals allow you to detect a dead peer more quickly, long intervals preserve battery life. it's about what you believe to be a likely failure. Jan 08 22:37:01 but keep in mind, you should be using the ConnectivityManager on Android to detect local network failures as they _are_ likely. Jan 08 22:37:06 and don't require a keep alive to detect Jan 08 22:37:22 <_avatar> i am using the ConnectivityManager for local failures, but that doesn't help with remote failures Jan 08 22:37:35 <_avatar> e.g. the server is restarted Jan 08 22:37:36 im just reiterating :) Jan 08 22:37:38 <_avatar> ok :) Jan 08 22:37:40 <_avatar> appreciated Jan 08 22:37:45 if the server is restarted, you'll detect it gracefully and without a keep alive. Jan 08 22:37:57 an orderly shutdown as with close() will send a RST packet unprovoked, which you will pick up on the phone. Jan 08 22:39:44 <_avatar> right, but i don't want to rely on the server always being shut down gracefully. i'd like to handle all possible cases on the client :) Jan 08 22:42:06 as i said, it's a balance. Jan 08 22:42:40 I consider 30 minutes an acceptable window. As does Google. Jan 08 22:43:00 If you disagree, by all means narrow that window, and accept the loss of battery life that results :) Jan 08 22:43:47 Again though, if say your server lost network access from its provider, detecting that sooner and reconnecting won't help you at all :) Jan 08 22:45:20 <_avatar> it should probably be user-customizable in my app. depending on how the user is using the it, some of the communication between the client and server is pretty time critical Jan 08 22:45:41 would like to remind people that TCP keepalives can easily be made to toggle - though I've never tried on an active connection. Some socket options can only be applied before it is connected. Jan 08 22:46:11 I suspect keep alive can be changed after the fact - but I'm not 100% Jan 08 22:49:27 I will add, in my experience, the worst case given is the very rare situation and is not likely - though nothing wrong defending against it - and that in my experience (which seemingly drastically differs from jasta's), keepalives tend to work well to allow connection restoration since the service/service is available shortly after. Jan 08 22:50:31 In fact, in my experience, I see NAT/firewall routes, switches, and hubs cause the bulk of these type problems whereby, service is available again within seconds, if not less. Meaning, keepalives tend to work. Jan 08 22:51:03 ...seconds can become minutes... yet still fall less time than interval timer Jan 08 22:52:00 though service failover (ones which do not support socket migration) can also cause these issues which also means the service is immediately available again - just requiring a new connection. Jan 08 22:52:25 So, different takes on the same woes Jan 08 22:53:47 BlindOracle: whats wrong defending it is that it wastes valuable resources. you will see performance impact as you tighten the interval that wakes the cpu. i promise you, i have experimented with this for months now. Jan 08 22:53:59 one of the first projects i picked up when i got my G1 was implementing IMAP IDLE Jan 08 22:55:02 jasta: that statement was an all things being equal - clearly it does not address the compromises often required in an embedded world; especially one tethered to a battery. Jan 08 22:55:16 i originally ran my code with a keep alive interval of 2 minutes during initial testing and it was noticably poorer performing than my current solution at 15 times longer. Jan 08 22:55:52 jasta: that's not unsurprising in the least once you consider what is going on to accomplish that task Jan 08 22:56:16 err...not surprising Jan 08 22:57:33 geez are you guys still going on about that Jan 08 22:57:50 <_avatar> sorry, i unintentially refueled the fire :) Jan 08 22:58:12 there is a huge difference in the required work to trigger intr, wake device handler, handler delivers to stack, stack replies...verses that plus, stack delivers to buffer, schedules app, app wakes, lots of byte code processing....buffer is read....blah...blah... Jan 08 22:58:27 _avatar: just friendly exchange Jan 08 22:58:28 wtf eclipse destroyed my project Jan 08 22:58:37 <_avatar> BlindOracle: i know, i'm just kidding Jan 08 23:00:01 jasta: especially when I've read something like 10,000x more work to do via DEX versus native and we're talking multiples of that here Jan 08 23:05:22 in other words, many orders of magnitude more work is required to do it at the application layer, especially via the VM, that is required to do it in the OS. But to be clear, jasta is correct, the overhead of waking (if in fact it truly sleeps) is currently unknown Jan 08 23:05:54 so experiment...experiment Jan 08 23:09:49 <_avatar> good advice. let's see how quickly a 5 minute alarm kills my battery Jan 08 23:11:46 _avatar: one thing I am sure of, using alarms means waking the VM - so lots of overhead. I'm sure jasta results are representative. Jan 08 23:12:05 _avatar: it's difficult to objectify this with a phone that you carry in your pocket. if you can, get a second phone. Jan 08 23:17:23 BlindOracle: have you introduced this topic to Google btw? Jan 08 23:18:43 that is, offering an interface to TCP_KEEP* sock opts in Android. Jan 08 23:19:02 and using a set of defaults in /proc that better fit a mobile device? Jan 08 23:19:44 i would be interested to see what could come of google putting more research energy into this topic. Jan 08 23:20:59 jasta: not all encompassing there Jan 08 23:21:08 I provided the link above...I'll fetch again. Jan 08 23:21:29 http://code.google.com/p/android/issues/detail?id=1726 Jan 08 23:21:41 That addresses the defaults; which for most is more than enough Jan 08 23:21:51 it is after all, unlikely to be a common case need Jan 08 23:22:14 beyond that, there is native node via JNI. So everything is actually accessible/doable right now. Jan 08 23:22:50 yes but google is less likely to officially support anything that can't be accessed from the java layer Jan 08 23:22:54 including your requested changes. Jan 08 23:23:31 they already do expose stuff from the kernel layer, like thread priority. Jan 08 23:23:50 jasta: well, I was rather encouraged by the interest thus far. Given the ease of change/test/validate. Jan 08 23:24:37 jasta: if this does interest you, I would encourage you to apply your own comments. Feedback from other developers surely adds to the weight of the request. Jan 08 23:24:59 _avatar: *cough* *cough* you too. ;) Jan 08 23:25:25 <_avatar> jasta: i have two phones Jan 08 23:25:33 _avatar: i figured as much :) Jan 08 23:25:38 <_avatar> one is mine, one belongs to work :) Jan 08 23:25:50 jasta: even if comments are negative, I would encourage you to make them. Wasted time is wasted time; especially since access already exists. Jan 08 23:30:31 have you tested these parameters yourself? Jan 08 23:30:58 I have...I have not tested battery life or overall impact. The modest testing thus far is postive Jan 08 23:31:00 does a keep alive actually get generated? Jan 08 23:31:02 *modest* Jan 08 23:31:08 yes Jan 08 23:31:20 ok, i just wanted to be certain that the code wasnt broken for any other reasons :) Jan 08 23:31:40 jasta: you're not seeing them? Jan 08 23:32:01 jasta: keep in mind you have to change the proc values too Jan 08 23:32:07 which is what I did Jan 08 23:32:13 no i havent tried. Jan 08 23:32:20 i was just curious to know that you have actually tested this already Jan 08 23:32:29 ok Jan 08 23:33:45 i just posted a comment asking for some more study on this. Jan 08 23:34:35 for push type apps, especially if it's app configurable, this seems like a natural fit - assuming battery impact isn't too negative. Jan 08 23:34:39 it would be nice to see a test case put together that can be used to exaggerate performance problems. for instance, send an application layer keep alive every minute versus a TCP keep alive probe. Jan 08 23:34:54 and have two otherwise idling phones run in that environment for a day Jan 08 23:35:08 it could be possible that you'd find a significant difference Jan 08 23:35:21 jasta: agreed. I just don't have the time for such testing - yet. Jan 08 23:35:45 and also create a test that does both with say a 2 minute application layer keep alive and tcp probes starting at 1 minute of inactivity Jan 08 23:35:53 and then contrast with no tcp probe being sent Jan 08 23:36:01 short intervals like 1 and 2 minutes will yield results :) Jan 08 23:36:18 unfortunately in order to be truly scientific about this we'd need 3 phones :) Jan 08 23:36:33 I'd also like to see an application which collects battery statistics allow for start/stop buttons to better understand battery load versus code, coding strategies, and various design decisions so it can be feed back for smart design decisions. Jan 08 23:36:39 i can provide that pretty soon actually. i'll be going to work for t-mobile in a couple of weeks Jan 08 23:36:54 jasta: ya, I know. I'm excited for you! Jan 08 23:36:59 BlindOracle: google already seems to do that, but it wouldn't be helpful for our purposes. Jan 08 23:37:16 the activity manager service has some BatteryStats collecting code. not sure what it does though Jan 08 23:37:32 jasta: really? I'll have to check that out. Jan 08 23:37:51 <_avatar> jasta: nice, what will you be doing there? software engineer? Jan 08 23:37:58 i only noticed it when i was hunting for some other issue, so i cant say that it is usable or even that it does what i think it does Jan 08 23:38:27 _avatar: yup, dev work. both on the framework and app dev Jan 08 23:38:31 but initially app dev Jan 08 23:38:34 jasta: well, if you get a chance to explore it a little, please let me know. I hope to have more time to explore such stuff in 30-45 days Jan 08 23:39:00 BlindOracle: i didn't mean to defeat your exploration into this area. i did not initially understand the concern you were bringing up :) Jan 08 23:39:41 that is, that you were trying to introduce changes into Android to explore this approach. i thought you were seriously advocating making use of this feature in practice. Jan 08 23:40:54 jasta: well, in practice, it won't hurt - which was my point. At 2-hour intervals, who cares. That might account for a fraction of a fraction of 1% of the total battery consumption in a day...assuming you ever get a connection to be idle for 2 hours. See my point. Jan 08 23:41:44 jasta: which is to say, I don't see most people going through the pains of creating a JNI wrapper to enable it for their application. Jan 08 23:41:49 in practice, you can't use it without JNI, and JNI is not officially supported. Jan 08 23:41:57 so, it's not practical :) Jan 08 23:42:04 for what is already a corner case - push type applications Jan 08 23:42:43 enabling it at the 2h interval is also pointless in practice, because you'll still need an application layer keep alive much tighter than that Jan 08 23:42:43 it's practical to enable will little to no *immediate* benefit and at likely zero cost. Jan 08 23:42:57 that is, unless google can be coached to reduce the defaults. Jan 08 23:43:13 jasta: exactly. so cost is pragmatically zero Jan 08 23:43:21 without research, i dont think google would act on your request. Jan 08 23:43:36 but it does "future proof" the app to some extend at a cost of zero. ;) Jan 08 23:43:38 well if cost and benefit are both zero, there isnt a case for doing it :) Jan 08 23:43:51 then its just confusing code hehe Jan 08 23:43:54 jasta: keep in mind that's at the app level Jan 08 23:44:23 anyway, if i can get some time to experiment i will. of course i'll need to wait until i have plenty of handsets :) Jan 08 23:45:02 jasta: hehe...hopefully adding one line of code doesn't constitute "confusing code"....hehe Jan 08 23:46:24 youre just trying to bait me aren't you? :) Jan 08 23:47:28 jasta: in the end, it's a low risk change with benefit to a small segment of applications (push plus some minute other corners) at the cost of battery - which is currently the only unknown. Jan 08 23:47:49 jasta: of course. Heck, at this point, if we can't bait and jab we've been wasting out time. ;) Jan 08 23:49:39 jasta: In all seriousness, I've enjoyed our exchange. Hopefully they won't be so "adversarial" in the future. Jan 08 23:49:47 night all Jan 09 00:06:55 I'm curious, how do those "toggle" apps disable/enable bluetooth when all the bluetooth APIs are hidden? I wonder how they accomplish that... Jan 09 00:08:04 there's probably an intent Jan 09 00:08:54 ah, true Jan 09 00:10:43 android.bluetooth.BluetoothIntent; Jan 09 00:51:30 romainguy_: do you know how the phone app has those toggle menu items? menu's seem to have a checkable property but i cant seem to make it do anything. Jan 09 01:08:52 is it a custom drawable underneith? Jan 09 01:09:37 jasta: like a stateful drawable that changes automatically based on checked state Jan 09 01:09:55 i dont think so, because it changes the position of the label as well. Jan 09 01:10:11 but maybe it could be by some voodoo Jan 09 01:10:30 * jasta ponders Jan 09 01:11:19 jasta: you mean the in-call menu? Jan 09 01:11:30 it doesnt change the label position for me :/ Jan 09 01:11:50 yeah it does. the label position of the menu item itself is higher up, and the check mark is down below Jan 09 01:12:34 O.O hmm im thinking of the green "lights" Jan 09 01:12:40 i havent seen a check mark Jan 09 01:12:47 me too Jan 09 01:12:56 i just called it a check mark for some reaosn Jan 09 01:13:14 normally the icon is on top, and the label is below it. but the green lights are below the label Jan 09 01:13:19 so obviously something special is happening Jan 09 01:13:58 well there's always the source ;) Jan 09 01:14:37 actually, i cant really find the source for the phone app. Jan 09 01:14:48 i mean, there's apps/Phone, but it doesnt seem to have what im looking for Jan 09 01:15:05 maybe im being dense. ill look again Jan 09 01:15:31 http://android.git.kernel.org/?p=platform/packages/apps/Phone.git;a=blob;f=src/com/android/phone/InCallMenu.java;h=2073a3bb190a3f56135b93efeb1a5bed27bd9488;hb=cupcake Jan 09 01:15:42 yeah i just stumbled upon that. Jan 09 01:15:56 and the Activity is http://android.git.kernel.org/?p=platform/packages/apps/Phone.git;a=blob;f=src/com/android/phone/InCallScreen.java;h=3c1656d4077b142bf182b9b038e7a8d32e337340;hb=cupcake Jan 09 01:16:02 this i did not expect Jan 09 01:16:53 oh, i see how i missed this :) Jan 09 01:17:11 this attaches everything to the options panel to do it Jan 09 02:35:38 the Market app is not open source right/ Jan 09 02:35:39 ? **** ENDING LOGGING AT Fri Jan 09 02:59:57 2009