**** BEGIN LOGGING AT Tue Aug 12 02:59:56 2008 Aug 12 05:54:17 hi davidw Aug 12 05:54:57 "'morning" Aug 12 05:55:39 hoy Aug 12 05:58:23 okay I need to sleep now Aug 12 05:58:33 looks to be another long day tomorrow :) Aug 12 05:58:41 so, "night", davidw :) Aug 12 05:59:18 romainguy, manana Aug 12 08:54:18 could someone tell me why the EditText gets destroyed when I type more than the line height defined in the layout ? Aug 12 08:54:23 It looks like this: http://img.skitch.com/20080812-tqc8rprxp5uw34p49f6fcuqywa.jpg Aug 12 08:56:31 ne art notizanwendung? Aug 12 08:57:43 ne ne nur das roh layout für nen Mini Blogging Tool. Und so langsam nervt mich das Textfeld :) Aug 12 09:02:27 wart doch aufs neue SDK :) Aug 12 09:02:57 bau nen eigenes Aug 12 09:03:02 also textfeld ;-) Aug 12 09:05:14 Joa später :-) Aug 12 09:05:33 Im Moment hab ich keinen Nerv mehr :D. So langsam hasse ich UI erstellen *g* Aug 12 09:05:55 sowieso, darum ist meine so minimal wie es geht Aug 12 09:06:17 obwohl ne netstat anwendung sicherlich nett wäre Aug 12 09:23:09 I can't read German - perhaps your question was answered, but what do you mean by destroyed? Aug 12 09:27:17 :). If I put more than the 8 lines inside the EditText field it breaks I cant scroll down and the widget doesnt react any more. I can type but I cant see anything. On top of the widget you can see that their is the orange line missing. It starts missing after I reach the last line. Aug 12 09:27:40 I can make a video that shows better what I mean it is a bit hard to describe Aug 12 09:28:01 That's what I thought you meant Aug 12 09:28:58 http://code.google.com/p/android/issues/detail?id=744 Aug 12 09:29:28 That bug almost killed me in the ADC Aug 12 09:30:30 ok the next time I'm looking in the buglist I promise. Why do I always come across the bugs :D Aug 12 09:30:48 :) Aug 12 09:32:03 But well the bloggin with Tumblr works thats all I want *g* Aug 12 11:42:27 anyone is familiar with marketing? Aug 12 11:42:39 banner-ad prices and stuff Aug 12 11:48:48 How can I use a Surface View that is created in code into my XML layout ? I know that I could do it with add view. But how can I setup the sorting. For example having 2 buttons inside a Linear Layout and the Surface should be above the buttons. Aug 12 11:53:15 maybe. addView(View child, int index) Aug 12 11:53:33 addView(mySurfaceView, 0); Aug 12 11:53:36 thanks I will try that. Aug 12 11:54:06 or even "-1" as the buttons may have "0" and "1" already Aug 12 11:55:18 yeah I will try that :-) Aug 12 11:55:30 but it could be right. Aug 12 12:00:25 linear.addView(preview,-1, new LayoutParams(LayoutParams.WRAP_CONTENT, LayoutParams.WRAP_CONTENT)); <- but it tells me that the layout parameters are wrong. If I do a simple "addContentView" the parameters are taken for the Surface. Aug 12 12:01:49 and not setting parameters leads me to no parameters set :P Aug 12 12:11:52 check the imports Aug 12 12:12:14 this produces no code-errors: Aug 12 12:12:28 myLinLay.addView(mySurfaceView,0, new ViewGroup.LayoutParams(ViewGroup.LayoutParams.WRAP_CONTENT, ViewGroup.LayoutParams.WRAP_CONTENT)); Aug 12 12:15:36 hmm I'm getting InvalidParams supplied to android.widget.LinearLayout@.... Aug 12 12:16:46 http://nopaste.info/f53ba124a5.html Aug 12 12:17:04 (sorry for the indents they are caused by the no paste site) Aug 12 12:19:53 hm, then try Linearlayout.Layoutparams: http://nopaste.info/d4c9cf3f65.html Aug 12 12:20:44 why don't you "add" it by working with setVisibility(View.GONE); or similar? Aug 12 12:21:38 no marketing-guy here? Aug 12 12:22:16 Well I created the SurfaceView (a camera preview) in the activity so I cant use it directly in the XML file. So I have to add it. Or is there something wrong in my understanding ? Aug 12 12:23:43 Your last example made it working Aug 12 12:23:46 thank! Aug 12 12:23:49 :) Aug 12 12:23:50 +s Aug 12 12:23:55 Dankeschön :-) Aug 12 12:24:00 Kein Problem Aug 12 12:33:41 Now I got another problem. Adding the SurfaceView this way it isnt visible anymore after an onResume. Adding it just with addContentView(sv) the resume behaviour works just fine. Do I have to save my whole View tree when the activuty is interrupted ? Aug 12 13:06:04 o/ Aug 12 13:36:47 howdy Aug 12 13:48:33 michaelnovakjr: hi Aug 12 13:48:45 howdy Aug 12 13:48:49 what's up Aug 12 13:50:56 yop Aug 12 14:00:28 mh, am i the only one that hates that data-base crap on android? :( Aug 12 14:00:33 *database Aug 12 14:00:48 no Aug 12 14:01:03 it could be better Aug 12 14:01:38 buster: what's wrong with it? Aug 12 14:02:10 I'd be fine if there were just standard tables we would access with raw querys. Aug 12 14:02:16 i mean this contactmethots, columns, projection, etc. etc. stuff Aug 12 14:02:25 plusminus_: yes! Aug 12 14:02:44 contentprovider needs some work Aug 12 14:03:22 i am just trying to figure out how to get the email from a contact with phone number X. i think i did it some weeks ago, but cant remember, and its all weird, about contactmethods, preferredamilkind, and what not :( Aug 12 14:03:29 dude Aug 12 14:03:32 *preferred_email Aug 12 14:03:42 the database implementation on android is awesome Aug 12 14:04:44 buster its very simple actually Aug 12 14:05:55 dont think so Aug 12 14:06:08 getEmailFromTelnr(X) would be very simple ;) Aug 12 14:06:54 oh, ok...ContentProviders Aug 12 14:07:00 getContentProvider().query(random confusing arguments and arrays which are defined through dozens constants in dozens classes) is not, imho Aug 12 14:07:14 agree Aug 12 14:07:17 thought you meant the SQLite implementation Aug 12 14:07:24 uh Aug 12 14:07:25 \sender = cur.getString( cur.getColumnIndex( android.provider.Contacts.PeopleColumns.NAME ) ); Aug 12 14:07:37 that's not difficult Aug 12 14:07:41 its how to get the cursor Aug 12 14:08:22 normally i would just do "select name, email from x where x=y Aug 12 14:08:23 and done Aug 12 14:08:48 Cursor cur = managedQuery( android.provider.Contacts.People.CONTENT_URI, null, where condition, null ); Aug 12 14:08:57 anyway, i didn't mean to whine ;p Aug 12 14:08:59 where it says where condition you put what you are using to search Aug 12 14:09:15 Moseycode takes another small step forwards: http://www.youtube.com/watch?v=KyvkVFr5ij4 Aug 12 14:09:37 tomgibara: wonderful! Aug 12 14:09:56 buster, it is extremely simple Aug 12 14:10:20 michaelnovakjr: no. emails are hidden somewhere else i think Aug 12 14:10:20 muthu: It's my first proper 3D demonstration - still has some way to go though. Aug 12 14:10:36 buster, you pull that column instead Aug 12 14:10:47 well but I have to aggree with buster if you come from a web background and do a lot of database stuff raw queries are definetly mich easier Aug 12 14:11:09 tomgibara: wtf, you are insane... Aug 12 14:11:50 tomgibara: damn, that is slick! Aug 12 14:12:02 wtf, tomgibara Aug 12 14:12:03 plusminus_: probably, btw I finally replied to your email! Sorry about the delay. Aug 12 14:12:04 nice Aug 12 14:12:26 http://code.google.com/android/reference/android/provider/Contacts.ContactMethods.html --- buster check that out Aug 12 14:13:06 tomgibara: got it, fine Aug 12 14:13:29 moseycode, really cool Aug 12 14:13:46 thx everyone, I've been beating myself around the head trying to get the maths right - it's such a relief to finally get something working Aug 12 14:14:09 tomgibara: what's a real world use case? Aug 12 14:14:13 tomgibara: will it take long to port it to android? Aug 12 14:14:39 michaelnovakjr: yeah, i know, but thanks. its confusing although ;p Aug 12 14:14:50 moseycode rocks :) Aug 12 14:15:04 plusminus_: That is my android code base, but with a JMF/OpenGL wrapper to accomodate the missing android hardware Aug 12 14:15:16 ive shown it my colleague and he also says it rocks :) Aug 12 14:15:38 muthu: Several advertisers are interested. Aug 12 14:16:40 plusminus_: Of course real world performance is completely unknown, I can't do anything about that without hardware (damn it!) Aug 12 14:17:32 muthu: serveral use-cases will arise Aug 12 14:17:36 think of that Aug 12 14:18:14 you see a poster of a movie and point your camera on it. Suddenly the poster becomes alive, showing the trailer1 Aug 12 14:18:24 that would be stunning Aug 12 14:18:29 wow! Aug 12 14:18:34 yay Aug 12 14:18:35 <3 Aug 12 14:18:40 that would be neat Aug 12 14:18:40 :D Aug 12 14:18:41 neat Aug 12 14:18:44 one use-case I would really like to pursue is games Aug 12 14:18:52 each person shares the same board (in 3D possibly) Aug 12 14:18:56 tomgibara that is very slick. Aug 12 14:19:02 but they don't necessarily see the same things Aug 12 14:19:06 as you see its really possible (the trailer thing) Aug 12 14:19:18 eg. fog of war effects are possible Aug 12 14:20:02 imo moseycode will rock in Adc2 with real devices Aug 12 14:20:15 i'd bet my nuts... Aug 12 14:20:28 especially with it running on a mobile phone - each person can sit around the same pieces (marked with barcodes) Aug 12 14:20:29 hah Aug 12 14:20:56 but only the player who owns the piece can see the private information - that sort of thing. Aug 12 14:27:39 want want want want! :) Aug 12 14:27:54 want what/ Aug 12 14:27:55 ? Aug 12 14:30:38 moseycode <3 Aug 12 14:31:42 I'd google for it, but my ISP's DNS seems to be down at the moment. Aug 12 14:32:17 Darkeye11547: http://www.youtube.com/watch?v=KyvkVFr5ij4 Aug 12 14:32:30 Sorry, no DNS. Aug 12 14:32:51 I'd click, but I'd just get address not found. Aug 12 14:33:36 16:33 [FreeNode] -!- Irssi: youtube.com: 208.117.236.69 208.65.153.251 208.65.153.253 208.65.153.238 Aug 12 14:33:42 there ;) Aug 12 14:33:43 Could I bother someone to google "open dns" and find me a new server? Aug 12 14:33:46 many thanks Aug 12 14:33:49 try http://208.65.153.251/watch?v=KyvkVFr5ij4 Aug 12 14:33:54 *clicks* Aug 12 14:34:18 213.148.129.10 Aug 12 14:34:34 should be my dns. found it to be quite fast (in germany, though) Aug 12 14:34:48 nice tomgibara. Do I understand that right that you store the content to which the barcodes point at? Aug 12 14:34:54 Spiffy Aug 12 14:35:56 I've seen a few demos of the tech before, is this one actually available? Aug 12 14:36:16 as available as android i guess :p Aug 12 14:36:18 http://www.tomgibara.com/android/moseycode/releases/0.2.1/ Aug 12 14:36:50 Sweet. Aug 12 14:36:58 16:36 [FreeNode] -!- Irssi: tomgibara.com: 89.21.23.7 Aug 12 14:37:01 anno^da_: Yes, a significant part of Moseycode is its use as a free and open publishing system, anyone can publish their own interactive barcodes (though the gap between what will be possible - and what is now possible is still quite large). Aug 12 14:37:03 oh.. ok . :p Aug 12 14:37:04 I'm sure someone's already made a QR and Semacode reader as well. Aug 12 14:37:41 Darkeye11547: Google for one :) Their library is called zxing Aug 12 14:37:44 Great. Aug 12 14:38:15 Is is possible to link content that lies on my own server to the chamber that I registered at your site ? Aug 12 14:38:28 I'm just kinda pissed off because the few readers that already exist don't work on my current phone. Aug 12 14:39:21 anno^da_: Exactly yes, you can choose to host chambers (as they are called in Moseycode parlance) on the Moseycode server, or on your own and just put a pointer to your server. Aug 12 14:39:50 Great. Aug 12 14:39:58 The advantage of the latter is that then the chambers can be entirely dynamically generated (a chamber is basically an XML manifest of the contents of a barcode). Aug 12 14:40:00 I get new ideas for my applications now. :D Aug 12 14:41:06 ah well thats great I'm just reading through your site right now Aug 12 14:41:19 later on I have to get my camera here attached to Android Aug 12 14:41:53 (if I'm skllled enough to get it working :) ) Aug 12 14:42:36 anno^da_: I made an effort to make it as straightforward as possible, the h Aug 12 14:42:47 help is pretty good Aug 12 14:43:13 yeah I saw that. I'd come back to you if I dont get it working but it should be possible. :-) Aug 12 14:49:37 Blarg, still no connection, even with the new DNS nameserver. Aug 12 14:54:45 doesnt work? Aug 12 14:55:21 dunno.. last time i tried the dns from another provider, it worked.. but maybe they closed it to customers only meanwhile Aug 12 14:55:54 huh, that's weird. Another machine on the network is getting through just fine... Must be the pc, I guess. Gonna reboot Aug 12 14:56:19 208.67.222.222 Aug 12 14:56:19 208.67.220.220 Aug 12 14:56:26 that the OpenDNS one Aug 12 14:56:39 well.. when he comes back ;) Aug 12 15:03:50 i switched back from opendns to my isp ones Aug 12 15:03:53 opendns sucked Aug 12 15:04:16 wouldnt know a reason to take another dns Aug 12 15:04:25 (than the isp one) Aug 12 15:04:34 isp patch was late here Aug 12 15:04:38 in fact i didnt even know about openDNS some seconds ago ;) Aug 12 15:04:44 so i switched to opendns for a while Aug 12 15:04:48 ah well Aug 12 15:12:03 claiming sept presales for t-mobile android phone: Aug 12 15:12:04 http://tmonews.com/2008/08/android-may-be-here-sooner-then-we-think/ Aug 12 15:13:31 hmmm, is tmobile using gtalk accounts for something? "users will be required to have a Google Gmail account for the phone to work" Aug 12 15:16:43 i take the word of people who can't spell interesting with a grain of salt Aug 12 15:17:16 michaelnovakjr: yeah, I saw that too Aug 12 15:17:45 but i guess that is what happens when anyone can get a website :) Aug 12 15:19:51 zhobbs_ its not tmobile who makes you create a gmail acc, its google Aug 12 15:20:55 i still wouldn't take it as gospel Aug 12 15:21:24 alex2308: I disagree Aug 12 15:21:44 why Aug 12 15:22:12 just don't see why you'd need a gmail account for a "vanilla" android install Aug 12 15:22:54 activation Aug 12 15:23:02 for google talk, calendars, documents, mail Aug 12 15:23:08 it will all be google's services Aug 12 15:23:23 google forced the gmail accounts Aug 12 15:23:30 id still adwise anyone not to use the services Aug 12 15:23:31 sure, but they imply you need it to use the phone Aug 12 15:23:57 i think you need it (as you need an itunes acc) Aug 12 15:24:07 alex2308: why would you advise people not to use the services? Aug 12 15:24:20 alex2308: you don't need an itunes account Aug 12 15:24:35 alex2308: honestly you're just speculating Aug 12 15:24:50 ah yes, speculating Aug 12 15:24:54 that is what all of this is Aug 12 15:25:09 when tmobile comes out with a statement or google does, then we can talk Aug 12 15:25:28 i can't say that i'm even going to like Android. Aug 12 15:25:33 as a phone Aug 12 15:25:38 i hate how people just spew a bunch of crap every time some immature blog is posted Aug 12 15:25:55 google this, tmobile that Aug 12 15:25:58 after seeing 85772, blah. i don't like the progress. Aug 12 15:25:58 yakischloba cause they collect tons of data Aug 12 15:26:00 who fuckin cares until its actually happening Aug 12 15:26:54 alex2308: and? it doesn't bother me that my data is collected. i'm so insignificant in this world that I could post all my private info everywhere and really no one would care Aug 12 15:27:00 immature blogs are written usually by some bum who doesn't have a job and is scratching the popcorn off his chest as he sneers at the next stupid thing he'll post Aug 12 15:27:27 alex2308: so to have it mined to give me non-invasive advertising is not even notable Aug 12 15:27:48 alex2308: hate to break it to you but your wireless carrier knows everything about what you do Aug 12 15:27:53 btw, for the first time ever i saw an advertisement in my google maps mobile search results. Aug 12 15:28:01 michaelnovakjr: yeah exactly. every time I see one of those articles I just imagine some greasy fool leering at his monitor through thick glasses Aug 12 15:28:02 I use gtalk, but don't use gmail, docs, calendar Aug 12 15:28:05 it was weird :) Aug 12 15:28:10 michaelnovakjr no, there are laws prohibiting it in germany Aug 12 15:28:35 alex2308: its in the infrastructure, they do it Aug 12 15:28:48 they dont Aug 12 15:29:06 data is deleted instandly Aug 12 15:29:17 i highly doubt that Aug 12 15:29:48 i control that Aug 12 15:29:59 i agree with jasta, i don't think its headed in a good direction Aug 12 15:30:07 im in the enterprise privacy group Aug 12 15:30:18 wow. if there was ever a wrong guy behind the wheel. Aug 12 15:31:03 i mean, i expect google to have a lot of surprises up their sleeve, but ultimately, i don't think i'll like the phone itself. Aug 12 15:31:06 just the platform Aug 12 15:31:21 which will be OpenMoko all over again. hours and hours of work just to make it do what i want. Aug 12 15:31:33 alex2308: http://www.nytimes.com/2008/05/27/business/worldbusiness/27tapes.html?_r=1&ref=technology&oref=slogin Aug 12 15:31:38 although, being a linux user, this is not necessarily out of the question :) Aug 12 15:31:39 it happens :) Aug 12 15:32:10 no michaelnovakjr i don't think you understand. alex2308 is in the _enterprise privacy group_ and directly controls with his own hands whether or not private data is recorded. Aug 12 15:32:20 michaelnovakjr: yeah, embarassing Aug 12 15:32:31 tomgibara: I have a feed now that serves me with ip:8080/cam.jpg but Moseycode doesnt get the images. (i can view them in the browser) Is there anything I'm missing Aug 12 15:32:35 ah, i didn't know he was in control of the red button Aug 12 15:32:40 but its not easy to fully control every part of a 250.000 people company Aug 12 15:32:58 anno^da_: what ip are you specifying? Aug 12 15:32:59 tomgibara: working now. Aug 12 15:33:03 okay Aug 12 15:33:07 :) Aug 12 15:33:08 alex2308: that is why your statement of everything deleted instantly is false Aug 12 15:33:26 oh yeah he is. he abuses his powerful position to steal peoples source code Aug 12 15:33:34 anno^da_: you should be able to scan the barcodes that are on the website Aug 12 15:33:53 anno^da_: assuming the webcam isn't built into your monitor :) Aug 12 15:34:39 well yes :D Aug 12 15:35:00 thats why I went upstairs looking for my wired cam :) Aug 12 15:36:16 hehe true Aug 12 15:36:22 anyway gotta go home Aug 12 15:36:27 google ftl Aug 12 15:36:34 going to steal source code some more? Aug 12 15:36:45 no, finished for today Aug 12 15:36:53 alex2308: go home Aug 12 15:36:55 good, because that doesn't make you a programmer Aug 12 15:37:00 just a big ass Aug 12 15:43:43 woooh Aug 12 15:43:47 i like big asses Aug 12 15:46:02 and i can not lie! Aug 12 15:46:03 *dance* Aug 12 15:46:03 :p) Aug 12 15:46:31 let's get a little more trigger happy on the /kickban's :) Aug 12 15:47:27 aww how cute alex2308 has a website http://daloo.de/ Aug 12 15:47:45 lets go download some spl0itz guys Aug 12 15:47:50 :) Aug 12 15:48:53 a true show of genius. Aug 12 15:49:00 what are you so fucked up about, anyway? Aug 12 15:49:30 buster: who? me? ;) Aug 12 15:50:11 yep Aug 12 15:50:22 take it easy buddy :) Aug 12 15:50:35 no reason to get upset Aug 12 15:50:40 tomgibara Aug 12 15:50:42 fascinating Aug 12 15:50:44 :) Aug 12 15:51:08 anno^da_: Did it work then? Aug 12 15:51:40 Note that the framerate is awful, not least because the frames have to be obtained over the wire Aug 12 15:52:56 yeah Aug 12 15:52:59 I know that Aug 12 15:53:06 yakischloba: the irc won't be the same as the release gets closer Aug 12 15:53:41 michaelnovakjr: what do you mean by that? Aug 12 15:54:29 But it is pretty nice to see that working that good Aug 12 15:54:29 more people joining Aug 12 15:54:30 :) Aug 12 15:54:55 and asking "omgwtf, i want android on my nokia xyz. where can i dl setup.exe" ;) Aug 12 15:55:05 yakischloba: more annoying people actually Aug 12 15:55:09 anno^da_: Yeah, when I first got it working, I wasted hours just futzing around with it Aug 12 15:55:15 or "i have minesweeper.exe but it doesnt load an my andropid phone, is it broken?!" Aug 12 15:55:18 :) Aug 12 15:55:27 buster: that's a feature Aug 12 15:55:33 actually that wouldn't be the case Aug 12 15:55:35 of course Aug 12 15:55:50 michaelnovakjr: mm yeah. polluted channel soon. Aug 12 15:56:04 we've put android on a vogue and written software for it, nothing wrong with it.... there's nothing else productive to do with android Aug 12 15:56:38 buster although complaining about something as simple as content providers doesn't really say much Aug 12 15:56:59 michaelnovakjr: thats a stretch I think. You guys keep coming up with good ideas for utilities and stuff, I think they can keep flowin if you want Aug 12 15:57:03 buster: one reason I like IRC is b/c it's a bit more self-selecting. Most people who ask the silly questions won't find their way here :) Aug 12 15:57:25 michaelnovakjr: i still say that its complicated Aug 12 15:58:03 probably because i invested way too much time to do a really easy task concering two sql tables. and i'm not even done yet Aug 12 15:58:30 buster: its different, not harder or more complicated. Aug 12 15:58:31 you must not understand concepts then :) Aug 12 15:58:45 buster: i had a hard time getting used to it as well but that was my own shortcoming Aug 12 15:58:47 did you bother to read the documentation buster? Aug 12 15:58:58 yakischloba: weren't you also learning java? Aug 12 15:59:14 michaelnovakjr: yes Aug 12 15:59:34 morrildl: you must not have ever hung out in #c. Aug 12 15:59:47 no, i downloaded android, wrote about 70 pages diploma until today concerning android and quite some code, but i didnt read any documentation or even learned mor eabout java then hello world.... Aug 12 16:00:08 jasta: no I haven't. And please don't burst my bubble, I want there to be a place like that ;) Aug 12 16:02:24 the whole data access thing in android isn't that bad. its just another one of a hundred ways to access a relational database. there are worse ones than cursors and all that. coming from writing sql and using ActiveRecord all the time it was weird but now its just as easy as anything else I use. Aug 12 16:04:37 you can use sql, but databases are protected between apps, hence content providers :) Aug 12 16:05:23 and no matter what you say, but to get an emailadress through content_email_uri is ok. but that i have to get the column through a constant named DATA, which lies between i gazillion of email-constants, that sucks, tbh. and thats just to get _all_ emails. to match my person_id versus the email person id (the join) is something i have yet to do.. Aug 12 16:08:56 different strokes I guess. I wouldn't have done it this way, but its not my system. Aug 12 16:09:06 you'd think.. "ok, i have ContactMethods.CONTENT_EMAIL_URI. i want the Person ID, so i take ContactMethods.PERSON_ID. but, hell no. 'Invalid column person'" Aug 12 16:11:19 meh, actually forget about it. i guess i got some thing wrong anyway. i'm a bit nerved i guess :p Aug 12 16:12:13 you sound like it :) Aug 12 16:13:18 well as long as we're griping, I hate CSS. Aug 12 16:13:51 Actually I just hate how bad I am at all UI design ;) Aug 12 16:19:17 yakischloba: did you test some different browsers with you css yetß? ;) Aug 12 16:19:30 buster: no, I'm scared. Aug 12 16:19:30 buster: the ContentProvider URI-based access mechanism is clumsy if you ask me. The abstraction is certainly very leaky. Aug 12 16:19:50 though it is workable. Aug 12 17:47:54 morrildl: Can you please follow-up about the MediaPlayer issues we discussed yesterday. Aug 12 17:48:30 It is crucial that some functionality is introduced to permit applications to both stream and cache media streams. Aug 12 17:48:54 This feature can either come from allowing arbitrary input (that is, an InputStream), or by a feature to simply allow the MediaPlayer to save the file to disk itself. Aug 12 17:49:15 The former seems best, but I can appreciate that if the MediaPlayer is implemented with IPC that this probably won't work well. Aug 12 18:48:03 yawn Aug 12 18:49:07 nway Aug 12 18:51:00 jasta: I'm pretty sure that cpu performance issues will kill the hope of MediaPlayer running from an InputStream Aug 12 18:52:18 The possibility of saving a file to disk will probably depend on the transport too (though to be honest, I'm not clear on which transports the Android media library supports) Aug 12 18:53:04 it currently supports http, and that's the only one i care about. Aug 12 18:53:47 if this doesn't make it into 1.0, then Android will not be able to have any streaming media that is also cacheable using the provided mechanisms. Aug 12 18:53:56 If it uses ranges, then saving a file might be very difficult to implement. Aug 12 18:54:17 Yes, I can certainly see why it's useful. Aug 12 18:55:22 this is simply unacceptable not to make it into the first production release. ugh. Aug 12 18:56:31 tomgibara: all that would be necessary would be to have the class tee its own input to some file on disk. there is no significant challenge in this implementaiton if you don't try to manage what that means at the MediaPlayer layer. Aug 12 18:56:38 let the usage of MediaPlayer worry about the implications there. Aug 12 18:57:03 I think there will be lots of important -wanted- functionality missing in the 1.0 release. Aug 12 18:57:11 the only caveat that MediaPlayer would need to know abou is that seeking shouldn't be reflected in the teed output. Aug 12 18:57:28 tomgibara: this isn't just wanted functionality, this simple problem will destroy the possibility of my app being on Android. Aug 12 18:57:58 jasta: But that latter point is the issue with using http range requests for seeking Aug 12 18:58:28 I meant functionality that was both important _and_ wanted. Aug 12 18:58:52 For me, the lack of any AOT or JIT was a major blow. Aug 12 18:59:01 not to mention this is a credibility issue as Dan committed this functionality to be possible. Aug 12 18:59:23 tomgibara, isnt playing from a http connection what tunewiki does? it plays youtube videos Aug 12 19:00:13 buster: tomgibara doesn't work on TuneWiki, and even still, TuneWiki quite likely doesn't cache this output. Aug 12 19:00:20 Or they simply don't use MediaPlayer somehow. Aug 12 19:01:33 oh well, i didnt get all you wrote.. read somehow like playing streaming stuff from the web isnt possible.. go on then ;p Aug 12 19:01:39 *read Aug 12 19:01:49 tomgibara: For me, the lack of any AOT or JIT was a major blow. << you still haven't tried on a real device Aug 12 19:02:42 romainguy__: who should i talk to about the MediaPlayer? Aug 12 19:03:28 well tunewiki prolly uses rtsp links from youtube Aug 12 19:03:47 since thats what the youtube mobile 3gp site uses Aug 12 19:14:09 romainguy__: I'm not saying that Android/Dalvik will be slow, or even too slow to run Moseycode - what I am confident of is that with some form of to-native compilation would significantly boost the performance of my app, and probably others without making heavy trade-offs against the benefits of an interpreter. Aug 12 19:14:27 And I still assert that within a short period of time, applications developers will look to differentiate their applications by adding features that don't 'come for free' in the framework. Aug 12 19:15:03 Thus the lack of compilation will become important fairly quickly. Aug 12 19:16:24 romainguy__: btw, if you have a device handy, I'm happy to send you my postal address ;) Aug 12 19:45:58 tomgibara: the Vogue can run Android, although the processor is way under class of what we all expect Android to be running on. Aug 12 19:46:11 jasta, but its still fast :) Aug 12 19:46:21 faster than the emulator that's for sure :) Aug 12 19:46:25 yes, it does still run nicely. however, i have noticed something... Aug 12 19:46:50 the emulator also runs very fast when you use a 240x320px skin instead of the default 320x480. Aug 12 19:47:04 interesting Aug 12 19:47:09 the animations are much smoother. Aug 12 19:47:31 so maybe the jump in performance is not actually that meaningful... though, the drawing acceleration on the official devices is likely quite significant. Aug 12 19:47:39 I have always strongly suspected the basic IO (screen/sound etc) as being the aspect which makes the emulator slow. Aug 12 19:51:32 Also, Google employs a lot of smart people - I'm sure that the performance will be good. Aug 12 19:51:55 This doesn't change the underlying assumption that seems to exist: that most apps will spend most of their time not running in the interpreter, but idle or in native code. Aug 12 19:51:56 tomgibara: what do you make of the Dalvik maintainer saying that JIT just doesn't offer much for Dalvik? Aug 12 19:52:43 That assumption is probably a valid one, except for the fact that developers will quickly push the boundaries and invalidate it (imo). Aug 12 19:53:36 i don't recall it being an assumption, but rather a confirmed benchmark. Aug 12 19:53:45 jasta: I think he's entirely right, but I've never written a VM. Aug 12 19:53:56 the efficiency of their interpretor may well exploit architecture-specific features which make JIT pretty negligible. Aug 12 19:54:18 i know at least that they are abusing a pretty common gcc feature not present on other compilers. Aug 12 19:55:04 The gains that people might anticipate from a JIT are almost certainly overstated. Aug 12 19:55:46 Dalvik will clearly be optimized in a number of ways - and will have been informed by previous VM implementations - to be efficient w/o native-compilation. Aug 12 19:56:00 I'm thinking in particular of Lua Aug 12 19:56:09 But... Aug 12 19:56:46 tomgibara: right, so how can you be so certain that this will have an observed impact on performance? Aug 12 19:56:47 There is a significant class of applications for which a small element of compilation will provide staggering improvements Aug 12 19:57:31 but how can you know that without knowing the implementation details of the interpretor? think very concretely about what you're talking about: the set of instructions being performed by the processor. Aug 12 19:58:06 the interpretor could be exploiting functionality to make that set very precise and efficient, quite like the set of instructions it would produce directly through JIT. Aug 12 19:58:31 Okay: Very simply, most application code (most as a proportion of the source code) in a typical app is taken up with logic and method calls etc. Aug 12 19:58:59 But what can you infer from that? Aug 12 19:59:00 Method calls are relatively expensive and apart from inlining and some other optimizations, you can't remove the cost Aug 12 19:59:22 So compiling the code isn't going to gain you very much. Aug 12 19:59:51 On the other hand - say you want to implement a parser Aug 12 20:00:39 The most optimum way in most circumstances is a highly compact lookup table Aug 12 20:01:13 so your code spends almost all of its time in one method doing array lookups (from the input stream and comparing them against your array of state transitions etc) Aug 12 20:01:41 In that instance, the overhead of the interpreter is going to absolutely kill your performance Aug 12 20:02:27 Because what would simply be loads, branches and compares becomes 'decorated' with all of the work being done by the interpreter. Aug 12 20:03:11 This is exactly the reason that all of the in-built code (like MediaPlayer, Bitmap, Audio) stays the hell away from InputStreams Aug 12 20:03:48 because just the process of iterating over the byte array backing the buffer will significantly impair performance. Aug 12 20:03:53 actually, i would reason that they do so because they don't wish to bridge to Java, which can incur costly performance overhead when translating types. Aug 12 20:04:39 that may be a factor too, certainly Aug 12 20:04:40 inherent in the language design and class implementations. Aug 12 20:05:11 I doubt if its the main reason, since calls to an InputStream are relatively few compared to the number of bytes read Aug 12 20:05:48 it would be interesting to see a non-numerical analysis of this. Aug 12 20:06:23 Incidentally, my suggestion is an annotation that you can supply on a method which basically says to the apk installer: compile this AOT Aug 12 20:07:00 well, we know from history that is a generally failing strategy. Aug 12 20:07:23 So the application still has the properties of being small (in memory), but gets to call out to a faster method on the rare but important occasions it needs to. Aug 12 20:07:27 humans are notoriously bad at microoptimizations by hand. Aug 12 20:07:29 why? Aug 12 20:07:54 for example, inline and register keywords in most C compilers are now completely ignored. or at least, the compiler does not interpret them literally. Aug 12 20:08:18 because it has been shown that humans don't know what they're doing, but profilers do. Aug 12 20:08:39 It's certainly open for abuse - but isn't everything. Aug 12 20:09:08 I understand that the reason that compilers ignore the inline directive is that they can make a better judgement in most cases than the programmer Aug 12 20:09:18 That's fine Aug 12 20:10:12 In my 'proposal', the installer could just ignore my annotation too, if the VM became so advanced that it was confident it could make a better judgement Aug 12 20:10:35 And it could be ignored if the VM just didn't support compilation Aug 12 20:10:50 Well, one nice thing about this topic is that you can beat it to death with numerical analysis once the code is released. Aug 12 20:11:27 In the mean time, I am going to crusade to get the MediaPlayer extended with my required features. Aug 12 20:11:34 Not easily, you can't draw general conclusions from a single device Aug 12 20:12:55 You can draw conclusions about the performance of that device. Aug 12 20:13:14 And that is quite useful. Aug 12 20:14:26 I suspect that JIT or AOT compilation is difficult for another reason. Architecturally, Dalvik may be quite complicated, leading to real problems implementing this. Aug 12 20:14:51 But I'm done speculating. Until we can analyize it, there's no use discussing it. Aug 12 20:15:43 I don't disagree with either of those last two comments :) Aug 12 20:57:22 hi Aug 12 21:34:26 chab7: hello Aug 12 21:46:13 jasta_: Just as an aside, I've confirmed that (in the emulator at least) the BitmapFactory native method that takes an InputStream is slower than the native method that takes the asset id directly (in a very simple benchmark). Aug 12 21:49:25 tomgibara: by what margin did you find? Aug 12 21:50:46 btw, looking at the code for BitmapFactory, they are one in the same ;) Aug 12 21:51:39 decodeResource() calls decodeStream. the only difference is that the stream is from res.openRawResource(), which possibly returns a more efficient InputStream. Aug 12 21:51:45 or you could even be seeing something as simple as the kernel's read cache. Aug 12 21:53:09 jasta: Read the bytecodes carefully and you'll see that they aren't ;) Aug 12 21:53:59 i'll need a hint then, because i do not see what you see :0 Aug 12 21:55:08 Read the decodeStream method, you'll see that it does an instanceof check on the stream (very tidy way of doing it in my opinion) Aug 12 21:55:42 ahh yes, i see that you are correct. Aug 12 21:55:43 163628 byte JPG, takes approx 1230ms w/ stream and approx 1100ms w/ asset id Aug 12 21:56:34 tomgibara: JPG file, you mean? Aug 12 21:56:46 One proviso is that I wrap the asset stream in a buffered stream to avoid the instanceof test Aug 12 21:56:53 That will add some overhead Aug 12 21:56:54 yes Aug 12 21:57:07 It's entirely possible that the kernel's read cache may still be in effect here, depending on how assets are read. Aug 12 21:57:17 And yes, wrapped methods would have some overhead. Aug 12 21:57:58 regardless, the only real test that makes any sense is to implement this all in JNI: one method to decode from a FileInputStream, and another to impelment that natively. Aug 12 21:58:14 your test is to dissimilar to prove anything, and even then the benchmark margins are very small. Aug 12 21:58:21 too* Aug 12 21:58:56 it is also very important to remember that we have a non-trivial kernel we're dealing with here. it has extensive optimizations that it can apply which are not always intuitive. Aug 12 21:59:14 and, above all else, a complex scheduler that can invalidate our results :) Aug 12 21:59:48 I completely agree that this benchmark is nowhere near conclusive, but I don't think they are necessarily small margins - a significant proportion of the time is (I'm assuming here) the actual decoding of the JPEG. Aug 12 21:59:50 but as i said, you'd need to write a JNI module in order to benchmark this even reasonably Aug 12 22:00:30 why does JNI allow you to benchmark it more accurately? Aug 12 22:01:40 (I know very little about producing reliable benchmarks) Aug 12 22:02:42 tomgibara: Because here you are benchmarking two entirely different code paths that you can't see. Aug 12 22:02:51 nativeDecodeAssert and nativeDecodeStream are both unknown to us. Aug 12 22:03:07 nativeDecodeAsset, for example, may be quite a bit faster for reasons we can't see. Aug 12 22:03:39 If you wrote a JNI layer yourself, you could benchmark what you are really trying to learn: whether the perofrmance overhead of allowing an InputStream from Java is really so great compared to natively reading the file in C. Aug 12 22:03:56 I see what you mean now Aug 12 22:03:59 Your test would be to create two native methods: one which takes a filename, and does it all in C, another which takes an InputStream. Aug 12 22:04:03 Yes, I can see that. Aug 12 22:04:17 Then use a FileInputStream from Java for the benchmark. Make sure to use two different files too :) Aug 12 22:04:25 don't let the kernel get the chance to cache either one Aug 12 22:04:41 two different files, but with identical content, i mean. Aug 12 22:06:22 for an illustration of what i'm talking about as far as the kernel's read cache, install the pv command and run it over a somewhat large file with pv foo > /dev/null Aug 12 22:06:26 and then run it again after it completes. Aug 12 22:06:33 you will see wildly different results. probably a margin of 10% or more. Aug 12 22:07:27 (fwiw, this is why numerical analysis usually sucks) Aug 12 22:08:40 tomgibara: btw, this is something we could benchmark today. JNI is possible on Android. Aug 12 22:08:45 and not much work, either. Aug 12 22:08:52 Yes, I've always struggled to produce reliable benchmarks - it's so hard to generate a replicable environment Aug 12 22:09:06 tomgibara: I completely agree that this benchmark is nowhere near conclusive, but I don't think they are necessarily small margins - a significant proportion of the time is (I'm assuming here) the actual decoding of the JPEG. << you'll be happy to hear we did a lot of work in that area recently Aug 12 22:09:30 we also introduced a new API on BitmapFactory to load files from file descriptors instead of InputStreams Aug 12 22:09:31 because you're usually testing hundreds or *maybe* thousands of lines of code by using tens of millions of lines of code to run it :) Aug 12 22:09:50 haha yes! Aug 12 22:10:25 it's the resolution of the JPG that matters, not its file size Aug 12 22:11:07 romainguy: we're actually talking about the overhead of using an InputStream versus natively reading from a stream. Aug 12 22:11:14 romainguy: I'd assume that (I know a little about image compression) - it's large. Aug 12 22:11:58 jasta: that's why we added an API with file descriptors Aug 12 22:12:06 but the different is really not big Aug 12 22:12:17 it had an impact when we were trying to load tons of small images Aug 12 22:12:32 romainguy: such as map tiles ;) Aug 12 22:12:49 romainguy: regardless, i don't know that feeding the MediaPlayer this way is what i really want anyway. Aug 12 22:12:56 tomgibara: no, not map tiles :)) Aug 12 22:12:58 i mostly just want the MediaPlayer to be cachable. Aug 12 22:13:32 designing a media input stream would be tricky, unless you implicitly disabled seeks... Aug 12 22:14:37 btw, i'm getting very nervous that Android is gonna ship without this ability. which would mean Five can't exist :( Aug 12 22:15:22 jasta: Unless you use some ugly compromise. Aug 12 22:15:29 There is no ugly compromise. Aug 12 22:15:41 jasta, you could always have "iFive" Aug 12 22:15:50 * AttractiveApe snorts. Aug 12 22:15:52 Downloading it in parallel :-/ Aug 12 22:16:08 tomgibara: that isn't so much an ugly compromise as it is an entirely unworkable design :) Aug 12 22:16:13 tethridge: hiFive Aug 12 22:16:19 bandwidth is a premium, it's already iffy whether you can even stream reliably. Aug 12 22:16:20 even better Aug 12 22:16:32 hmm Aug 12 22:16:35 or hiFi Aug 12 22:16:36 I like that. Aug 12 22:16:44 Or not caching it, but remembering that th user has played it and then scheduling it for download later (in an interruptible way) Aug 12 22:16:52 They are very ugly, I know Aug 12 22:18:52 Perhaps use it to your advantage (stretching it a bit here): get your server to transcode the audio file into a low bitrate version for streaming, but schedule the download of a high fidelity version. Aug 12 22:19:03 tomgibara: they're not just ugly, they compromise an already ambitious design to the point that it won't work. Aug 12 22:19:20 the user will see right through the abstractions and the experience would be terrible. Aug 12 22:19:50 fair enough, you know the problem domain better than I do Aug 12 22:20:53 well anyway, i'm on a mission now to get someone's attention who can fix this. Aug 12 22:35:38 hehe, stupid phone died Aug 12 23:08:46 tomgibara: i'm coding up that better test of throughput differences between a JNI InputStream and natively reading. Aug 12 23:10:36 though i dont think performance is the main reason they don't support this. they couldnt use an InputStream else seeking would not be possible. Aug 12 23:11:33 and it would be tricky to provide a stream that would work right Aug 12 23:12:17 jasta: java typically uses marking for limited seek ahead Aug 12 23:12:43 i don't mean seek ahead. Aug 12 23:13:09 the mediaplayer obviously can seek in all directions, arbitrary distances. Aug 12 23:14:25 Some transports only support linear reads anyway (http w/o ranges is one example) Aug 12 23:14:45 still, i think they could support this and just leave non-trivial implementations up to us. Aug 12 23:15:12 I'm just off to bed now Aug 12 23:15:19 im heading home from work Aug 12 23:15:27 I look forward to hearing your results Aug 13 00:46:23 hey there, wondering if anyone else is working on a dbus/dcop-based remote control for android? Aug 13 00:46:28 specifically for vlc and amarok Aug 13 00:46:51 id love to jupm in and help with anything alreayd started, otherwise ill just do it myself ;) Aug 13 00:52:48 ooh any mythtv too Aug 13 01:00:10 finally found a gem: http://wiki.xmms2.xmms.se/wiki/Media_Player_Interfaces Aug 13 01:40:18 jasta: know any 3 bedroom houses for rent? Aug 13 02:54:43 umdk1d4, there is a thing called anyremote u might want to look at. It already does all that with JSR-82 **** ENDING LOGGING AT Wed Aug 13 02:59:57 2008