| 00:01.15 | *** join/#android zhobbs (n=zach@132.245.8.67.cfl.res.rr.com) |
| 00:02.29 | *** join/#android The_PHP_Jedi (n=ThePHPJe@unaffiliated/thephpjedi/x-000002) |
| 00:07.34 | *** join/#android eton_ (n=eton@ppp-58-8-6-166.revip2.asianet.co.th) |
| 00:09.54 | *** join/#android edcba (i=edcba@nor75-17-82-67-199-204.fbx.proxad.net) |
| 00:11.10 | *** join/#android pombreda (n=pombreda@adsl-99-139-50-134.dsl.pltn13.sbcglobal.net) |
| 00:15.46 | *** join/#android eton (n=eton@ppp-58-8-2-180.revip2.asianet.co.th) |
| 00:39.13 | *** join/#android pombreda1 (n=pombreda@dsl017-042-218.sfo1.dsl.speakeasy.net) |
| 01:17.12 | sayers | How would I do a "Text area" |
| 01:24.28 | jasta | an edittext can do multi-line. |
| 01:24.59 | jasta | just let it grow to the size you want |
| 01:26.26 | *** join/#android zhobbs (n=zach@132.245.8.67.cfl.res.rr.com) |
| 01:29.47 | sayers | jasta, I can tell you know your android fairly well :P |
| 01:30.44 | sayers | Hm... wonder how I'd do a file browser... |
| 01:33.42 | *** join/#android pombreda (n=pombreda@h-68-165-170-124.snvacaid.dynamic.covad.net) |
| 01:37.07 | *** part/#android Dougie187 (n=doug@c-68-42-59-199.hsd1.fl.comcast.net) |
| 01:38.03 | jasta | sayers: we already did one |
| 01:38.07 | jasta | michaelnovakjr_ did. |
| 01:40.20 | jasta | its at android-random |
| 01:51.06 | *** join/#android chadkouse (n=chadkous@75-93-182-214.day.clearwire-dns.net) |
| 01:55.37 | sayers | jasta, :P |
| 01:57.46 | sayers | jasta, the one called glance? |
| 01:58.10 | jasta | yesh |
| 02:01.32 | sayers | Ah, well I think I'm going to doccument that code when I figure it out. |
| 02:02.40 | jasta | what's confusing about it (i haven't looked yet) |
| 02:05.16 | *** join/#android chadkouse (n=chadkous@75-93-182-214.day.clearwire-dns.net) |
| 02:05.28 | chadkouse | anyone familiar with a permission to allow your app to get to the internet ? |
| 02:07.53 | sayers | jasta, haha :) the whole thing mainly , being it an API it should have a docbook which I will add when I figure it out |
| 02:09.00 | jasta | sayers: what are you talking about? |
| 02:09.08 | sayers | that glance thing |
| 02:09.16 | sayers | I need a filebrowser so I can save and load |
| 02:09.19 | michaelnovakjr_ | hey sayers |
| 02:09.25 | sayers | howdy michaelnovakjr_ |
| 02:09.28 | *** join/#android SR71-Blackbird (n=nirvana@unaffiliated/sr71-blackbird) |
| 02:09.33 | michaelnovakjr_ | glance is still in development |
| 02:09.36 | jasta | sayers: how is that an API? |
| 02:10.03 | sayers | jasta, uhm, is it a library |
| 02:10.10 | jasta | no, it' snot. |
| 02:10.15 | sayers | I'm not sure the technical jargon for "I use that code to do stuff" |
| 02:10.30 | sayers | jasta, then why'd you tell me to look at it? |
| 02:10.32 | jasta | it is roughly that, through android's intents system. |
| 02:10.50 | sayers | __However__ a file browser should be in the sdk. |
| 02:11.01 | sayers | Seeing as that will be similar no matter the program and it'd look a lot better. |
| 02:11.07 | jasta | it's an android application, that browses and manages files. |
| 02:11.27 | jasta | sayers: that type of thing would be accomplished through intents in ANdroid |
| 02:11.29 | sayers | jasta, Well I'm comparing to Swings JFileChooser |
| 02:11.31 | jasta | and it need not be part of the SDK. |
| 02:11.43 | michaelnovakjr_ | sayers: different concept |
| 02:11.51 | jasta | the Intent idea, though, is kind of useless at the moment though. |
| 02:11.53 | sayers | What am I confused about then? |
| 02:12.06 | jasta | Since there's little community and hardly any demo applications that take advantage of it. |
| 02:12.08 | sayers | I should probably read more into the android philosophy |
| 02:12.09 | michaelnovakjr_ | glance is more like a nautilus than file chooser |
| 02:12.11 | jasta | So it's hard to really see how useful it will become. |
| 02:12.24 | sayers | michaelnovakjr_, ah I don't want that just yet |
| 02:12.45 | sayers | jasta, What is the intent concept about ? |
| 02:12.50 | michaelnovakjr_ | i'm installing apks via bluetooth right now so its handy |
| 02:13.24 | sayers | Intent looks like a class that will have easy methods for everything ? |
| 02:13.39 | jasta | lol |
| 02:14.11 | sayers | I guess I'm wrong. |
| 02:14.22 | jasta | it's not that, i just laughed at the way you said it. |
| 02:14.42 | jasta | what sort of meaning do you suppose "easy methods for everything" means? |
| 02:14.44 | sayers | They sure in the glossary make it sound like that |
| 02:14.53 | sayers | let me read the offical page |
| 02:15.18 | jasta | Intents are a mechanism in Android that allow you to access other applications, or parts of it, semantically. |
| 02:15.32 | jasta | That is, not by name, but by meaning. By your "intention". |
| 02:15.44 | sayers | ah |
| 02:16.02 | sayers | That is cool I guess, I didn't know it needed to be done that way. |
| 02:16.11 | jasta | So, for example, a contacts application might satisfy an intent to "pick a contact" |
| 02:16.19 | sayers | Well if you did it any other way apps would be huge... |
| 02:16.31 | jasta | It is how Android *can* become a composable set of applications that work together. |
| 02:16.43 | sayers | and you'd use the local instance of contacts to get the last one they entered or whatever... |
| 02:16.45 | jasta | It hardly does that now though, because there are too few applications to really see how the ecosystem will evolve. |
| 02:17.09 | jasta | sayers: What? No. You clearly do not understand. |
| 02:17.22 | sayers | jasta, Clearly :) |
| 02:17.44 | jasta | the alternative would be for every application that desired common functionality, such as browsing files, or picking a contact, or sending e-mails, etc. to implement that functionality for itself, rather than re-using existing applications that may or may exist concretely. |
| 02:18.03 | jasta | For example, there should be a general mechanism to say "compose a new e-mail". |
| 02:18.22 | jasta | that is different from saying "Launch Gmail", which is neither general nor directly what you mean. |
| 02:18.34 | sayers | Ah... |
| 02:18.36 | jasta | Intents, however, are not limited to applications Google creates for Android. |
| 02:18.43 | jasta | Any user-generated application can create new intents, that other applications can use. |
| 02:19.01 | sayers | jasta, is there any code showing this in very basics ? maybe that will help me. |
| 02:19.03 | jasta | So for example, my application is a music player. I can expose an intent to let another application choose a music file to use as a ring tone. |
| 02:19.16 | jasta | sayers: I'm sure there's lots. The only way to even open an activity is through intents. |
| 02:19.39 | sayers | I really need to read more about android :( |
| 02:19.49 | sayers | A lot of words flying across that are android specific |
| 02:19.52 | jasta | agreed. Stop wasting time on IRC and go read the documentation. |
| 02:20.43 | sayers | Where do you suggest I start, under reference information ? |
| 02:21.45 | jasta | code.google.com/android has lots of places you could start. |
| 02:21.49 | jasta | there's lots to read, and a lot of videos there |
| 02:21.59 | jasta | there are also the Google I/O videos, many of them i strongly recommend you view. |
| 02:22.16 | sayers | ah crap, I only have lined paper to print on :( |
| 02:22.18 | sayers | oh well |
| 02:22.50 | sayers | I'm going to start reading anatomy of an application |
| 02:24.04 | *** join/#android dims (n=dims@c-66-31-154-33.hsd1.ma.comcast.net) |
| 02:24.13 | *** join/#android eton (n=eton@ppp-58-8-8-29.revip2.asianet.co.th) |
| 02:29.55 | *** join/#android zhobbs (n=zach@132.245.8.67.cfl.res.rr.com) |
| 02:30.57 | sayers | jasta, I sort of get the idea of intent, I need to re-read it all but it is ingenious! |
| 02:33.27 | *** join/#android duey (n=duey@203-190-208-12.innovationwaikato.co.nz) |
| 02:34.33 | michaelnovakjr_ | how's it going jasta? |
| 02:35.30 | jasta | good |
| 02:35.50 | michaelnovakjr_ | figure out the ioctl stuff? |
| 02:37.27 | jasta | havent had a chance yet |
| 02:41.29 | michaelnovakjr_ | i'm playing around with installing apk's via bluetooth..... |
| 02:41.41 | michaelnovakjr_ | but the bluetooth from win mobile |
| 02:41.58 | michaelnovakjr_ | storing it on the sdcard and then glance putting it in the data/app directory |
| 02:43.01 | ttuttle | romainguy, romainguy_: good evening |
| 02:50.05 | michaelnovakjr_ | howdy |
| 02:50.10 | ttuttle | hi |
| 02:54.08 | michaelnovakjr_ | sayers: still around? |
| 03:05.02 | *** join/#android aculich1 (n=aculich@216-15-124-74.c3-0.smr-ubr3.sbo-smr.ma.cable.rcn.com) |
| 03:10.29 | sayers | michaelnovakjr_, yes |
| 03:24.28 | michaelnovakjr_ | did you take a look at glance? |
| 03:26.12 | *** join/#android umdk1d4 (n=umdk1d3@adsl-dynamic-64-79-45-15.bridgeband.net) |
| 03:27.44 | sayers | michaelnovakjr_, I took a glance at glance :p |
| 03:30.57 | romainguy_ | yo ttuttle |
| 03:36.07 | *** join/#android shoragan (n=shoragan@sicherheitsschwankung.de) |
| 03:38.30 | *** join/#android eton_ (n=eton@ppp-58-8-240-121.revip2.asianet.co.th) |
| 03:43.22 | sayers | michaelnovakjr_, what for? |
| 03:43.37 | michaelnovakjr_ | you were talking about it before |
| 03:46.11 | *** join/#android pandora-- (n=pandora@cpe-76-172-208-63.socal.res.rr.com) |
| 03:47.15 | sayers | michaelnovakjr_, there isn't much to look at currently :( |
| 04:04.23 | *** join/#android eton (n=eton@ppp-58-8-1-115.revip2.asianet.co.th) |
| 04:11.16 | *** join/#android yakischloba (n=jake@c-67-160-47-243.hsd1.wa.comcast.net) |
| 04:20.24 | *** join/#android eton_ (n=eton@ppp-58-8-6-12.revip2.asianet.co.th) |
| 04:26.21 | *** join/#android grah (n=grah@CPE-58-161-243-117.nsw.bigpond.net.au) |
| 04:27.17 | *** part/#android grah (n=grah@CPE-58-161-243-117.nsw.bigpond.net.au) |
| 04:27.44 | *** join/#android eton (n=eton@ppp-58-8-240-20.revip2.asianet.co.th) |
| 04:33.33 | *** join/#android eton (n=eton@ppp-58-8-240-30.revip2.asianet.co.th) |
| 04:36.43 | *** join/#android romainguy__ (n=gfx@69.36.227.131) |
| 04:36.57 | *** join/#android eton (n=eton@ppp-58-8-240-196.revip2.asianet.co.th) |
| 04:37.20 | *** join/#android romainguy___ (n=gfx@72.14.224.1) |
| 04:39.00 | *** join/#android lindever__ (n=eton@ppp-58-8-240-196.revip2.asianet.co.th) |
| 04:44.53 | *** join/#android lindever__ (n=eton@ppp-58-8-11-58.revip2.asianet.co.th) |
| 05:05.01 | *** join/#android dmoffett (n=dmoffett@71.33.240.149) |
| 05:32.23 | *** join/#android romainguy__ (n=gfx@adsl-76-241-19-32.dsl.pltn13.sbcglobal.net) |
| 05:34.48 | *** join/#android romainguy___ (n=gfx@72.14.224.1) |
| 05:42.26 | *** join/#android duey (n=Nick@203.96.223.40) |
| 05:51.13 | *** join/#android eton_ (n=eton@ppp-58-8-7-37.revip2.asianet.co.th) |
| 05:57.46 | *** join/#android pjz (n=pj@zachs.place.org) |
| 06:13.16 | *** join/#android eton_ (n=eton@ppp-58-8-240-190.revip2.asianet.co.th) |
| 06:58.50 | *** join/#android inZane- (i=nemo@dslb-084-058-027-065.pools.arcor-ip.net) |
| 07:06.57 | *** join/#android eton (n=eton@ppp-58-8-209-254.revip2.asianet.co.th) |
| 07:18.26 | *** join/#android shoragan (n=shoragan@debian/developer/shoragan) [NETSPLIT VICTIM] |
| 07:18.26 | *** join/#android borism (n=boris@195-50-206-65-dsl.krw.estpak.ee) |
| 07:18.26 | *** join/#android Hai-Fai (n=jarmo@hoasnet-fe35dd00-42.dhcp.inet.fi) [NETSPLIT VICTIM] |
| 07:18.26 | *** join/#android ttuttle (n=tom@pdpc/supporter/student/gentoo.contributor.ttuttle) [NETSPLIT VICTIM] |
| 07:18.26 | *** join/#android jarp (i=jii@nikita.tnnet.fi) [NETSPLIT VICTIM] |
| 07:18.26 | *** join/#android SUSaiyan (n=SUSaiyan@cc84863-b.zwoll1.ov.home.nl) [NETSPLIT VICTIM] |
| 07:18.26 | *** join/#android bjartek (n=bjartka@kremt.pvv.ntnu.no) [NETSPLIT VICTIM] |
| 07:18.26 | *** join/#android Miek (n=mike@unaffiliated/mikechml) [NETSPLIT VICTIM] |
| 07:18.27 | *** join/#android spykid (n=dh@alterpolis.net) [NETSPLIT VICTIM] |
| 07:19.14 | *** join/#android nslu2-log (n=nslu2-lo@limax.nslu2-linux.org) |
| 07:19.15 | *** join/#android Kraln (n=quassel@38.100.42.251) [NETSPLIT VICTIM] |
| 07:23.51 | *** join/#android lindever__ (n=eton@ppp-58-8-18-32.revip2.asianet.co.th) |
| 07:24.16 | *** join/#android alex2308 (n=alex2308@daloo.de) |
| 07:25.29 | alex2308 | morning no-longer-angry-at-me-dudez |
| 07:43.56 | *** join/#android okizo (n=chatzill@bgl93-3-82-230-208-124.fbx.proxad.net) |
| 08:06.41 | *** join/#android anno^da_ (n=anno^da@p5B07CE44.dip.t-dialin.net) |
| 08:10.41 | *** join/#android cutmasta (n=cutmasta@62.225.134.181) |
| 08:28.01 | *** join/#android romainguy__ (n=gfx@adsl-76-241-19-32.dsl.pltn13.sbcglobal.net) |
| 08:32.05 | *** join/#android romainguy___ (n=gfx@72.14.224.1) |
| 08:36.30 | *** join/#android mxcl (n=mxcl@hq.last.fm) |
| 08:42.46 | *** join/#android nowi (n=nowi@p57A0D149.dip.t-dialin.net) |
| 08:44.24 | *** join/#android rwhitby (n=rwhitby@nslu2-linux/rwhitby) |
| 09:27.14 | *** join/#android nowi_ (n=nowi@p57BB58BB.dip.t-dialin.net) |
| 09:32.44 | *** join/#android nowi (n=nowi@p57A0E4E1.dip.t-dialin.net) |
| 09:34.33 | *** join/#android mxcl (n=mxcl@hq.last.fm) |
| 09:40.23 | *** join/#android dueynz (n=duey@203.96.223.40) |
| 10:13.30 | *** join/#android mr_daniel (n=sysrq@rzdspc10.informatik.uni-hamburg.de) |
| 10:14.26 | *** join/#android nowi_ (n=nowi@p57A0EE17.dip.t-dialin.net) |
| 10:48.07 | *** part/#android rwhitby (n=rwhitby@nslu2-linux/rwhitby) |
| 10:49.43 | *** join/#android SUSaiyan (n=SUSaiyan@cc84863-b.zwoll1.ov.home.nl) |
| 10:57.28 | *** join/#android nowi (n=nowi@p57A0C79D.dip.t-dialin.net) |
| 11:02.31 | *** join/#android mxcl_ (n=mxcl@hq.last.fm) |
| 11:07.10 | *** join/#android nowi_ (n=nowi@p57A0DBA3.dip.t-dialin.net) |
| 11:30.12 | *** join/#android nowi (n=nowi@p57A0C78B.dip.t-dialin.net) |
| 11:37.41 | *** join/#android al2308 (n=alex2308@daloo.de) |
| 11:53.45 | *** join/#android nowi_ (n=nowi@p57A0D29A.dip.t-dialin.net) |
| 11:56.11 | *** join/#android alex2308 (n=alex2308@daloo.de) |
| 11:57.35 | *** join/#android mr_daniel (n=sysrq@rzdspc10.informatik.uni-hamburg.de) [NETSPLIT VICTIM] |
| 11:57.35 | *** join/#android nslu2-log (n=nslu2-lo@limax.nslu2-linux.org) |
| 11:57.35 | *** join/#android Kraln (n=quassel@38.100.42.251) [NETSPLIT VICTIM] |
| 11:59.14 | *** join/#android umdk1d3 (n=umdk1d3@adsl-dynamic-64-79-45-15.bridgeband.net) |
| 12:00.23 | *** join/#android nowi__ (n=nowi@p57A0E092.dip.t-dialin.net) |
| 12:08.13 | *** join/#android eton (n=eton@ppp-58-8-16-186.revip2.asianet.co.th) |
| 12:09.18 | *** join/#android eton_ (n=eton@ppp-58-8-16-186.revip2.asianet.co.th) |
| 12:22.19 | *** join/#android muthu (n=sushmu@59.92.68.145) |
| 12:38.58 | *** join/#android eton (n=eton@ppp-58-8-211-195.revip2.asianet.co.th) |
| 12:49.13 | *** join/#android zhobbs_ (n=zach@mail.guardianmfg.com) |
| 12:59.52 | *** join/#android mazzen (n=mortel@dhcp-ce168199.intern.uni-duisburg-essen.de) |
| 13:13.25 | *** join/#android aculich (n=aculich@pool-70-19-152-254.bos.east.verizon.net) |
| 13:14.13 | *** join/#android jsilvaa (n=jsilva@142.150.154.107) |
| 13:25.41 | *** join/#android mari (n=mari@offb-d9be22e2.pool.mediaWays.net) |
| 14:03.29 | *** join/#android krau (n=cktakaha@200.184.118.132) |
| 14:11.45 | *** join/#android yakischloba (n=jake@c-67-160-47-243.hsd1.wa.comcast.net) |
| 14:26.35 | *** join/#android SR71-Blackbird (n=nirvana@unaffiliated/sr71-blackbird) |
| 14:30.01 | *** join/#android cheng (n=cheng@141.76.49.20) |
| 14:31.40 | *** join/#android mluser-work (n=mluser-w@208.178.12.226) |
| 14:31.48 | *** join/#android Azalar (n=Azalar@unaffiliated/azalar) |
| 14:34.05 | *** join/#android sayers (n=sayers@c-76-20-182-119.hsd1.mi.comcast.net) |
| 14:38.42 | *** join/#android Dralspire2 (n=dralspir@unaffiliated/dralspire) |
| 15:01.05 | *** join/#android matt_c (n=mcroydon@gozur.sunflowerbroadband.com) |
| 15:32.11 | *** join/#android mr__daniel (n=sysrq@rzdspc10.informatik.uni-hamburg.de) |
| 15:40.27 | *** join/#android yakischloba (n=jake@rnkfoods.com) |
| 15:41.00 | jasta | yawn |
| 15:41.21 | *** join/#android romainguy__ (n=gfx@72.14.224.1) |
| 15:42.28 | yakischloba | so cold today and yesterday |
| 15:42.36 | yakischloba | i like it though. refreshing |
| 15:43.40 | jasta | yeah, its been nice |
| 15:46.41 | *** join/#android aculich (n=aculich@c-66-31-201-16.hsd1.ma.comcast.net) |
| 15:46.46 | yakischloba | I get a little out of my element when its super hot all the time |
| 15:49.26 | jasta | ditto |
| 15:49.34 | *** part/#android mari (n=mari@offb-d9be22e2.pool.mediaWays.net) |
| 16:13.59 | sayers | jasta, Should I watch the IO videos in : Introduction => Building 101 => Inside => Anatomy ? |
| 16:14.46 | jasta | sure, if you feel like there would be value. |
| 16:15.18 | sayers | It's always good to hear a person who knows it describe it. |
| 16:15.48 | romainguy__ | sayers: you should definitely what the IO videos |
| 16:15.57 | romainguy__ | it's a good way to understand Android application model |
| 16:16.00 | sayers | yes |
| 16:16.07 | sayers | A bit nicer than reading too |
| 16:16.09 | *** join/#android pombreda (n=pombreda@h-68-165-170-124.snvacaid.dynamic.covad.net) |
| 16:32.51 | *** join/#android zhobbs` (n=zach@132.245.8.67.cfl.res.rr.com) |
| 16:56.59 | *** part/#android djsiegel (n=david@il-la.la.idealab.com) |
| 17:00.47 | *** join/#android pandora-- (n=pandora-@66.238.50.126.ptr.us.xo.net) |
| 17:14.14 | *** join/#android SR71-Blackbird (n=nirvana@unaffiliated/sr71-blackbird) |
| 17:20.12 | *** join/#android cybereagle (n=cybereag@unaffiliated/cybereagle) |
| 17:22.16 | jasta | yawn |
| 17:22.35 | jasta | romainguy_: did you see my messages i think 2 days ago regarding the thread safety of HttpClient? |
| 17:22.51 | romainguy_ | I don't remember it |
| 17:22.58 | romainguy_ | but I don't know anything about HttpClient |
| 17:23.12 | romainguy_ | you'd be better off asking such questions to the Apache guys I guess |
| 17:23.30 | sayers | jasta, so intents are a high level way of saying I want a "picture to be viewed" and then the intent recievers would be notified and the end user could pick what app to use for said thing |
| 17:23.53 | *** part/#android muthu (n=sushmu@59.92.68.145) |
| 17:23.57 | romainguy_ | sayers: that's correct |
| 17:24.04 | sayers | yay! |
| 17:24.37 | romainguy_ | the user will be presented with a choice only if several receivers can respond to the intent |
| 17:24.42 | romainguy_ | otherwise it will just work :) |
| 17:24.56 | romainguy_ | it's a very effective way for apps to work with each other |
| 17:25.52 | jasta | romainguy_: ok, i'm just trying to get a better sense for how to properly manage threads in the Java and Android contexts. |
| 17:26.12 | jasta | because i think a lot of my initial work moved through the issue too quickly and made some false assumptions |
| 17:26.50 | jasta | there are some nuanced gotchas i've noticed. |
| 17:27.06 | jasta | specifically when you attempt to halt a thread that is busy waiting for I/O |
| 17:27.40 | sayers | I saw something interesting on the IO videos about having your application finished by sending android a message, what is the proper way to have an application closed? |
| 17:28.01 | jasta | sayers: applications do not manager their life cycle, they respond to the managers requests. |
| 17:28.42 | jasta | sayers: there is good documentation on this topic. lookup the Activity class documentation on the Android code page. |
| 17:29.39 | jasta | romainguy_: for example, I've noticed that Socket appears to be thread-safe in that one thread can be blocked in a read of its InputStream where another thread can issue a close to break the other thread out of its wait. |
| 17:30.25 | jasta | I have to assume then that the Socket's stream is also hardened against simultaneous invocations of close(), but I don't know how to verify that. |
| 17:30.53 | jasta | There are some good books on Java concurrency that I think I will pick up. |
| 17:32.49 | jasta | i saw this book in particular that looked thoughtful: http://www.amazon.com/Java-Threads-OReilly-Associates/dp/B00008CM3F/ref=pd_sim_b_3 |
| 17:35.10 | jasta | romainguy_: any thoughts? |
| 17:36.54 | *** join/#android eton_ (n=eton@ppp-58-8-6-215.revip2.asianet.co.th) |
| 17:38.01 | *** join/#android borism (n=boris@195-50-206-250-dsl.krw.estpak.ee) |
| 17:54.53 | *** join/#android eton (n=eton@ppp-58-8-1-240.revip2.asianet.co.th) |
| 17:59.09 | *** join/#android pombreda (n=pombreda@dsl017-042-218.sfo1.dsl.speakeasy.net) |
| 18:10.16 | *** join/#android SR71-Blackbird (n=nirvana@unaffiliated/sr71-blackbird) |
| 18:16.01 | *** join/#android eton_ (n=eton@ppp-58-8-3-242.revip2.asianet.co.th) |
| 18:22.35 | *** join/#android AttractiveApe (n=phil@office.gossamer-threads.com) |
| 18:23.02 | SanMehat | morning |
| 18:23.18 | AttractiveApe | hi :) |
| 18:23.35 | SanMehat | :) |
| 18:25.25 | *** join/#android soulreaper (n=soul@HSI-KBW-091-089-241-179.hsi2.kabel-badenwuerttemberg.de) |
| 18:26.31 | jasta | hello san |
| 18:26.39 | *** join/#android dasilvj (n=dasilvj@did75-1-81-57-20-118.fbx.proxad.net) |
| 18:39.30 | sayers | is there a way I can put text into an Edit Text but have it so they don't have to manually delete every charecter to use it? |
| 18:39.50 | zhobbs_ | android:hint="blah" |
| 18:41.36 | jasta | im glad they included hints ;) |
| 18:41.45 | jasta | lots of people would subclass EditText for that otherwise |
| 18:42.30 | zhobbs_ | yeah, it's nice |
| 18:42.35 | sayers | hm so don't set a text and instead use a hint? |
| 18:42.53 | jasta | romainguy_: *poke*, i am curious about your opinion ;) |
| 18:43.13 | zhobbs_ | sayers: yeah |
| 18:43.16 | zhobbs_ | sayers: and hint will disapear when they enter text |
| 18:43.30 | sayers | awesomepants! |
| 18:43.36 | sayers | this is almost to easy... |
| 18:44.14 | jasta | welcome to android development |
| 18:44.51 | zhobbs_ | yep...you can do really cool stuff really easily |
| 18:45.17 | jasta | Android is not a huge departure from a lot of matured toolkits and platforms, but what is very new is that you're doing it all so easily on a mobile phone :) |
| 18:45.31 | sayers | haha yep |
| 18:45.55 | jasta | sayers: Mobile development using J2ME, Symbian, Windows Mobile, etc is all nightmarish and frustrating. |
| 18:46.01 | sayers | very |
| 18:46.06 | sayers | I looked at j2me |
| 18:46.12 | zhobbs_ | jasta: just curious, what's a suggestion for a desktop toolkit/platform |
| 18:47.18 | zhobbs_ | I've only used QT, and .NET |
| 18:47.31 | jasta | zhobbs_: i particularly enjoy GTK, honestly, so maybe you don't want to respect my opinion :) |
| 18:48.07 | sayers | hehe |
| 18:48.18 | jasta | the programming maybe doesn't have as much syntactic sugar as most people would like, but it is very easy to produce beautiful UIs with it. consistent, well-defined UIs, even. |
| 18:48.39 | jasta | GLADE has also come a long way. I used it on Five and it worked great. |
| 18:49.21 | jasta | the new GObject stuff I don't like, though. |
| 18:51.51 | sayers | For some reason my hint seems to go on multiple lines even though I tell the EditText to wrap_content |
| 18:52.14 | jasta | sayers: android:single_line, or some such property. |
| 18:52.25 | jasta | wrap_content doesn't do what you think it does ;) |
| 18:52.29 | zhobbs_ | android:maxLines="1" maybe? |
| 18:52.33 | zhobbs_ | somethign like that |
| 18:52.41 | jasta | oh yeah, singleLine* ;) |
| 18:53.04 | zhobbs_ | android:lines="1" |
| 18:53.29 | jasta | sayers: wrap_content and fill_parent as applied to dimensions specify whether or not the widget should measure itself minimally or as large as it can fit in its parent. |
| 18:54.17 | jasta | so if you have an EditText with a height of wrap_content, it will happily grow to as large as necessary to fit all the text it's been asked to hold. |
| 18:54.24 | zhobbs_ | any attribute that starts with "layout_" get's passed to its container to tell its container how to draw it |
| 18:54.32 | jasta | Which is obviously what you'd want. Consider a TextView label for example. |
| 18:55.40 | sayers | jasta, what if it is in a row however |
| 18:55.56 | jasta | sayers: It doesn't matter, wrap_content roughly means "as big as necessary" |
| 18:56.18 | sayers | jasta, hm, well let me put this xml file up, it doesn't make sense, I'm pretty sure I'm following all the tips. |
| 18:56.23 | jasta | what you want is both wrap_content and a way to force the widget to draw only x number of lines. |
| 18:56.30 | jasta | which is a property of EditText and TextView |
| 18:57.17 | jasta | sayers: It does make sense, you just need to read the documented properties for these widets. |
| 18:57.17 | jasta | widgets* |
| 18:59.29 | sayers | http://pastebin.com/d7a0827fd jasta I've been reading as I go, and that XML file looks correct |
| 19:10.44 | *** join/#android aculich (n=aculich@c-66-31-201-16.hsd1.ma.comcast.net) |
| 19:15.06 | jasta | oh lord, why are you using Table? |
| 19:15.24 | ttuttle | LinearLayout++ |
| 19:15.37 | f00f- | layout++ |
| 19:15.43 | ttuttle | heh |
| 19:16.16 | zhobbs_ | no reason for table if there's only one column |
| 19:16.20 | sayers | jasta, I don't see a document on GUI development. |
| 19:16.55 | zhobbs_ | sayers: this may help: http://code.google.com/android/devel/ui/layout.html |
| 19:17.23 | sayers | great! |
| 19:17.26 | sayers | thank you |
| 19:24.49 | *** join/#android borism (n=boris@195-50-197-6-dsl.krw.estpak.ee) |
| 19:31.28 | jasta | sayers: start with LinearLayout first. it's the most general layout to use. |
| 19:33.05 | sayers | Alright will do |
| 19:36.48 | *** join/#android bdjnk (n=bdjnk@ool-4572ad23.dyn.optonline.net) |
| 19:40.05 | sayers | The linear layout doc is more a javadoc then an explanation |
| 19:42.33 | zhobbs_ | sayers: there are lots of resources out there though. The official google tutorial is good, apidemos is a good reference, anddev.org, helloandroid.com |
| 19:42.41 | *** join/#android AstainHellbring (n=Administ@unaffiliated/astainhellbring) |
| 19:43.01 | sayers | Ah, okay, I've been limiting my self to google's thus far. |
| 19:43.17 | zhobbs_ | well thats the best place to start |
| 19:47.56 | jasta | yeah, i would recommend google's docs over some of the community sites. |
| 19:48.20 | jasta | esp for this more elementary stuff |
| 19:48.36 | jasta | sayers: The concept of a linear layout is pretty simple. It's just packing boxes, which is found in lots of other UI toolkits. |
| 19:51.08 | *** join/#android foysavas (n=foysavas@pool-96-233-23-96.bstnma.east.verizon.net) |
| 19:52.37 | *** join/#android jsilvaa (n=jsilva@142.150.154.107) |
| 19:54.46 | romainguy_ | for what it's worth |
| 19:54.51 | romainguy_ | TableLayout is just a LinearLayout |
| 19:58.13 | sayers | So I can only have one item per "imaginary row" which is that widget per widget in Linear layout , as in I can't have two things side by side? |
| 19:59.07 | zhobbs_ | if you want 2 side by side on row just have a horizontal linearlayout on that row |
| 19:59.36 | zhobbs_ | <LL> <Widget1 /> <LL> <Widget A /> <Widget B /> </LL> </LL> |
| 19:59.41 | romainguy_ | or |
| 19:59.43 | romainguy_ | use a TableLayout |
| 19:59.46 | romainguy_ | it does that for you |
| 20:00.22 | zhobbs_ | romainguy_: can you have rows with different number of columns in a TableLayout? |
| 20:00.36 | romainguy_ | yes you can |
| 20:00.45 | romainguy_ | you can leave cells empty too |
| 20:00.51 | zhobbs_ | how do you do that? |
| 20:00.58 | romainguy_ | leave empty cells? |
| 20:01.26 | jasta | sayers: If you're trying to do like "Username: <EditText>\nPassword: <EditText>" with the texts lined up I'd rethink the design personally. |
| 20:02.06 | zhobbs_ | jasta: for that I use a TableLayout |
| 20:02.21 | zhobbs_ | romainguy_: yeah, how do I leave an empty cell on a row? |
| 20:02.52 | romainguy_ | use android:column="x" where X is the column where you want to put the item |
| 20:03.01 | romainguy_ | the next widget will be at x+1 |
| 20:03.17 | jasta | zhobbs_: What I meant was that the UI layout is all wrong, IMO. |
| 20:03.45 | jasta | Username: and Password: being on top of the EditText widgets looks nicer on a thin screen. |
| 20:05.36 | jasta | so if you are designing this layout for a portrait orientation, it would look very weird to have the label to the left of the edittext |
| 20:05.43 | jasta | the label would take up 1/3 or more of the width of the phone. |
| 20:06.52 | yakischloba | Is it easy to switch layouts based on orientation? |
| 20:07.10 | jasta | Yes, quite. |
| 20:07.40 | jasta | Well, kind of. In M5 it might be broken. The idea is that the layout and drawable directories can have options associated with them that belong to the resolution, orientation, etc. |
| 20:07.47 | jasta | But lots of that stuff is broken in M5 as it is documented. |
| 20:07.53 | yakischloba | oic |
| 20:09.41 | romainguy_ | jasta: implementations of InputStream are often synchronized, I know for instance that BufferedInputStream is, so attempting to close() from one thread while blocking on a read() in another is safe |
| 20:09.49 | *** join/#android eton (n=eton@ppp-58-8-1-230.revip2.asianet.co.th) |
| 20:09.57 | romainguy_ | but that can definitely depend on the implementation of InputStream you are using |
| 20:10.24 | romainguy_ | jasta: layouts based on orientations works just fine in M5 |
| 20:10.32 | jasta | romainguy_: it is difficult to determine that at times. for example, is URL#openStream()? |
| 20:11.09 | jasta | romainguy_: Must be resolution then. Or a combination of them. I can't remember, I have a filed bug about it somewhere on the issue list. |
| 20:11.27 | romainguy_ | you can always wrap the inputstream into another inputstream that you know is synchronized |
| 20:11.30 | romainguy_ | like BufferedInputStream |
| 20:11.57 | jasta | romainguy_: But that would dead lock for the case you're trying to use. |
| 20:12.09 | jasta | i.e., to interrupt a read by closing the socket. |
| 20:12.40 | jasta | and by "you're" I mean "I'm" :) |
| 20:14.22 | romainguy_ | not a real deadlock |
| 20:14.30 | romainguy_ | I'm pretty sure SocketInputStream has a timeout |
| 20:14.45 | jasta | Why wouldn't it be? One thread would synchronize read and hold the lock, the other would try to close and would need to wait for the read to finish. |
| 20:14.49 | jasta | That's a serious deadlock. |
| 20:14.53 | romainguy_ | that's not a deadlock |
| 20:15.04 | romainguy_ | that would be a deadlock if the read() could never finish |
| 20:15.16 | romainguy_ | it's just synchronization |
| 20:16.09 | romainguy_ | I confirm that socket input stream do timeout |
| 20:16.15 | jasta | the read() may not finish for quite some time, but I see what you mean. |
| 20:16.31 | jasta | Either way, your UI thread could become unresponsive for an arbitrary length of time. |
| 20:16.37 | jasta | Which is unacceptable. |
| 20:16.38 | romainguy_ | note that you can do it differently |
| 20:16.43 | romainguy_ | you can call close() on the Socket itself |
| 20:17.12 | romainguy_ | that will trigger an interrupt for the read |
| 20:17.19 | romainguy_ | and release the blocking call to read() |
| 20:18.49 | jasta | right, i know that is recommended for Socket, for instance. |
| 20:18.57 | jasta | but what about where that encapsulation is hidden from me, as is the case with URL#openStream? |
| 20:19.13 | jasta | what type of InputStream do I get, and is it synchronized in such a way that this starvation won't occur? |
| 20:19.23 | sayers | I know there is numbers only but that seems to prevent decimals, what is the alternative ? |
| 20:19.30 | romainguy_ | then just don't it this way |
| 20:19.33 | jasta | sayers: numbers only? |
| 20:19.35 | romainguy_ | just mark the reading thread as stopped |
| 20:19.44 | romainguy_ | and let the read timeout/finish/whatever, then bail out |
| 20:19.46 | jasta | and wait for it to die? |
| 20:19.52 | jasta | or rather, don't wait. |
| 20:19.56 | jasta | just let it die when it dies. |
| 20:19.57 | sayers | jasta, a modifier for EditText |
| 20:20.04 | jasta | sayers: huh? |
| 20:20.15 | romainguy_ | jasta: you can also probably send interrupt() to the thread |
| 20:20.35 | sayers | jasta, android:numeric = true |
| 20:20.36 | romainguy_ | usually a Thread is implemented by wrapping the execution code inside a try {} catch (InterruptedException e) |
| 20:20.40 | jasta | But interrupt will specifically not interrupt a blocking I/O operation, it says that in the documentation quite clearly. |
| 20:21.18 | jasta | sayers: Oh, that I don't know. If it doesn't have such a feature you'll have to subclass. |
| 20:21.54 | sayers | phone number suprisingly does the trick.. |
| 20:22.21 | jasta | I wouldn't recommend that. Don't specific phone number when you intend something else. The rules for phone number may change, and you can only be certain they will support phone numbers. |
| 20:22.25 | jasta | Not the input you need. |
| 20:24.00 | romainguy_ | jasta: then use non blocking i/o :) |
| 20:24.14 | romainguy_ | argh |
| 20:24.34 | romainguy_ | actually calling interrupt() on a thread blocked in I/O has different effect depending on the implementation |
| 20:24.57 | jasta | this seems like a problem that must have been well solved by now? |
| 20:25.03 | romainguy_ | hmm |
| 20:25.08 | jasta | for example, if i have a UI and i want to fire off an HTTP download, but i can it to be user cancellable. |
| 20:25.09 | romainguy_ | I don't know how the blocking I/O are implemented |
| 20:25.17 | romainguy_ | but if they rely on wait() then it will release the lock |
| 20:25.24 | romainguy_ | which means you can call close safely |
| 20:25.27 | jasta | HttpClient, for example, uses blocking I/O |
| 20:25.33 | jasta | and i imagine someone in that dev team had thought about it. |
| 20:25.46 | romainguy_ | you should write a simple example |
| 20:25.46 | jasta | Perhaps it is synchronized in a way that would prevent starvation. It wouldn't be too hard to do that, I'd think. |
| 20:25.54 | romainguy_ | and just call close() to see if it works |
| 20:25.59 | jasta | I did, actually, and it seems to behave as I expect. |
| 20:26.19 | jasta | But the problem is that it is very difficult to specifically test the blocking read, since without modifications to my networking environment read() would block only for a fraction of a second. |
| 20:26.25 | jasta | I can't detect that length of time very easily ;) |
| 20:26.41 | romainguy_ | can't you make a test that specifically block read for a long time? |
| 20:26.44 | jasta | Perhaps I will use iptables to starve the connection at a certain point and then test. |
| 20:27.07 | jasta | Let it work a few times, then after like 100k start DROP'ing packets. |
| 20:27.18 | jasta | so the read() should choke very abnormally |
| 20:27.43 | jasta | (btw, I really hope the Android networking stack is clever and can switch between towers, Wi-Fi, etc without interrupting connections *grin*) |
| 20:30.29 | jasta | Linux is capable of abstracting the network stack in this way, but not automatically :) |
| 20:30.41 | jasta | specifically, netfilter can. |
| 20:30.45 | jasta | Because it's uber. |
| 20:33.07 | jasta | Sigh, it starves :( |
| 20:33.26 | jasta | Definitely does. I got it to starve for about 50 seconds just there. |
| 20:34.38 | yakischloba | hmm. i just watched a bunch of the I/O videos. those were helpful |
| 20:35.05 | jasta | romainguy_: hehe, i can starve it for much longer too ;) |
| 20:35.18 | jasta | let ACKs get through and it will just seemingly sit here forever |
| 20:35.26 | tomgibara | jasta: if it's a cancellable HTTP download, you might be able to terminate the download by closing the connection on a separate thread |
| 20:36.46 | jasta | tomgibara: seems that's not the case, at least by using URL#openStream and close() on the stream. |
| 20:37.04 | jasta | i'll be happy to publish my code so someone can review it for correctness otherwise |
| 20:37.33 | jasta | romainguy_: this seems like something important to have well solved before you start encouranging lots of developers to embrace Android as an internet platform... |
| 20:38.19 | tomgibara | jasta: I remember being plagued by this in a project years ago but I can't remember the resolution |
| 20:38.42 | jasta | Now, I wonder if HttpClient synchronizes without starvation here... |
| 20:39.36 | jasta | it's definitely a synchronization problem. the main thread hangs doing close();, until such time as I release the read() call by opening up communication again. |
| 20:40.00 | jasta | this will be disasterous if these bugs plague most applications on Android, whose network connection will be quite unreliable by contrast to desktop machines. |
| 20:40.42 | tomgibara | I'm sure SocketChannel supports asycnhronous closing |
| 20:40.50 | yakischloba | what is all this? http client functionality is unable to fail gracefully in the event that the connection is lost? |
| 20:41.10 | romainguy_ | yakischloba: no, it's just jasta trying to force an input stream to stop blocking on a read |
| 20:41.24 | romainguy_ | jasta: just use non blocking I/O or do what I said, stop the thread and let it finish |
| 20:41.33 | jasta | how do you "just use non-blocking I/O" though? |
| 20:41.45 | romainguy_ | by using the non blocking I/O APIs ? |
| 20:41.51 | jasta | i thought you don't really get that option. if the API is blocking, you are blocking. |
| 20:42.03 | jasta | romainguy_: right, but do you suppose i'm going to implement an http client myself? |
| 20:43.18 | romainguy_ | can't you set a timeout on the connection? |
| 20:43.40 | jasta | It will be very ahrd to maintain state by just discarging references to threads and letting them die when they please. |
| 20:43.41 | tomgibara | jasta: I just checked the docs of SocketChannel, you can just call close() on a separate thread and the read() will terminate with -1 bytes read. |
| 20:43.46 | romainguy_ | I don't know anything about Apache's HttpClient, I never used it |
| 20:43.54 | jasta | For example, what if the user clicks a button to download a file and store it to /sdcard/Foo |
| 20:44.04 | jasta | then they hit cancel. then they click very soon after to download it again. |
| 20:44.04 | tomgibara | But yes, you need a HTTP layer built on top |
| 20:44.10 | jasta | The previous thread will have /sdcard/Foo open for writing |
| 20:44.14 | jasta | and so now will the new thread. |
| 20:44.56 | jasta | tomgibara: What would you recommend then? |
| 20:46.12 | jasta | I feel like this will be a disasterous problem for most third party developers to correctly maintain state of their applications in the event of network failure or user cancellation of network operations. |
| 20:46.24 | tomgibara | Well, first find out if the apache http client works on top of nio |
| 20:46.35 | jasta | tomgibara: It doesn't, AFAIK. |
| 20:46.50 | jasta | My test currently using URL#openStream, so I will try to adjust it to use HttpClient to see what its behaviour is. |
| 20:46.59 | jasta | is currently using* |
| 20:47.06 | romainguy_ | URL#openStream is not HttpClient |
| 20:47.11 | jasta | I know that. |
| 20:47.21 | jasta | That is exactly what I just said, even. |
| 20:47.22 | tomgibara | jasta: There seem to be two core modules "HttpCore base module" and "HttpCore NIO extensions" |
| 20:47.32 | jasta | tomgibara: both included with Android? |
| 20:48.09 | romainguy_ | All I know is that many changes occured in the HttpClient after M5 |
| 20:48.30 | jasta | By upstream or by you guys? |
| 20:48.42 | romainguy_ | I have no idea |
| 20:48.44 | romainguy_ | probably both |
| 20:48.51 | romainguy_ | I know we updated the version from upstream |
| 20:49.01 | jasta | is very concerned at the moment. |
| 20:49.02 | romainguy_ | again, I don't deal with that part of the system so... :) |
| 20:49.12 | jasta | I can already tell a lot of my code for Five makes assumptions which I have now proven to be false. |
| 20:49.30 | jasta | And that can cause serious starvation issues. |
| 20:50.01 | jasta | I can appreciate the strategy that you could just leave dangling threads and try to maintain their state to not be destructive once they eventually do pull out of read and error. |
| 20:50.15 | jasta | As in, have a stopped flag that you can check after read fails to figure out how to clean up. |
| 20:50.44 | jasta | I also wouldn't want dangling threads to prevent the application from being nuked by the OOM killer. |
| 20:50.52 | tomgibara | jasta: nio is not in M5 as far as I can tell |
| 20:51.06 | jasta | Likewise, if the thread has a handle to the activity's Handler, that could be bad if the application stops. |
| 20:51.07 | tomgibara | jasta: what I mean is the http core io extensions |
| 20:51.38 | *** part/#android michaelnovakjr__ (n=mnovak@96.56.111.166) |
| 20:52.41 | tomgibara | I was concerned about this when writing the moseycode app. I settled on a worker thread with a timeout |
| 20:53.01 | jasta | I am going to bring this issue up formally. Two reasons I am concerned about this. a) I want my application to be hardened against serious network failure, else its basic operation will be compromised, and b) I want there to be a clear concise set of best practices but forth for Android development when accessing the network. |
| 20:53.17 | jasta | tomgibara: And how do you cancel? Just interrupt it and forget about it? |
| 20:54.01 | jasta | Or do you potentially starve the UI by waiting for it to die? |
| 20:54.21 | romainguy_ | jasta: Android relies on standard Java APIs and the well known Apache HttpClient |
| 20:54.32 | romainguy_ | I'm sure many projects have tackled this issue already |
| 20:54.42 | romainguy_ | there's nothing fundamentally different about Android in this situation |
| 20:54.59 | jasta | romainguy_: I'm sure they have, but I haven't been able to find one yet. There's no reason this precludes starting the conversation in the Android community. |
| 20:55.05 | tomgibara | jasta: I didn't even interrupt, I had a flag that was checked after each read IIRC |
| 20:55.11 | romainguy_ | That's not what I'm saying |
| 20:55.16 | jasta | tomgibara: That's what I do in certain situations as well. |
| 20:55.37 | romainguy_ | I'm just saying that you don't have to be so dramatic about it :) |
| 20:55.49 | jasta | It would be irresponsible of Google not to publish an example of this, I think. |
| 20:56.24 | tomgibara | irresponsible seems like a strong word to use for this |
| 20:56.25 | jasta | romainguy_: Well so far this particularly community of developers does not have a solution that would work without introducing a lot of third party code into Android M5 ;) |
| 20:56.28 | f00f- | they dont have the publish an example |
| 20:56.30 | f00f- | it's not their code |
| 20:56.31 | romainguy_ | See, you're being dramatic again :) |
| 20:56.55 | romainguy_ | jasta: but the Android community should intersect with the larger Java community |
| 20:57.00 | romainguy_ | when it comes to the java.* APIs |
| 20:57.18 | tomgibara | Google have done the right thing here haven't they? They've a adopted a mature and open source http implementation |
| 20:57.19 | jasta | goes off to investigate HttpClient's implementation |
| 20:58.01 | jasta | f00f-: How about in your usage? What policy have you adopted? |
| 20:59.00 | f00f- | jasta: a timeout |
| 20:59.09 | jasta | I mean for cancellation. |
| 20:59.36 | tomgibara | jasta: It occurs to me that there might be a performance cost in providing http backed by nio |
| 20:59.49 | zhobbs_ | non-cancellable ProgressDialog ftw :) |
| 20:59.50 | f00f- | i dont handle cancellation, just ignore it if it's already been made (ie. http transaction sent) |
| 21:00.18 | f00f- | i dont have a use case where i would need to cancel an http request |
| 21:00.25 | jasta | tomgibara: how so? non-blocking I/O on most platforms is a performance win. |
| 21:00.34 | f00f- | zhobbs_: agreed :) |
| 21:00.55 | jasta | tomgibara: including Linux. |
| 21:00.59 | tomgibara | jasta: I expect it depends how its abstracted |
| 21:01.14 | zhobbs_ | f00f-: that is what I do, not bad if you have a reasonable timeout |
| 21:02.22 | f00f- | jasta: canceling a file upload, however, is definitely something that needs to be supported |
| 21:02.43 | f00f- | perhaps you can hook into a transmit handler |
| 21:02.54 | f00f- | or :) |
| 21:02.56 | f00f- | be sneaky |
| 21:03.01 | f00f- | and have your own inputstream |
| 21:03.07 | f00f- | that you have a magic interface to |
| 21:03.10 | f00f- | that'll return EOF or something |
| 21:03.13 | f00f- | when you desire cancelation |
| 21:03.20 | jasta | that wouldn't work. |
| 21:03.29 | f00f- | why not? |
| 21:03.31 | jasta | you can't just wrap a synchronization problem to fix it. |
| 21:03.43 | f00f- | i dont understand |
| 21:04.35 | jasta | a write is not the same problem anyway. |
| 21:05.10 | jasta | although it can be if you flood the kernel's buffer, but that's pretty unlikely. not that it invalidates the problem, i suppose. |
| 21:05.43 | f00f- | depends on the http client's transmit buffer |
| 21:05.51 | jasta | f00f-: no, it depends on the kernel's. |
| 21:06.05 | jasta | the kernel is the source that can block the write, if and only if it's send queue is full. |
| 21:06.25 | jasta | non-blocking I/O doesn't have this concern as it can simply issue writes when it knows the buffer to be ready. |
| 21:06.46 | jasta | but reads are a different story, as they don't just block when the buffer is full, they block instead when it is empty. |
| 21:06.53 | jasta | which means you're far more likely to catch them blocking |
| 21:06.53 | f00f- | right |
| 21:07.24 | f00f- | i was just suggesting to have it cancel using the fact that there is no lnoger any data to be sent |
| 21:07.27 | jasta | but regardless, the issue is not for normal operation of cancelling a functioning download or upload. |
| 21:07.41 | jasta | it's when you are trying to cancel a non-functional download or upload. one that is blocked potentially for a very long time. |
| 21:07.46 | jasta | up to its timeout, for example. |
| 21:08.01 | f00f- | just use a timeout then |
| 21:08.13 | jasta | even a sensible timeout of a connection of about 30 to 60s is WAY too long to block the UI. |
| 21:08.28 | jasta | f00f-: the issue is about synchronization the I/O thread with the main one, for explicit cancellation to preserve your stat.e |
| 21:08.33 | f00f- | 5-10 sec max imho |
| 21:08.35 | jasta | one strategy is to just tell it to stop, then forget about it. |
| 21:08.46 | jasta | 5-10 seconds for a transmit timeout on a mobile phone is a miserable idea f00f. |
| 21:09.11 | f00f- | i dont know |
| 21:09.31 | jasta | the other is to try to synchronize the cancellation, pulling the blocking thread out of its blocking call immediately. this latter strategy seems not to be possible in my tests. but i have yet to look at HttpClient. |
| 21:09.54 | jasta | but even still, 5-10s is too long to block the UI. 1s is too long to block the UI. |
| 21:10.06 | f00f- | use a progress dialog ;) |
| 21:10.10 | jasta | so it looks like the only workable strategy is to just let it die and not synchronize when or why. |
| 21:10.31 | jasta | f00f-: Your user will want to tear your head off if you make them wait up to 10s to cancel a simple operation. |
| 21:10.40 | jasta | Especially since they may likely want to cancel it because it's not working. |
| 21:10.53 | jasta | So now your app "doesn't work" for 10s just because they pressed the wrong button or something. |
| 21:11.26 | f00f- | clearly UI thread should be separate from HTTP thread |
| 21:11.38 | jasta | So, it seems without further research that the only sensible approach is to just tell the thread to stop and not bother synchronizing its death. |
| 21:11.58 | jasta | but rather to just code it in such a way that it can break out of the blcoking I/O at any time, and clean itself up gracefully in either event: success, failure, or cancellation. |
| 21:12.29 | tomgibara | jasta: fwiw, that was my conclusion |
| 21:12.38 | jasta | f00f-: Obviously, but again you aren't realizing what I'm saying. The policy decision that affects this is what you do when the user wants to cancel the HTTP thread. Do you interrupt the thread and just let it die, or do you try to synchronize its cancellation? |
| 21:13.55 | jasta | What we've been talking about, and my concern is, if you choose the latter strategy it seems you will starve the UI thread. |
| 21:14.11 | jasta | I was hoping to find a clean way to break the blocking thread out of it's I/O but it seems not possible reliably. |
| 21:14.30 | jasta | By cleanly, I mean without starvation. |
| 21:14.50 | jasta | tomgibara: Yeah, I'm starting to get there myself. But it seems like such a sloppy way to design your application. |
| 21:15.04 | jasta | Especially since other resources can be locked up because of the I/O thread. |
| 21:15.14 | jasta | For example, if you had an exclusive write lock on the output file. You can't gracefully remove it because the input stream is blocked. |
| 21:15.33 | jasta | Or a lock on some database table. Or in a transaction, etc. |
| 21:16.08 | tomgibara | jasta: I was more prosaic about it, it seemed like the best solution given the tradeoffs |
| 21:16.19 | jasta | Also, the thread probably has a reference to your activity's Handler, which means you'll need to be careful not to send messages to it that won't make any sense long after the user left your activity. |
| 21:16.22 | f00f- | jasta: you just cancel it and let it die. |
| 21:16.51 | jasta | continues to research this. Hopefully HttpClient will be different. |
| 21:16.55 | tomgibara | jasta: At least one has the hope that a starved read will be relatively rare |
| 21:16.57 | jasta | If not, I anxiously await NIO support in Android. |
| 21:17.09 | f00f- | do your research first about HttpClient, not sure why you would use anything else. |
| 21:17.10 | jasta | tomgibara: Rare has nothing to do with good design :) |
| 21:17.24 | jasta | f00f-: Yeah, I'm gonna go off and look at it now. |
| 21:17.40 | tomgibara | jasta: But everything to do with good engineering! |
| 21:17.53 | jasta | It seems like it should be possible, even if it's implementation specific. In other words, on Linux, you very much so can interrupt a blocking recv :) |
| 21:18.06 | jasta | tomgibara: What? No it doesn't. |
| 21:18.27 | f00f- | i believe my stream method might work |
| 21:18.34 | f00f- | in any situation |
| 21:18.41 | jasta | tomgibara: Engineers design buildings to withstand earthquakes even in cities that don't have them :) |
| 21:18.47 | tomgibara | jasta: Are you suggesting that good engineering doesn't involve trade-offs depending on the frequency at which certain situations arise? |
| 21:19.46 | jasta | tomgibara: I would state it a different way: Proper engineering is about respecting the severity of catastrophic events, not necessarily their frequency. |
| 21:20.50 | tomgibara | jasta: I think in part at least, it's about addressing risk which is loosely the product of severity and risk in my thinking. |
| 21:21.16 | f00f- | tomigabra |
| 21:21.19 | f00f- | you're in round 2 right |
| 21:21.19 | tomgibara | *second risk = frequency |
| 21:21.40 | tomgibara | f00f: only by virtue of helping out another team, yes |
| 21:21.50 | f00f- | i think i came across your web site |
| 21:21.54 | f00f- | while searching for spatial indexing |
| 21:21.57 | f00f- | is that you? |
| 21:22.07 | f00f- | z-order curve and hilbert curve stuff? |
| 21:22.07 | tomgibara | oh yeah, I came up with a really nice algorithm for that |
| 21:22.14 | tomgibara | that's me |
| 21:22.20 | f00f- | nice :) |
| 21:22.34 | f00f- | hopefully a little later i will implement such a aystem |
| 21:22.56 | tomgibara | what sort of system? |
| 21:23.14 | f00f- | essentially a list of POI's |
| 21:23.20 | f00f- | very simple, but needs very fast access |
| 21:23.52 | *** part/#android bluerive1 (n=qtameic@194.237.142.7) |
| 21:23.56 | f00f- | i'm stil trying to understand voronoi tesselations |
| 21:24.35 | tomgibara | f00f: yes them :-) |
| 21:26.34 | tomgibara | The nice thing about my clustering algorithm is that it's linear in the number of points clustered and memory usage is independent of that number. Of course it has its limitations because of this, but it means you can throw any number of points at it without worrying. |
| 21:27.26 | *** join/#android mr_daniel (n=sysrq@e177159134.adsl.alicedsl.de) |
| 21:28.01 | mickrobk_ | tomgibara: ur server is down, what is ur algo? |
| 21:28.31 | mickrobk_ | its funny, i just got all my spatial indexes to work 2 weeks ago |
| 21:28.53 | tomgibara | mickrobk: I just noticed - I need a new host - its a only static website |
| 21:30.07 | f00f- | tomgibara: a big question is can i stuff it into MySQL or do i need to roll my own |
| 21:30.27 | jasta | ponders |
| 21:30.47 | mickrobk_ | f00f- doesn't mysql have extensions for geodata? |
| 21:30.55 | tomgibara | mickrobk_: The details aren't published there, but in summary, it does a linear pass over the data, maintains a heap of point clusters that records the mean and variance, these are updated with each new point following the rule that the variance should be minimized at each step |
| 21:31.11 | tomgibara | Can't stuff it into MySQL I'm afraid |
| 21:31.15 | zhobbs | tomgibara: do you have a lot of traffic? I could probably host it for you if you're not sucking down too much bw |
| 21:31.24 | f00f- | mickrobk_: they have r-tree indexes but they suck and are not distributable horizontally |
| 21:31.50 | tomgibara | zhoobs: ha very little |
| 21:32.40 | tomgibara | zhobbs: I might take you up on that offer |
| 21:32.56 | zhobbs | tomgibara: sure, email me ( zach@zta-tech.com ) and I'll set you up |
| 21:34.21 | *** join/#android duey (n=duey@203-190-208-12.innovationwaikato.co.nz) |
| 21:35.08 | mickrobk_ | f00f-: their implementation sucks? |
| 21:35.59 | tomgibara | f00f: What does horizontal mean in that context? |
| 21:38.01 | jasta | interesting, it seems that closing the socket is supported, but the InputStream is synchronized in an entirely different way so closing it is not the same. |
| 21:38.18 | jasta | HttpClient's HttpMethodBase.abort() does close the socket, and thus does work. |
| 21:38.21 | jasta | Good to know. |
| 21:41.14 | jasta | I'll post my sample code for anyone curious. But it's gotta wait a bit, stepping into a meeting :) |
| 21:41.32 | jasta | this is platform specific too, but the major platforms do support it. |
| 21:41.40 | jasta | but java, specifically, does not. |
| 21:42.25 | jasta | that said, i'm happy to introduce a starvation for an unlikely event on a platform i can't imagine being. its better than the alternative :) |
| 21:45.05 | yakischloba | please do post when you get back jasta |
| 22:09.00 | *** join/#android mluser-work (n=mluser-w@208.178.12.226) |
| 22:21.53 | f00f- | mickrobk_ tomgibara well, afaik, it cant be clustered |
| 22:22.01 | f00f- | and r-tree indexes not supported on InnoDB |
| 22:22.26 | f00f- | i'm looking to scale to 100 million POI's |
| 22:40.06 | tomgibara | f00f-: What operations do you need to perform on that data? |
| 22:40.18 | *** join/#android Dougie187 (n=doug@c-68-42-59-199.hsd1.fl.comcast.net) |
| 22:41.57 | f00f- | tomgibara: basically nearby searches |
| 22:42.48 | f00f- | well how about this. you want to track 100 M+ objects/people |
| 22:43.18 | f00f- | static shouldnt be problem right |
| 22:43.27 | f00f- | but if those objects are moving around then it becomes a nightmare |
| 23:08.01 | tomgibara | f00f-: I can think of a few different ways of approaching the problem - none of them involve any sort of RDBMS |
| 23:08.59 | tomgibara | f00f-: I can't recall the details now, but there are spatial indices that are effecient for updates |
| 23:13.05 | f00f- | tomgibara: hmm, okay i was thinking to go the DIY route, but lots of work to write an implementation that is distributed like this |
| 23:13.19 | f00f- | ie. a horizontally scalable geospatial store |
| 23:14.28 | tomgibara | f00f-: Well a system that can efficiently do spatial queries on 100M frequently moving points probably doesn't lend itself to off-the-shelf solutions |
| 23:15.32 | f00f- | yeah i would agree :) |
| 23:15.40 | f00f- | i'm actually excited about develpoing it when i'm done with round 2 |
| 23:18.14 | tomgibara | f00f-: An obvious approach is to partition the space so that each partition contains approximately the same number of points, allocate each partition to a single server and use some standard software on that, and then patch something over the top to track points that move from one partition to another |
| 23:19.30 | tomgibara | f00f-: It's worth pointing out that 100M points is small enough to fit in memory and that a custom system that dealt with it that way might perform very well. |
| 23:20.11 | tomgibara | f00f-: Of course reliability issues might promote a distributed solution |
| 23:33.10 | f00f- | tomgibara: yes it would seem so, although i wonder about searches like: "find nearby restaurants serving vegetarian food" |
| 23:33.23 | f00f- | the non-spatial data would need to be stored elsewhere? in an RDBMS? |
| 23:41.23 | *** join/#android AstainHellbring (n=Administ@unaffiliated/astainhellbring) |
| 23:54.20 | *** join/#android BlackBsd (n=brian@72.168.193.117) |
| 23:56.38 | *** join/#android BlackBsd (n=brian@72.168.193.117) |