**** BEGIN LOGGING AT Thu Jul 24 02:59:56 2008 Jul 24 03:10:29 michaelnovakjr_, yes Jul 24 03:24:28 did you take a look at glance? Jul 24 03:27:44 michaelnovakjr_, I took a glance at glance :p Jul 24 03:30:58 yo ttuttle Jul 24 03:43:23 michaelnovakjr_, what for? Jul 24 03:43:37 you were talking about it before Jul 24 03:47:15 michaelnovakjr_, there isn't much to look at currently :( Jul 24 07:25:29 morning no-longer-angry-at-me-dudez Jul 24 15:41:00 yawn Jul 24 15:42:29 so cold today and yesterday Jul 24 15:42:36 i like it though. refreshing Jul 24 15:43:40 yeah, its been nice Jul 24 15:46:46 I get a little out of my element when its super hot all the time Jul 24 15:49:27 ditto Jul 24 16:14:00 jasta, Should I watch the IO videos in : Introduction => Building 101 => Inside => Anatomy ? Jul 24 16:14:47 sure, if you feel like there would be value. Jul 24 16:15:18 It's always good to hear a person who knows it describe it. Jul 24 16:15:48 sayers: you should definitely what the IO videos Jul 24 16:15:57 it's a good way to understand Android application model Jul 24 16:16:00 yes Jul 24 16:16:07 A bit nicer than reading too Jul 24 17:22:16 yawn Jul 24 17:22:36 romainguy_: did you see my messages i think 2 days ago regarding the thread safety of HttpClient? Jul 24 17:22:51 I don't remember it Jul 24 17:22:58 but I don't know anything about HttpClient Jul 24 17:23:13 you'd be better off asking such questions to the Apache guys I guess Jul 24 17:23:30 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 Jul 24 17:23:57 sayers: that's correct Jul 24 17:24:04 yay! Jul 24 17:24:37 the user will be presented with a choice only if several receivers can respond to the intent Jul 24 17:24:42 otherwise it will just work :) Jul 24 17:24:56 it's a very effective way for apps to work with each other Jul 24 17:25:52 romainguy_: ok, i'm just trying to get a better sense for how to properly manage threads in the Java and Android contexts. Jul 24 17:26:12 because i think a lot of my initial work moved through the issue too quickly and made some false assumptions Jul 24 17:26:50 there are some nuanced gotchas i've noticed. Jul 24 17:27:06 specifically when you attempt to halt a thread that is busy waiting for I/O Jul 24 17:27:40 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? Jul 24 17:28:01 sayers: applications do not manager their life cycle, they respond to the managers requests. Jul 24 17:28:42 sayers: there is good documentation on this topic. lookup the Activity class documentation on the Android code page. Jul 24 17:29:39 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. Jul 24 17:30:26 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. Jul 24 17:30:53 There are some good books on Java concurrency that I think I will pick up. Jul 24 17:32:49 i saw this book in particular that looked thoughtful: http://www.amazon.com/Java-Threads-OReilly-Associates/dp/B00008CM3F/ref=pd_sim_b_3 Jul 24 17:35:10 romainguy_: any thoughts? Jul 24 18:23:02 morning Jul 24 18:23:18 hi :) Jul 24 18:23:35 :) Jul 24 18:26:31 hello san Jul 24 18:39:30 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? Jul 24 18:39:50 android:hint="blah" Jul 24 18:41:36 im glad they included hints ;) Jul 24 18:41:45 lots of people would subclass EditText for that otherwise Jul 24 18:42:30 yeah, it's nice Jul 24 18:42:35 hm so don't set a text and instead use a hint? Jul 24 18:42:53 romainguy_: *poke*, i am curious about your opinion ;) Jul 24 18:43:06 sayers: yeah Jul 24 18:43:16 sayers: and hint will disapear when they enter text Jul 24 18:43:30 awesomepants! Jul 24 18:43:36 this is almost to easy... Jul 24 18:44:14 welcome to android development Jul 24 18:44:51 yep...you can do really cool stuff really easily Jul 24 18:45:17 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 :) Jul 24 18:45:31 haha yep Jul 24 18:45:55 sayers: Mobile development using J2ME, Symbian, Windows Mobile, etc is all nightmarish and frustrating. Jul 24 18:46:01 very Jul 24 18:46:07 I looked at j2me Jul 24 18:46:13 jasta: just curious, what's a suggestion for a desktop toolkit/platform Jul 24 18:47:18 I've only used QT, and .NET Jul 24 18:47:31 zhobbs_: i particularly enjoy GTK, honestly, so maybe you don't want to respect my opinion :) Jul 24 18:48:04 hehe Jul 24 18:48:18 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. Jul 24 18:48:39 GLADE has also come a long way. I used it on Five and it worked great. Jul 24 18:49:22 the new GObject stuff I don't like, though. Jul 24 18:51:51 For some reason my hint seems to go on multiple lines even though I tell the EditText to wrap_content Jul 24 18:52:14 sayers: android:single_line, or some such property. Jul 24 18:52:25 wrap_content doesn't do what you think it does ;) Jul 24 18:52:30 android:maxLines="1" maybe? Jul 24 18:52:33 somethign like that Jul 24 18:52:41 oh yeah, singleLine* ;) Jul 24 18:53:04 android:lines="1" Jul 24 18:53:29 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. Jul 24 18:54:17 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. Jul 24 18:54:24 any attribute that starts with "layout_" get's passed to its container to tell its container how to draw it Jul 24 18:54:32 Which is obviously what you'd want. Consider a TextView label for example. Jul 24 18:55:40 jasta, what if it is in a row however Jul 24 18:55:56 sayers: It doesn't matter, wrap_content roughly means "as big as necessary" Jul 24 18:56:18 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. Jul 24 18:56:23 what you want is both wrap_content and a way to force the widget to draw only x number of lines. Jul 24 18:56:31 which is a property of EditText and TextView Jul 24 18:56:44 sayers: It does make sense, you just need to read the documented properties for these widets. Jul 24 18:56:47 widgets* Jul 24 18:59:30 http://pastebin.com/d7a0827fd jasta I've been reading as I go, and that XML file looks correct Jul 24 19:15:06 oh lord, why are you using Table? Jul 24 19:15:24 LinearLayout++ Jul 24 19:15:37 layout++ Jul 24 19:15:42 heh Jul 24 19:16:16 no reason for table if there's only one column Jul 24 19:16:21 jasta, I don't see a document on GUI development. Jul 24 19:16:55 sayers: this may help: http://code.google.com/android/devel/ui/layout.html Jul 24 19:17:24 great! Jul 24 19:17:26 thank you Jul 24 19:31:28 sayers: start with LinearLayout first. it's the most general layout to use. Jul 24 19:33:05 Alright will do Jul 24 19:40:05 The linear layout doc is more a javadoc then an explanation Jul 24 19:42:33 sayers: there are lots of resources out there though. The official google tutorial is good, apidemos is a good reference, anddev.org, helloandroid.com Jul 24 19:43:02 Ah, okay, I've been limiting my self to google's thus far. Jul 24 19:43:18 well thats the best place to start Jul 24 19:47:57 yeah, i would recommend google's docs over some of the community sites. Jul 24 19:48:21 esp for this more elementary stuff Jul 24 19:48:36 sayers: The concept of a linear layout is pretty simple. It's just packing boxes, which is found in lots of other UI toolkits. Jul 24 19:54:46 for what it's worth Jul 24 19:54:51 TableLayout is just a LinearLayout Jul 24 19:58:13 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? Jul 24 19:59:07 if you want 2 side by side on row just have a horizontal linearlayout on that row Jul 24 19:59:37 Jul 24 19:59:41 or Jul 24 19:59:44 use a TableLayout Jul 24 19:59:46 it does that for you Jul 24 20:00:22 romainguy_: can you have rows with different number of columns in a TableLayout? Jul 24 20:00:36 yes you can Jul 24 20:00:45 you can leave cells empty too Jul 24 20:00:51 how do you do that? Jul 24 20:00:58 leave empty cells? Jul 24 20:01:27 sayers: If you're trying to do like "Username: \nPassword: " with the texts lined up I'd rethink the design personally. Jul 24 20:02:06 jasta: for that I use a TableLayout Jul 24 20:02:21 romainguy_: yeah, how do I leave an empty cell on a row? Jul 24 20:02:52 use android:column="x" where X is the column where you want to put the item Jul 24 20:03:01 the next widget will be at x+1 Jul 24 20:03:17 zhobbs_: What I meant was that the UI layout is all wrong, IMO. Jul 24 20:03:45 Username: and Password: being on top of the EditText widgets looks nicer on a thin screen. Jul 24 20:05:36 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 Jul 24 20:05:43 the label would take up 1/3 or more of the width of the phone. Jul 24 20:07:02 Is it easy to switch layouts based on orientation? Jul 24 20:07:10 Yes, quite. Jul 24 20:07:40 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. Jul 24 20:07:47 But lots of that stuff is broken in M5 as it is documented. Jul 24 20:07:54 oic Jul 24 20:09:41 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 Jul 24 20:09:57 but that can definitely depend on the implementation of InputStream you are using Jul 24 20:10:24 jasta: layouts based on orientations works just fine in M5 Jul 24 20:10:32 romainguy_: it is difficult to determine that at times. for example, is URL#openStream()? Jul 24 20:11:10 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. Jul 24 20:11:27 you can always wrap the inputstream into another inputstream that you know is synchronized Jul 24 20:11:31 like BufferedInputStream Jul 24 20:11:57 romainguy_: But that would dead lock for the case you're trying to use. Jul 24 20:12:10 i.e., to interrupt a read by closing the socket. Jul 24 20:12:40 and by "you're" I mean "I'm" :) Jul 24 20:14:22 not a real deadlock Jul 24 20:14:30 I'm pretty sure SocketInputStream has a timeout Jul 24 20:14:45 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. Jul 24 20:14:49 That's a serious deadlock. Jul 24 20:14:54 that's not a deadlock Jul 24 20:15:05 that would be a deadlock if the read() could never finish Jul 24 20:15:16 it's just synchronization Jul 24 20:16:10 I confirm that socket input stream do timeout Jul 24 20:16:16 the read() may not finish for quite some time, but I see what you mean. Jul 24 20:16:31 Either way, your UI thread could become unresponsive for an arbitrary length of time. Jul 24 20:16:37 Which is unacceptable. Jul 24 20:16:39 note that you can do it differently Jul 24 20:16:43 you can call close() on the Socket itself Jul 24 20:17:13 that will trigger an interrupt for the read Jul 24 20:17:19 and release the blocking call to read() Jul 24 20:18:50 right, i know that is recommended for Socket, for instance. Jul 24 20:18:58 but what about where that encapsulation is hidden from me, as is the case with URL#openStream? Jul 24 20:19:13 what type of InputStream do I get, and is it synchronized in such a way that this starvation won't occur? Jul 24 20:19:24 I know there is numbers only but that seems to prevent decimals, what is the alternative ? Jul 24 20:19:30 then just don't it this way Jul 24 20:19:33 sayers: numbers only? Jul 24 20:19:35 just mark the reading thread as stopped Jul 24 20:19:44 and let the read timeout/finish/whatever, then bail out Jul 24 20:19:46 and wait for it to die? Jul 24 20:19:53 or rather, don't wait. Jul 24 20:19:57 just let it die when it dies. Jul 24 20:19:57 jasta, a modifier for EditText Jul 24 20:20:05 sayers: huh? Jul 24 20:20:15 jasta: you can also probably send interrupt() to the thread Jul 24 20:20:36 jasta, android:numeric = true Jul 24 20:20:36 usually a Thread is implemented by wrapping the execution code inside a try {} catch (InterruptedException e) Jul 24 20:20:41 But interrupt will specifically not interrupt a blocking I/O operation, it says that in the documentation quite clearly. Jul 24 20:22:03 sayers: Oh, that I don't know. If it doesn't have such a feature you'll have to subclass. Jul 24 20:22:05 phone number suprisingly does the trick.. Jul 24 20:22:22 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. Jul 24 20:22:26 Not the input you need. Jul 24 20:24:00 jasta: then use non blocking i/o :) Jul 24 20:24:14 argh Jul 24 20:24:35 actually calling interrupt() on a thread blocked in I/O has different effect depending on the implementation Jul 24 20:24:57 this seems like a problem that must have been well solved by now? Jul 24 20:25:03 hmm Jul 24 20:25:08 for example, if i have a UI and i want to fire off an HTTP download, but i can it to be user cancellable. Jul 24 20:25:09 I don't know how the blocking I/O are implemented Jul 24 20:25:17 but if they rely on wait() then it will release the lock Jul 24 20:25:24 which means you can call close safely Jul 24 20:25:27 HttpClient, for example, uses blocking I/O Jul 24 20:25:33 and i imagine someone in that dev team had thought about it. Jul 24 20:25:46 you should write a simple example Jul 24 20:25:46 Perhaps it is synchronized in a way that would prevent starvation. It wouldn't be too hard to do that, I'd think. Jul 24 20:25:55 and just call close() to see if it works Jul 24 20:25:59 I did, actually, and it seems to behave as I expect. Jul 24 20:26:19 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. Jul 24 20:26:25 I can't detect that length of time very easily ;) Jul 24 20:26:42 can't you make a test that specifically block read for a long time? Jul 24 20:26:44 Perhaps I will use iptables to starve the connection at a certain point and then test. Jul 24 20:27:07 Let it work a few times, then after like 100k start DROP'ing packets. Jul 24 20:27:19 so the read() should choke very abnormally Jul 24 20:27:44 (btw, I really hope the Android networking stack is clever and can switch between towers, Wi-Fi, etc without interrupting connections *grin*) Jul 24 20:30:29 Linux is capable of abstracting the network stack in this way, but not automatically :) Jul 24 20:30:41 specifically, netfilter can. Jul 24 20:30:46 Because it's uber. Jul 24 20:33:07 Sigh, it starves :( Jul 24 20:33:26 Definitely does. I got it to starve for about 50 seconds just there. Jul 24 20:34:38 hmm. i just watched a bunch of the I/O videos. those were helpful Jul 24 20:35:06 romainguy_: hehe, i can starve it for much longer too ;) Jul 24 20:35:18 let ACKs get through and it will just seemingly sit here forever Jul 24 20:35:26 jasta: if it's a cancellable HTTP download, you might be able to terminate the download by closing the connection on a separate thread Jul 24 20:36:46 tomgibara: seems that's not the case, at least by using URL#openStream and close() on the stream. Jul 24 20:37:04 i'll be happy to publish my code so someone can review it for correctness otherwise Jul 24 20:37:34 romainguy_: this seems like something important to have well solved before you start encouranging lots of developers to embrace Android as an internet platform... Jul 24 20:38:19 jasta: I remember being plagued by this in a project years ago but I can't remember the resolution Jul 24 20:38:42 Now, I wonder if HttpClient synchronizes without starvation here... Jul 24 20:39:37 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. Jul 24 20:40:00 this will be disasterous if these bugs plague most applications on Android, whose network connection will be quite unreliable by contrast to desktop machines. Jul 24 20:40:42 I'm sure SocketChannel supports asycnhronous closing Jul 24 20:40:51 what is all this? http client functionality is unable to fail gracefully in the event that the connection is lost? Jul 24 20:41:10 yakischloba: no, it's just jasta trying to force an input stream to stop blocking on a read Jul 24 20:41:24 jasta: just use non blocking I/O or do what I said, stop the thread and let it finish Jul 24 20:41:33 how do you "just use non-blocking I/O" though? Jul 24 20:41:45 by using the non blocking I/O APIs ? Jul 24 20:41:51 i thought you don't really get that option. if the API is blocking, you are blocking. Jul 24 20:42:03 romainguy_: right, but do you suppose i'm going to implement an http client myself? Jul 24 20:43:18 can't you set a timeout on the connection? Jul 24 20:43:40 It will be very ahrd to maintain state by just discarging references to threads and letting them die when they please. Jul 24 20:43:41 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. Jul 24 20:43:47 I don't know anything about Apache's HttpClient, I never used it Jul 24 20:43:54 For example, what if the user clicks a button to download a file and store it to /sdcard/Foo Jul 24 20:44:04 then they hit cancel. then they click very soon after to download it again. Jul 24 20:44:04 But yes, you need a HTTP layer built on top Jul 24 20:44:11 The previous thread will have /sdcard/Foo open for writing Jul 24 20:44:14 and so now will the new thread. Jul 24 20:44:56 tomgibara: What would you recommend then? Jul 24 20:46:12 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. Jul 24 20:46:25 Well, first find out if the apache http client works on top of nio Jul 24 20:46:35 tomgibara: It doesn't, AFAIK. Jul 24 20:46:51 My test currently using URL#openStream, so I will try to adjust it to use HttpClient to see what its behaviour is. Jul 24 20:46:59 is currently using* Jul 24 20:47:06 URL#openStream is not HttpClient Jul 24 20:47:11 I know that. Jul 24 20:47:21 That is exactly what I just said, even. Jul 24 20:47:22 jasta: There seem to be two core modules "HttpCore base module" and "HttpCore NIO extensions" Jul 24 20:47:32 tomgibara: both included with Android? Jul 24 20:48:10 All I know is that many changes occured in the HttpClient after M5 Jul 24 20:48:30 By upstream or by you guys? Jul 24 20:48:42 I have no idea Jul 24 20:48:44 probably both Jul 24 20:48:51 I know we updated the version from upstream Jul 24 20:49:01 * jasta is very concerned at the moment. Jul 24 20:49:02 again, I don't deal with that part of the system so... :) Jul 24 20:49:12 I can already tell a lot of my code for Five makes assumptions which I have now proven to be false. Jul 24 20:49:30 And that can cause serious starvation issues. Jul 24 20:50:01 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. Jul 24 20:50:15 As in, have a stopped flag that you can check after read fails to figure out how to clean up. Jul 24 20:50:45 I also wouldn't want dangling threads to prevent the application from being nuked by the OOM killer. Jul 24 20:50:52 jasta: nio is not in M5 as far as I can tell Jul 24 20:51:06 Likewise, if the thread has a handle to the activity's Handler, that could be bad if the application stops. Jul 24 20:51:07 jasta: what I mean is the http core io extensions Jul 24 20:52:41 I was concerned about this when writing the moseycode app. I settled on a worker thread with a timeout Jul 24 20:53:02 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. Jul 24 20:53:17 tomgibara: And how do you cancel? Just interrupt it and forget about it? Jul 24 20:54:02 Or do you potentially starve the UI by waiting for it to die? Jul 24 20:54:21 jasta: Android relies on standard Java APIs and the well known Apache HttpClient Jul 24 20:54:32 I'm sure many projects have tackled this issue already Jul 24 20:54:43 there's nothing fundamentally different about Android in this situation Jul 24 20:54:59 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. Jul 24 20:55:05 jasta: I didn't even interrupt, I had a flag that was checked after each read IIRC Jul 24 20:55:11 That's not what I'm saying Jul 24 20:55:16 tomgibara: That's what I do in certain situations as well. Jul 24 20:55:37 I'm just saying that you don't have to be so dramatic about it :) Jul 24 20:55:49 It would be irresponsible of Google not to publish an example of this, I think. Jul 24 20:56:25 irresponsible seems like a strong word to use for this Jul 24 20:56:25 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 ;) Jul 24 20:56:28 they dont have the publish an example Jul 24 20:56:30 it's not their code Jul 24 20:56:32 See, you're being dramatic again :) Jul 24 20:56:55 jasta: but the Android community should intersect with the larger Java community Jul 24 20:57:00 when it comes to the java.* APIs Jul 24 20:57:18 Google have done the right thing here haven't they? They've a adopted a mature and open source http implementation Jul 24 20:57:19 * jasta goes off to investigate HttpClient's implementation Jul 24 20:58:01 f00f-: How about in your usage? What policy have you adopted? Jul 24 20:59:00 jasta: a timeout Jul 24 20:59:09 I mean for cancellation. Jul 24 20:59:36 jasta: It occurs to me that there might be a performance cost in providing http backed by nio Jul 24 20:59:50 non-cancellable ProgressDialog ftw :) Jul 24 20:59:51 i dont handle cancellation, just ignore it if it's already been made (ie. http transaction sent) Jul 24 21:00:18 i dont have a use case where i would need to cancel an http request Jul 24 21:00:25 tomgibara: how so? non-blocking I/O on most platforms is a performance win. Jul 24 21:00:34 zhobbs_: agreed :) Jul 24 21:00:55 tomgibara: including Linux. Jul 24 21:00:59 jasta: I expect it depends how its abstracted Jul 24 21:01:14 f00f-: that is what I do, not bad if you have a reasonable timeout Jul 24 21:02:22 jasta: canceling a file upload, however, is definitely something that needs to be supported Jul 24 21:02:43 perhaps you can hook into a transmit handler Jul 24 21:02:55 or :) Jul 24 21:02:56 be sneaky Jul 24 21:03:01 and have your own inputstream Jul 24 21:03:07 that you have a magic interface to Jul 24 21:03:10 that'll return EOF or something Jul 24 21:03:13 when you desire cancelation Jul 24 21:03:20 that wouldn't work. Jul 24 21:03:29 why not? Jul 24 21:03:31 you can't just wrap a synchronization problem to fix it. Jul 24 21:03:43 i dont understand Jul 24 21:04:35 a write is not the same problem anyway. Jul 24 21:05:10 although it can be if you flood the kernel's buffer, but that's pretty unlikely. not that it invalidates the problem, i suppose. Jul 24 21:05:44 depends on the http client's transmit buffer Jul 24 21:05:51 f00f-: no, it depends on the kernel's. Jul 24 21:06:06 the kernel is the source that can block the write, if and only if it's send queue is full. Jul 24 21:06:25 non-blocking I/O doesn't have this concern as it can simply issue writes when it knows the buffer to be ready. Jul 24 21:06:46 but reads are a different story, as they don't just block when the buffer is full, they block instead when it is empty. Jul 24 21:06:53 which means you're far more likely to catch them blocking Jul 24 21:06:53 right Jul 24 21:07:24 i was just suggesting to have it cancel using the fact that there is no lnoger any data to be sent Jul 24 21:07:27 but regardless, the issue is not for normal operation of cancelling a functioning download or upload. Jul 24 21:07:41 it's when you are trying to cancel a non-functional download or upload. one that is blocked potentially for a very long time. Jul 24 21:07:46 up to its timeout, for example. Jul 24 21:08:01 just use a timeout then Jul 24 21:08:13 even a sensible timeout of a connection of about 30 to 60s is WAY too long to block the UI. Jul 24 21:08:28 f00f-: the issue is about synchronization the I/O thread with the main one, for explicit cancellation to preserve your stat.e Jul 24 21:08:33 5-10 sec max imho Jul 24 21:08:36 one strategy is to just tell it to stop, then forget about it. Jul 24 21:08:46 5-10 seconds for a transmit timeout on a mobile phone is a miserable idea f00f. Jul 24 21:09:12 i dont know Jul 24 21:09:32 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. Jul 24 21:09:55 but even still, 5-10s is too long to block the UI. 1s is too long to block the UI. Jul 24 21:10:06 use a progress dialog ;) Jul 24 21:10:10 so it looks like the only workable strategy is to just let it die and not synchronize when or why. Jul 24 21:10:31 f00f-: Your user will want to tear your head off if you make them wait up to 10s to cancel a simple operation. Jul 24 21:10:40 Especially since they may likely want to cancel it because it's not working. Jul 24 21:10:53 So now your app "doesn't work" for 10s just because they pressed the wrong button or something. Jul 24 21:11:26 clearly UI thread should be separate from HTTP thread Jul 24 21:11:38 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. Jul 24 21:11:58 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. Jul 24 21:12:29 jasta: fwiw, that was my conclusion Jul 24 21:12:38 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? Jul 24 21:13:55 What we've been talking about, and my concern is, if you choose the latter strategy it seems you will starve the UI thread. Jul 24 21:14:12 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. Jul 24 21:14:30 By cleanly, I mean without starvation. Jul 24 21:14:51 tomgibara: Yeah, I'm starting to get there myself. But it seems like such a sloppy way to design your application. Jul 24 21:15:03 Especially since other resources can be locked up because of the I/O thread. Jul 24 21:15:14 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. Jul 24 21:15:33 Or a lock on some database table. Or in a transaction, etc. Jul 24 21:16:08 jasta: I was more prosaic about it, it seemed like the best solution given the tradeoffs Jul 24 21:16:19 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. Jul 24 21:16:22 jasta: you just cancel it and let it die. Jul 24 21:16:52 * jasta continues to research this. Hopefully HttpClient will be different. Jul 24 21:16:55 jasta: At least one has the hope that a starved read will be relatively rare Jul 24 21:16:57 If not, I anxiously await NIO support in Android. Jul 24 21:17:09 do your research first about HttpClient, not sure why you would use anything else. Jul 24 21:17:10 tomgibara: Rare has nothing to do with good design :) Jul 24 21:17:24 f00f-: Yeah, I'm gonna go off and look at it now. Jul 24 21:17:40 jasta: But everything to do with good engineering! Jul 24 21:17:54 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 :) Jul 24 21:18:06 tomgibara: What? No it doesn't. Jul 24 21:18:27 i believe my stream method might work Jul 24 21:18:34 in any situation Jul 24 21:18:41 tomgibara: Engineers design buildings to withstand earthquakes even in cities that don't have them :) Jul 24 21:18:47 jasta: Are you suggesting that good engineering doesn't involve trade-offs depending on the frequency at which certain situations arise? Jul 24 21:19:46 tomgibara: I would state it a different way: Proper engineering is about respecting the severity of catastrophic events, not necessarily their frequency. Jul 24 21:20:50 jasta: I think in part at least, it's about addressing risk which is loosely the product of severity and risk in my thinking. Jul 24 21:21:16 tomigabra Jul 24 21:21:19 you're in round 2 right Jul 24 21:21:19 *second risk = frequency Jul 24 21:21:40 f00f: only by virtue of helping out another team, yes Jul 24 21:21:50 i think i came across your web site Jul 24 21:21:54 while searching for spatial indexing Jul 24 21:21:57 is that you? Jul 24 21:22:07 z-order curve and hilbert curve stuff? Jul 24 21:22:08 oh yeah, I came up with a really nice algorithm for that Jul 24 21:22:14 that's me Jul 24 21:22:20 nice :) Jul 24 21:22:34 hopefully a little later i will implement such a aystem Jul 24 21:22:56 what sort of system? Jul 24 21:23:14 essentially a list of POI's Jul 24 21:23:20 very simple, but needs very fast access Jul 24 21:23:56 i'm stil trying to understand voronoi tesselations Jul 24 21:24:35 f00f: yes them :-) Jul 24 21:26:34 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. Jul 24 21:28:01 tomgibara: ur server is down, what is ur algo? Jul 24 21:28:31 its funny, i just got all my spatial indexes to work 2 weeks ago Jul 24 21:28:53 mickrobk: I just noticed - I need a new host - its a only static website Jul 24 21:30:07 tomgibara: a big question is can i stuff it into MySQL or do i need to roll my own Jul 24 21:30:28 * jasta ponders Jul 24 21:30:47 f00f- doesn't mysql have extensions for geodata? Jul 24 21:30:55 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 Jul 24 21:31:11 Can't stuff it into MySQL I'm afraid Jul 24 21:31:15 tomgibara: do you have a lot of traffic? I could probably host it for you if you're not sucking down too much bw Jul 24 21:31:24 mickrobk_: they have r-tree indexes but they suck and are not distributable horizontally Jul 24 21:31:51 zhoobs: ha very little Jul 24 21:32:40 zhobbs: I might take you up on that offer Jul 24 21:32:56 tomgibara: sure, email me ( zach@zta-tech.com ) and I'll set you up Jul 24 21:35:08 f00f-: their implementation sucks? Jul 24 21:35:59 f00f: What does horizontal mean in that context? Jul 24 21:38:01 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. Jul 24 21:38:19 HttpClient's HttpMethodBase.abort() does close the socket, and thus does work. Jul 24 21:38:22 Good to know. Jul 24 21:41:14 I'll post my sample code for anyone curious. But it's gotta wait a bit, stepping into a meeting :) Jul 24 21:41:32 this is platform specific too, but the major platforms do support it. Jul 24 21:41:40 but java, specifically, does not. Jul 24 21:42:25 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 :) Jul 24 21:45:05 please do post when you get back jasta Jul 24 22:21:53 mickrobk_ tomgibara well, afaik, it cant be clustered Jul 24 22:22:01 and r-tree indexes not supported on InnoDB Jul 24 22:22:26 i'm looking to scale to 100 million POI's Jul 24 22:40:06 f00f-: What operations do you need to perform on that data? Jul 24 22:41:57 tomgibara: basically nearby searches Jul 24 22:42:48 well how about this. you want to track 100 M+ objects/people Jul 24 22:43:18 static shouldnt be problem right Jul 24 22:43:27 but if those objects are moving around then it becomes a nightmare Jul 24 23:08:01 f00f-: I can think of a few different ways of approaching the problem - none of them involve any sort of RDBMS Jul 24 23:08:59 f00f-: I can't recall the details now, but there are spatial indices that are effecient for updates Jul 24 23:13:06 tomgibara: hmm, okay i was thinking to go the DIY route, but lots of work to write an implementation that is distributed like this Jul 24 23:13:19 ie. a horizontally scalable geospatial store Jul 24 23:14:29 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 Jul 24 23:15:32 yeah i would agree :) Jul 24 23:15:41 i'm actually excited about develpoing it when i'm done with round 2 Jul 24 23:18:15 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 Jul 24 23:19:30 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. Jul 24 23:20:11 f00f-: Of course reliability issues might promote a distributed solution Jul 24 23:33:10 tomgibara: yes it would seem so, although i wonder about searches like: "find nearby restaurants serving vegetarian food" Jul 24 23:33:24 the non-spatial data would need to be stored elsewhere? in an RDBMS? Jul 25 00:52:10 yakischloba: i'm posting that example now Jul 25 00:52:35 sweet. Jul 25 00:52:44 sounds like something that would be important to know in the future. Jul 25 00:52:53 yes, probably :) Jul 25 01:08:50 What is the more appreciated way of saving text-like data with android, on the SD card or in a sql db? Jul 25 01:09:08 That would depend on what the data is.. Jul 25 01:09:22 and how you plan to use it. Jul 25 01:09:40 and whether or not you want to require that your users have SD cards. Jul 25 01:09:54 Well I plan on using it in a Database like structure but I don't know to much about how quick the Sql db is on the phone Jul 25 01:10:07 then you should use sqlite, obviously. Jul 25 01:10:16 sqlite can run on a wrist watch. don't worry about it ;) Jul 25 01:10:22 alright Jul 25 01:10:23 i assure you, the performance of sqlite3 will greatly exceed whatever you come up with on a flat file. Jul 25 01:10:31 wowza Jul 25 01:10:45 Just have to figure out how to use sqllite 3 Jul 25 01:11:47 thats what I'm figuring out right now. I'm used to MySQL as far as writing my own queries. Jul 25 01:12:19 I've done very little database work so it'll be new either way Jul 25 01:12:24 sqlite3 has great documentation. Jul 25 01:12:29 yay Jul 25 01:12:36 the example Notes application gives some good basic examples of how to use it with android. Jul 25 01:12:41 sayers: why yay? you haven't been reading any documentation so far :) Jul 25 01:12:52 jasta, Yes I have! Jul 25 01:13:26 I just tend to ask broad questions here which point me at the documentation :) Jul 25 01:19:52 sqlite looks like its going to annoy me. Jul 25 01:20:05 why do you say that Jul 25 01:23:37 looks like its harder to do date/time stuff than in other dbs. i don't see stuff like timediff() Jul 25 01:24:16 not that this is actually a problem. i'm just crying Jul 25 01:39:17 yakischloba, just use java features? Jul 25 01:39:41 sayers: thats what I'm doing, obviously. I was just hoping to use something I already knew how to use ;) Jul 25 01:39:52 Ah Jul 25 01:40:15 So I guess its up to the developer to decide how they want to store dates in sqlite Jul 25 01:40:21 Well, I don't think running through that tutorial will help me.. I think I'll have to learn by writing and fixing Jul 25 01:40:24 unix timestamp format I think?.. Jul 25 01:40:48 sayers: if you don't understand relational databases then thats the first step Jul 25 01:41:10 I still need a bit more Android work I think. Jul 25 01:42:03 yakischloba: yeah, in sqlite3, there are basically only 3 types, TEXT, BLOB, and variouses sizes of integers. Jul 25 01:42:07 various* Jul 25 01:42:20 There's no date/time type as far as the storage is concerned. Jul 25 01:42:28 jasta: yeah. So I assume the most efficient way is to store it as an integer? Jul 25 01:42:32 So, you declare a field DATE or TIME simply as an aesthetic ;) Jul 25 01:42:49 Generally the UNIX timestamp in UTC is a good strategy for storing times, yes. Jul 25 01:42:54 Ok. Jul 25 01:43:39 Do note that Java insists on describing and interpreting times as the UNIX timestamp but in milliseconds, not seconds. Jul 25 01:45:00 yeah I'm reading that now Jul 25 01:46:01 sigh, i might have to admit defeat on this lame blocking I/O problem :) Jul 25 01:46:20 the big gotcha left here is that you obviously can't use this trick to close a socket which hasn't been opened yet. Jul 25 01:46:37 so, if it's hanging in a blocked connect(), there's nothing you can do but wait for the socket timeout. Jul 25 01:47:09 which means you essentially cannot safely synchronize the death of the I/O thread. Jul 25 01:47:18 :( Jul 25 01:47:40 at least for the common case you can nuke it quickly. Jul 25 01:47:54 but a blocking connect() is not so rare. a host that is not responding to you, for example, would do it. Jul 25 01:48:54 Well, shot. Jul 25 01:48:57 shoot* Jul 25 01:49:33 I guess you could use a hybrid strategy here... Jul 25 01:49:57 it would simplify the code non-the-less to know that ONLY executeMethod is uninterruptible Jul 25 01:57:50 would I want to look up activities to figure out how to forward one activity to the next? Jul 25 02:02:40 alas it's in the api demo Jul 25 02:03:00 ;) Jul 25 02:03:59 I forgot about them and now that I'm only 90% out of the android concepts they sorta make sense :D /me does happy dance Jul 25 02:48:44 What designates one XML layout for one class and another xml layout for another class? Jul 25 02:53:04 the tags used Jul 25 02:53:08 elements specify classes Jul 25 02:53:14 android classes are autoscoped Jul 25 02:53:17 if using own calss Jul 25 02:53:21 specify full package path Jul 25 02:53:29 ei oh ei....is there a better tool for diagrams than Visio? Jul 25 02:55:46 f00f-, so that is done on every tag before android ? Jul 25 02:58:23 I don't see that in any of the examples **** ENDING LOGGING AT Fri Jul 25 02:59:57 2008