| 00:01.12 | yakischloba | clearly need to get rid of your girlfriend |
| 00:01.26 | yakischloba | standing in between you and the touch |
| 00:08.08 | *** join/#android ahti__ (n=ahti@88-196-185-130-dsl.rgu.estpak.ee) |
| 00:30.04 | *** join/#android Thus0 (n=petrus@123.158.69-86.rev.gaoland.net) |
| 00:35.24 | *** join/#android zeeeee (n=zeeeee@ASHDOWN-FORTY-TWO.MIT.EDU) |
| 00:39.41 | jasta_ | hmm |
| 00:39.52 | *** join/#android romainguy__ (n=gfx@69.36.227.135) |
| 00:40.06 | jasta_ | damn nice weather today. |
| 00:41.17 | *** join/#android romainguy___ (n=gfx@72.14.224.1) |
| 00:51.19 | yakischloba | yeah. i was outside sunning earlier ;) |
| 00:56.40 | zeeeee | is this a channel for discussion about google android? |
| 00:56.51 | Dougie187 | no |
| 00:57.01 | Dougie187 | we are talking about the android taking over the earth in 2020 |
| 00:57.06 | morrildl | zeeeee: yes |
| 00:57.09 | morrildl | Dougie187: :P |
| 00:57.11 | Dougie187 | :) |
| 00:57.26 | zeeeee | hah |
| 00:57.28 | morrildl | I guess that sets the tone for the channel for zeeeee pretty well though ;) |
| 00:57.37 | Dougie187 | i try. |
| 00:57.45 | zeeeee | i was just thrown off by the title here |
| 00:57.55 | *** mode/#android [+o morrildl] by ChanServ |
| 00:57.56 | Dougie187 | hey morrildl, any idea when the results for ADC1 are done? |
| 00:58.23 | morrildl | zeeeee: suggestions for better topics? :) |
| 00:58.33 | morrildl | Dougie187: good question |
| 00:58.41 | morrildl | unfortunately David's not around so I don't have an answer for that |
| 00:58.45 | morrildl | ask me again tomorrow :) |
| 00:58.56 | Dougie187 | ok. it wont be until late though, stupid work doesnt allow irc |
| 00:59.03 | morrildl | Dougie187: lame |
| 00:59.19 | zeeeee | is there a resource explaining the rationale behind why android requires apps to be written in java? |
| 00:59.19 | Dougie187 | lol trust me, i know. |
| 00:59.38 | chomchom | Oh noble Androids |
| 01:00.08 | chomchom | How annoying is is in eclipse when the LogCatView resets its size? |
| 01:00.20 | Dougie187 | i wouldnt know. |
| 01:00.25 | chomchom | And you have to edge it open further bit by bit |
| 01:00.27 | Dougie187 | im down with the vim yo. |
| 01:00.35 | zeeeee | maybe a more informative title could be "Discussion about the Google Android platform" |
| 01:00.42 | Dougie187 | lol |
| 01:00.51 | Dougie187 | or "Pretty Weather Outside" |
| 01:00.54 | chomchom | Or Anything else really |
| 01:01.17 | Dougie187 | although mine sounds rather gay. |
| 01:01.28 | zeeeee | anyway...anybody know why android requires java? |
| 01:01.43 | Dougie187 | because java is awesome. |
| 01:02.12 | Dougie187 | i think i heard something before, but dont quote me on this. |
| 01:02.16 | Dougie187 | security. |
| 01:02.21 | Dougie187 | garbage management? |
| 01:02.26 | *** topic/#android by morrildl -> For All Your Android Discussion Needs |
| 01:02.31 | Dougie187 | and of course each OOP |
| 01:02.33 | Dougie187 | easy* |
| 01:02.37 | morrildl | zeeeee: it's not Google Android so I can't say that ;) |
| 01:02.37 | zeeeee | Dougie187, security is what i just imagined too, but i was wondering about specifics |
| 01:02.49 | morrildl | zeeeee: The main reason is just developer base |
| 01:03.01 | Dougie187 | and cuz morrildl has a crush on java. |
| 01:03.13 | morrildl | Android uses a VM (named Dalvik) for the usual reasons of security and so on |
| 01:03.27 | chomchom | morrildl: Why not change it to: We'll end up making the phones ourselves: http://www.alleyinsider.com/2007/11/open_source_bug_can_run_android_sells_next_month |
| 01:03.38 | Dougie187 | that ones rather long. |
| 01:03.39 | zeeeee | morrildl, there is indeed a large base of java devs, so it makes sense for android to feature java. do you think it also explains why java is required? |
| 01:03.55 | morrildl | Dalvik is not a Java VM, but Java bytecode can be translated to Dalvik bytecode |
| 01:04.02 | Dougie187 | zeeeee: if you dont know.... morrildl is one of the android developers. |
| 01:04.04 | morrildl | Java is a popular language, so we started there |
| 01:04.11 | Dougie187 | he is like... the hevenly father of this channel. |
| 01:04.16 | Dougie187 | heavenly* |
| 01:04.17 | morrildl | Dougie187: :P |
| 01:04.42 | morrildl | chomchom: neat |
| 01:04.50 | chomchom | Yeah |
| 01:04.53 | Dougie187 | morrildl: true... but those phones are butt ugly. |
| 01:04.56 | chomchom | I'm looking forward to those |
| 01:05.05 | chomchom | But goo dfor prototypes! |
| 01:05.20 | morrildl | gotta boogie folks |
| 01:05.21 | zeeeee | Dougie187, i didn't know that. cool. |
| 01:05.25 | chomchom | Think of all the fun stuff you could do |
| 01:05.25 | morrildl | be back tomrorow, or perhaps later tonight |
| 01:05.28 | Dougie187 | See ya morrildl |
| 01:05.29 | zeeeee | morrildl, d'oh, all right...ttyl |
| 01:05.37 | chomchom | nighty |
| 01:06.39 | chomchom | Well back to what I was asking for help with, is there anyone using android on eclipse lurking here who has a good grasp of eclipse's caching of OSGI metadata? |
| 01:08.07 | chomchom | When eclipse starts up it caches all the bundles metadata in directories namespaced under the bundle names in .metadata |
| 01:08.09 | Dougie187 | i dont think many people are around now. |
| 01:08.13 | Dougie187 | and i stay clear of the IDEs |
| 01:08.27 | chomchom | your a mad sadomasachist |
| 01:08.44 | Dougie187 | hah, vim is the bet. |
| 01:08.46 | Dougie187 | best* |
| 01:08.51 | chomchom | mad mad mad |
| 01:09.20 | chomchom | when eclipse shuts down, it saves it's workbench state somewhere |
| 01:09.26 | chomchom | in the .metadata |
| 01:09.41 | Dougie187 | you dont like vim? |
| 01:09.54 | chomchom | I'd like to know where the flipping com.android.ide.eclipse.ddms.views.LogCatView setting are |
| 01:10.10 | chomchom | so I don't have to keep dragging it inch by inch in log view |
| 01:10.17 | chomchom | yeah I like vim! |
| 01:10.31 | chomchom | but not to write 100,000 lines of code |
| 01:10.38 | Dougie187 | but it's soooooo cool |
| 01:10.38 | Dougie187 | . |
| 01:10.46 | Dougie187 | i love using it to code anything. |
| 01:12.13 | *** part/#android zeeeee (n=zeeeee@ASHDOWN-FORTY-TWO.MIT.EDU) |
| 01:12.26 | chomchom | Well I wish you the best :). I like the convenience, code completeion, hierarchical layouts, advanced debugging & testing tools with high level modification of build scripts |
| 01:13.00 | chomchom | But I'm betting you'll be able to justify your love |
| 01:13.01 | Dougie187 | i will give you the code completion, but everything else is in my head. |
| 01:13.05 | Dougie187 | except the debugging. |
| 01:13.05 | Dougie187 | lol |
| 01:13.08 | chomchom | If you like it thats great |
| 01:13.18 | Dougie187 | but debugging.. there are debuggers out there that are good too. |
| 01:13.45 | Dougie187 | i just love how easy it is to do stuff, and i dont have to use my mouse when i code. And there are cool features like folding and such. |
| 01:13.59 | Dougie187 | also, you can code in a code completion thing, but you either have to find a plugin or code it yourself. |
| 01:16.28 | chomchom | Yeah I'm not dissing, people write code in all sorts. I know some peeps who swear by emacs |
| 01:16.35 | chomchom | others swear at it |
| 01:16.38 | Dougie187 | lol emacs is a joke though. |
| 01:16.40 | Dougie187 | yeah. |
| 01:16.48 | Dougie187 | i know more who swear at it then swear by it. |
| 01:18.10 | Dougie187 | eclipse isnt bad either though. |
| 01:18.13 | Dougie187 | i just like vim more. |
| 01:18.16 | Dougie187 | so i cant help you with your issue. |
| 01:18.17 | Dougie187 | lol |
| 01:19.00 | chomchom | :) no, I think by the reception I am as per usual, as we say here in Scotland: Getting the stone cold dingy. |
| 01:19.56 | Dougie187 | lol no.. its just late. |
| 01:20.13 | Dougie187 | if you come back tomorrow about.... 5 hours earlier.. maybe more you should get more help |
| 01:20.24 | Dougie187 | 5 hours should do it pretty well though |
| 01:22.03 | Dougie187 | most people aren't at work anymore. so they have left the room. |
| 01:22.08 | Dougie187 | though some will come back in a little while |
| 01:22.11 | Dougie187 | what time is it there? |
| 01:22.27 | Dougie187 | lol the Stone Cold Dingy.. |
| 01:22.32 | Dougie187 | ive never heard it that way before. |
| 01:22.40 | *** join/#android michaelnovakjr__ (n=mnovak@ool-18ba6e83.dyn.optonline.net) |
| 01:22.48 | michaelnovakjr__ | howdy |
| 01:22.50 | Dougie187 | whats going down michaelnovakjr__ |
| 01:22.58 | Dougie187 | you dont useeclipse do you? |
| 01:23.03 | Dougie187 | use eclipse* |
| 01:23.12 | michaelnovakjr__ | i used to use it |
| 01:23.26 | Dougie187 | hey chomchom michaelnovakjr__ might be able to help you. |
| 01:23.48 | michaelnovakjr__ | what's up? |
| 01:24.06 | Dougie187 | he is having an issue with eclipse, but i dont know enough to help him out. |
| 01:24.40 | chomchom | Can you see all the blah blah I just wrote or shall I reiterate>\ |
| 01:24.52 | Dougie187 | reiterate it. |
| 01:25.02 | Dougie187 | he just joined a minute ago |
| 01:25.37 | chomchom | Ok, how familiar are you with OSGI michaelnovakjr__ ? |
| 01:26.46 | michaelnovakjr__ | somewhat familiar |
| 01:27.43 | chomchom | Ok, well when eclipse starts up it caches lots of its bundles metadata your .metadata folder of the workspace |
| 01:27.59 | chomchom | So the adt plugin is one of those bundles |
| 01:28.25 | michaelnovakjr__ | ok |
| 01:29.30 | chomchom | In your workspace when you have chosen the ddms view and arranged the columns, upon closing I wanted to know if it stored its workbench settings as a memento'd file somewhere within the bundles |
| 01:29.53 | chomchom | I'd like to know where the flipping com.android.ide.eclipse.ddms.views.LogCatView setting are |
| 01:30.14 | chomchom | So that I don't have to slowly edge it further to the right when I want a larger log showing |
| 01:30.18 | michaelnovakjr__ | hm, not sure.... i don't think the ADT plugin is trump tight yet |
| 01:30.49 | michaelnovakjr__ | i end up using a command prompt for the logcat |
| 01:30.57 | chomchom | looking in: .metadata/.plugins/org.eclipse.core.runtime/.settings I can see that within that file there is memento'd data wil element attributes like ratio\="0.66238534" ratioLeft\="722" |
| 01:31.08 | chomchom | I've tried fiddling but alas, have got no where |
| 01:31.36 | chomchom | I think it may be forcing a reset every time |
| 01:32.00 | chomchom | romainguy_ ? Oh where art thou? |
| 01:32.13 | chomchom | romainguy? |
| 01:32.36 | chomchom | I know you are an intelliJ guy but you may be able to confirm this |
| 01:33.19 | michaelnovakjr__ | yea i gave up on eclipse right after the adc |
| 01:33.26 | michaelnovakjr__ | so i haven't used it since then for android |
| 01:33.34 | Dougie187 | im out guys. |
| 01:33.36 | Dougie187 | have a good evening. |
| 01:33.40 | michaelnovakjr__ | :) |
| 01:33.43 | *** part/#android Dougie187 (n=doug@c-69-244-215-210.hsd1.fl.comcast.net) |
| 01:33.57 | chomchom | nig |
| 01:34.00 | chomchom | night even |
| 01:43.54 | *** join/#android romainguy__ (n=gfx@adsl-76-241-19-32.dsl.pltn13.sbcglobal.net) |
| 02:06.25 | *** join/#android matt_c (n=mcroydon@137.147.45.66.cm.sunflower.com) |
| 02:09.55 | *** join/#android sayers (n=sayers@c-76-20-182-119.hsd1.mi.comcast.net) |
| 02:18.36 | *** join/#android yakischloba (n=jake@c-24-17-53-6.hsd1.wa.comcast.net) |
| 02:24.20 | *** join/#android morrildl (n=chatzill@72.14.224.1) |
| 02:34.23 | yakischloba | Someone suggested to me that I only open/close my sqlite db when I need to access it. It seems to me like it is going to cherchunk more if I am using it a lot. Is this correct? |
| 02:38.51 | duey | :\ |
| 02:38.56 | *** join/#android morrildl_ (n=chatzill@72.14.224.1) |
| 02:39.00 | duey | sqllite isnt a complex db |
| 02:39.10 | duey | its not a server or anything |
| 02:39.21 | michaelnovakjr__ | its a file |
| 02:39.25 | duey | so there is no connection overhead |
| 02:39.37 | yakischloba | yeah. so it should be lightweight enough that I don't need to worry about opening/closing it every time i usei t? |
| 02:39.48 | duey | doubt it |
| 02:39.56 | michaelnovakjr__ | as far as speed, shouldn't be an issue |
| 02:39.57 | yakischloba | ok |
| 02:40.15 | yakischloba | because opening/closing it _does_ seem to cause a tiny holdup |
| 02:40.33 | yakischloba | enough that i'd rather do without it |
| 02:40.33 | michaelnovakjr__ | do you open it in the same class? |
| 02:40.51 | yakischloba | what do you mean |
| 02:41.01 | michaelnovakjr__ | is it your main activity opening the connection? |
| 02:41.13 | yakischloba | others as well |
| 02:41.30 | michaelnovakjr__ | i wouldn't worry so much about it now |
| 02:41.43 | michaelnovakjr__ | the emulator is not that great of an indicator of speed |
| 02:41.56 | yakischloba | ok. so I should or should not close it when not immediately in use? |
| 02:42.30 | michaelnovakjr__ | if you aren't using it for the same task again close it |
| 02:42.46 | michaelnovakjr__ | by task i mean whatever your application is processing |
| 02:43.14 | yakischloba | hmm. |
| 03:02.13 | *** part/#android michaelnovakjr__ (n=mnovak@ool-18ba6e83.dyn.optonline.net) |
| 03:23.59 | *** join/#android yeonhoo (n=yeonhoo@189.58.75.203.adsl.gvt.net.br) |
| 03:30.10 | *** join/#android morrildl_ (n=chatzill@76-217-210-185.lightspeed.sntcca.sbcglobal.net) |
| 03:38.07 | *** join/#android OpnSrc1 (i=harisha1@gateway/tor/x-5487192cf7fb3fd6) |
| 03:38.32 | *** join/#android morrildl (n=chatzill@76-217-210-185.lightspeed.sntcca.sbcglobal.net) |
| 04:21.47 | *** join/#android morrildl_ (n=chatzill@72.14.224.1) |
| 04:58.45 | *** join/#android romainguy__ (n=gfx@72.14.224.1) |
| 05:43.57 | *** join/#android davidw (n=davidw@213.47.186.146) |
| 05:54.17 | morrildl_ | hi davidw |
| 05:54.57 | davidw | "'morning" |
| 05:55.39 | romainguy__ | hoy |
| 05:58.23 | morrildl_ | okay I need to sleep now |
| 05:58.33 | morrildl_ | looks to be another long day tomorrow :) |
| 05:58.41 | morrildl_ | so, "night", davidw :) |
| 05:59.18 | davidw | romainguy, manana |
| 06:02.06 | *** join/#android jasta (n=jasta@75-165-30-37.tukw.qwest.net) |
| 06:15.08 | *** join/#android SUNWjoejaxx (i=joejaxx@fluxbuntu/founder/joejaxx) |
| 06:42.09 | *** join/#android borism (n=boris@195-50-197-174-dsl.krw.estpak.ee) |
| 06:47.55 | *** join/#android tomgibara (i=Miranda@gibara.demon.co.uk) |
| 07:07.27 | *** join/#android anno^da_ (n=anno^da@p5B07CECE.dip.t-dialin.net) |
| 07:10.37 | *** join/#android inZane-_ (i=nemo@dslb-084-058-033-213.pools.arcor-ip.net) |
| 07:22.59 | *** join/#android alex2308 (n=alex2308@daloo.de) |
| 07:31.33 | *** join/#android anno^da_ (n=anno^da@p5B07CECE.dip.t-dialin.net) |
| 07:45.31 | *** join/#android eton (n=eton@ppp-58-8-6-65.revip2.asianet.co.th) |
| 08:04.28 | *** join/#android cutmasta (n=cutmasta@62.225.134.181) |
| 08:34.19 | *** join/#android nowi (n=nowi@p57A0C1CE.dip.t-dialin.net) |
| 08:50.32 | *** join/#android Woerf (i=53adcce7@gateway/web/ajax/mibbit.com/x-da266f3cc3eac48e) |
| 08:53.42 | *** join/#android umdk1d3 (n=umdk1d3@adsl-dynamic-64-79-45-15.bridgeband.net) |
| 08:54.18 | anno^da_ | could someone tell me why the EditText gets destroyed when I type more than the line height defined in the layout ? |
| 08:54.23 | anno^da_ | It looks like this: http://img.skitch.com/20080812-tqc8rprxp5uw34p49f6fcuqywa.jpg |
| 08:56.31 | alex2308 | ne art notizanwendung? |
| 08:57.43 | anno^da_ | ne ne nur das roh layout für nen Mini Blogging Tool. Und so langsam nervt mich das Textfeld :) |
| 09:02.27 | alex2308 | wart doch aufs neue SDK :) |
| 09:02.57 | tric | bau nen eigenes |
| 09:03.02 | tric | also textfeld ;-) |
| 09:05.14 | anno^da_ | Joa später :-) |
| 09:05.33 | anno^da_ | Im Moment hab ich keinen Nerv mehr :D. So langsam hasse ich UI erstellen *g* |
| 09:05.55 | alex2308 | sowieso, darum ist meine so minimal wie es geht |
| 09:06.17 | alex2308 | obwohl ne netstat anwendung sicherlich nett wäre |
| 09:23.09 | tomgibara | I can't read German - perhaps your question was answered, but what do you mean by destroyed? |
| 09:27.17 | anno^da_ | :). 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. |
| 09:27.40 | anno^da_ | I can make a video that shows better what I mean it is a bit hard to describe |
| 09:28.01 | tomgibara | That's what I thought you meant |
| 09:28.58 | tomgibara | http://code.google.com/p/android/issues/detail?id=744 |
| 09:29.28 | tomgibara | That bug almost killed me in the ADC |
| 09:30.30 | anno^da_ | ok the next time I'm looking in the buglist I promise. Why do I always come across the bugs :D |
| 09:30.48 | tomgibara | :) |
| 09:32.03 | anno^da_ | But well the bloggin with Tumblr works thats all I want *g* |
| 10:42.48 | *** join/#android eton_ (n=eton@ppp-58-8-6-65.revip2.asianet.co.th) |
| 11:54.58 | *** join/#android infobot (i=ibot@pdpc/supporter/active/TimRiker/bot/apt) |
| 11:54.58 | *** topic/#android is For All Your Android Discussion Needs |
| 11:55.18 | anno^da_ | yeah I will try that :-) |
| 11:55.30 | anno^da_ | but it could be right. |
| 12:00.25 | anno^da_ | 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. |
| 12:01.49 | anno^da_ | and not setting parameters leads me to no parameters set :P |
| 12:11.52 | plusminus_ | check the imports |
| 12:12.14 | plusminus_ | this produces no code-errors: |
| 12:12.28 | plusminus_ | myLinLay.addView(mySurfaceView,0, new ViewGroup.LayoutParams(ViewGroup.LayoutParams.WRAP_CONTENT, ViewGroup.LayoutParams.WRAP_CONTENT)); |
| 12:15.36 | anno^da_ | hmm I'm getting InvalidParams supplied to android.widget.LinearLayout@.... |
| 12:16.46 | anno^da_ | http://nopaste.info/f53ba124a5.html |
| 12:17.04 | anno^da_ | (sorry for the indents they are caused by the no paste site) |
| 12:19.53 | plusminus_ | hm, then try Linearlayout.Layoutparams: http://nopaste.info/d4c9cf3f65.html |
| 12:20.44 | plusminus_ | why don't you "add" it by working with setVisibility(View.GONE); or similar? |
| 12:21.38 | plusminus_ | no marketing-guy here? |
| 12:22.04 | *** join/#android matt_c (n=mcroydon@137.147.45.66.cm.sunflower.com) |
| 12:22.16 | anno^da_ | 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 ? |
| 12:23.43 | anno^da_ | Your last example made it working |
| 12:23.46 | anno^da_ | thank! |
| 12:23.49 | plusminus_ | :) |
| 12:23.50 | anno^da_ | +s |
| 12:23.55 | anno^da_ | Dankeschön :-) |
| 12:24.00 | plusminus_ | Kein Problem |
| 12:33.41 | anno^da_ | 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 ? |
| 12:41.40 | *** join/#android muthu (n=sushmu@59.92.64.182) |
| 12:51.08 | *** join/#android zhobbs_ (n=zach@mail.guardianmfg.com) |
| 12:54.34 | *** join/#android inZane- (i=nemo@dslb-084-058-011-062.pools.arcor-ip.net) |
| 12:57.21 | *** join/#android jsilvaa (n=jsilva@142.150.154.107) |
| 12:58.40 | *** join/#android sayers (n=sayers@c-76-20-182-119.hsd1.mi.comcast.net) |
| 13:06.01 | *** join/#android buster (n=buster@lostmind.org) |
| 13:06.04 | buster | o/ |
| 13:22.21 | *** join/#android d3ce1t (n=jose@144.Red-88-2-126.staticIP.rima-tde.net) |
| 13:34.18 | *** join/#android yakischloba (n=jake@c-24-17-53-6.hsd1.mn.comcast.net) |
| 13:34.43 | *** join/#android d3ce1t (n=jose@144.Red-88-2-126.staticIP.rima-tde.net) |
| 13:34.51 | *** join/#android yakischloba_ (n=jake@c-24-17-53-6.hsd1.mn.comcast.net) |
| 13:36.47 | michaelnovakjr | howdy |
| 13:45.21 | *** join/#android cybereagle (n=cybereag@unaffiliated/cybereagle) |
| 13:48.33 | plusminus_ | michaelnovakjr: hi |
| 13:48.45 | michaelnovakjr | howdy |
| 13:48.49 | michaelnovakjr | what's up |
| 13:50.56 | muthu | yop |
| 14:00.18 | *** join/#android mxcl_ (n=mxcl@hq.last.fm) |
| 14:00.28 | buster | mh, am i the only one that hates that data-base crap on android? :( |
| 14:00.33 | buster | *database |
| 14:00.48 | muthu | no |
| 14:01.03 | muthu | it could be better |
| 14:01.38 | zhobbs_ | buster: what's wrong with it? |
| 14:02.10 | plusminus_ | I'd be fine if there were just standard tables we would access with raw querys. |
| 14:02.16 | buster | i mean this contactmethots, columns, projection, etc. etc. stuff |
| 14:02.25 | buster | plusminus_: yes! |
| 14:02.44 | muthu | contentprovider needs some work |
| 14:03.22 | buster | 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 :( |
| 14:03.29 | michaelnovakjr | dude |
| 14:03.32 | buster | *preferred_email |
| 14:03.43 | michaelnovakjr | the database implementation on android is awesome |
| 14:04.44 | michaelnovakjr | buster its very simple actually |
| 14:05.55 | buster | dont think so |
| 14:06.08 | buster | getEmailFromTelnr(X) would be very simple ;) |
| 14:06.54 | zhobbs_ | oh, ok...ContentProviders |
| 14:07.00 | buster | getContentProvider().query(random confusing arguments and arrays which are defined through dozens constants in dozens classes) is not, imho |
| 14:07.14 | muthu | agree |
| 14:07.17 | zhobbs_ | thought you meant the SQLite implementation |
| 14:07.24 | michaelnovakjr | uh |
| 14:07.25 | michaelnovakjr | \sender = cur.getString( cur.getColumnIndex( android.provider.Contacts.PeopleColumns.NAME ) ); |
| 14:07.37 | michaelnovakjr | that's not difficult |
| 14:07.41 | buster | its how to get the cursor |
| 14:08.22 | buster | normally i would just do "select name, email from x where x=y |
| 14:08.23 | buster | and done |
| 14:08.48 | michaelnovakjr | Cursor cur = managedQuery( android.provider.Contacts.People.CONTENT_URI, null, where condition, null ); |
| 14:08.57 | buster | anyway, i didn't mean to whine ;p |
| 14:08.59 | michaelnovakjr | where it says where condition you put what you are using to search |
| 14:09.15 | tomgibara | Moseycode takes another small step forwards: http://www.youtube.com/watch?v=KyvkVFr5ij4 |
| 14:09.37 | muthu | tomgibara: wonderful! |
| 14:09.56 | michaelnovakjr | buster, it is extremely simple |
| 14:10.20 | buster | michaelnovakjr: no. emails are hidden somewhere else i think |
| 14:10.20 | tomgibara | muthu: It's my first proper 3D demonstration - still has some way to go though. |
| 14:10.36 | michaelnovakjr | buster, you pull that column instead |
| 14:10.47 | anno^da_ | 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 |
| 14:11.09 | plusminus_ | tomgibara: wtf, you are insane... |
| 14:11.50 | zhobbs_ | tomgibara: damn, that is slick! |
| 14:12.02 | buster | wtf, tomgibara |
| 14:12.03 | tomgibara | plusminus_: probably, btw I finally replied to your email! Sorry about the delay. |
| 14:12.04 | buster | nice |
| 14:12.26 | michaelnovakjr | http://code.google.com/android/reference/android/provider/Contacts.ContactMethods.html --- buster check that out |
| 14:13.06 | plusminus_ | tomgibara: got it, fine |
| 14:13.29 | muthu | moseycode, really cool |
| 14:13.46 | tomgibara | 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 |
| 14:14.09 | muthu | tomgibara: what's a real world use case? |
| 14:14.13 | plusminus_ | tomgibara: will it take long to port it to android? |
| 14:14.39 | buster | michaelnovakjr: yeah, i know, but thanks. its confusing although ;p |
| 14:14.50 | buster | moseycode rocks :) |
| 14:15.04 | tomgibara | plusminus_: That is my android code base, but with a JMF/OpenGL wrapper to accomodate the missing android hardware |
| 14:15.16 | buster | ive shown it my colleague and he also says it rocks :) |
| 14:15.38 | tomgibara | muthu: Several advertisers are interested. |
| 14:16.40 | tomgibara | plusminus_: Of course real world performance is completely unknown, I can't do anything about that without hardware (damn it!) |
| 14:17.32 | plusminus_ | muthu: serveral use-cases will arise |
| 14:17.36 | plusminus_ | think of that |
| 14:18.07 | *** join/#android dasilvj (n=dasilvj@did75-1-81-57-20-118.fbx.proxad.net) |
| 14:18.14 | plusminus_ | you see a poster of a movie and point your camera on it. Suddenly the poster becomes alive, showing the trailer1 |
| 14:18.24 | plusminus_ | that would be stunning |
| 14:18.29 | muthu | wow! |
| 14:18.34 | buster | yay |
| 14:18.35 | buster | <3 |
| 14:18.40 | buster | that would be neat |
| 14:18.40 | anno^da_ | :D |
| 14:18.41 | zhobbs_ | neat |
| 14:18.44 | tomgibara | one use-case I would really like to pursue is games |
| 14:18.52 | tomgibara | each person shares the same board (in 3D possibly) |
| 14:18.56 | dmoffett | tomgibara that is very slick. |
| 14:19.02 | tomgibara | but they don't necessarily see the same things |
| 14:19.06 | plusminus_ | as you see its really possible (the trailer thing) |
| 14:19.18 | tomgibara | eg. fog of war effects are possible |
| 14:20.02 | plusminus_ | imo moseycode will rock in Adc2 with real devices |
| 14:20.15 | plusminus_ | i'd bet my nuts... |
| 14:20.28 | tomgibara | especially with it running on a mobile phone - each person can sit around the same pieces (marked with barcodes) |
| 14:20.29 | zhobbs_ | hah |
| 14:20.56 | tomgibara | but only the player who owns the piece can see the private information - that sort of thing. |
| 14:25.32 | *** join/#android Darkeye11547 (n=Craig@dsl253-084-234.hou1.dsl.speakeasy.net) |
| 14:27.39 | buster | want want want want! :) |
| 14:27.54 | Darkeye11547 | want what/ |
| 14:27.55 | Darkeye11547 | ? |
| 14:30.38 | buster | moseycode <3 |
| 14:31.42 | Darkeye11547 | I'd google for it, but my ISP's DNS seems to be down at the moment. |
| 14:32.17 | plusminus_ | Darkeye11547: http://www.youtube.com/watch?v=KyvkVFr5ij4 |
| 14:32.30 | Darkeye11547 | Sorry, no DNS. |
| 14:32.51 | Darkeye11547 | I'd click, but I'd just get address not found. |
| 14:33.36 | buster | 16:33 [FreeNode] -!- Irssi: youtube.com: 208.117.236.69 208.65.153.251 208.65.153.253 208.65.153.238 |
| 14:33.42 | buster | there ;) |
| 14:33.43 | Darkeye11547 | Could I bother someone to google "open dns" and find me a new server? |
| 14:33.46 | Darkeye11547 | many thanks |
| 14:33.49 | plusminus_ | try http://208.65.153.251/watch?v=KyvkVFr5ij4 |
| 14:33.54 | Darkeye11547 | *clicks* |
| 14:34.18 | buster | 213.148.129.10 |
| 14:34.35 | buster | should be my dns. found it to be quite fast (in germany, though) |
| 14:34.48 | anno^da_ | nice tomgibara. Do I understand that right that you store the content to which the barcodes point at? |
| 14:34.54 | Darkeye11547 | Spiffy |
| 14:35.37 | *** join/#android mikez5 (n=lockwood@74.125.60.1) |
| 14:35.56 | Darkeye11547 | I've seen a few demos of the tech before, is this one actually available? |
| 14:36.16 | buster | as available as android i guess :p |
| 14:36.18 | anno^da_ | http://www.tomgibara.com/android/moseycode/releases/0.2.1/ |
| 14:36.50 | Darkeye11547 | Sweet. |
| 14:36.58 | buster | 16:36 [FreeNode] -!- Irssi: tomgibara.com: 89.21.23.7 |
| 14:37.01 | tomgibara | 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). |
| 14:37.03 | buster | oh.. ok . :p |
| 14:37.04 | Darkeye11547 | I'm sure someone's already made a QR and Semacode reader as well. |
| 14:37.41 | tomgibara | Darkeye11547: Google for one :) Their library is called zxing |
| 14:37.44 | anno^da_ | Great. |
| 14:38.15 | anno^da_ | Is is possible to link content that lies on my own server to the chamber that I registered at your site ? |
| 14:38.28 | Darkeye11547 | I'm just kinda pissed off because the few readers that already exist don't work on my current phone. |
| 14:39.21 | tomgibara | 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. |
| 14:39.50 | anno^da_ | Great. |
| 14:39.58 | tomgibara | 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). |
| 14:40.00 | anno^da_ | I get new ideas for my applications now. :D |
| 14:41.06 | anno^da_ | ah well thats great I'm just reading through your site right now |
| 14:41.19 | anno^da_ | later on I have to get my camera here attached to Android |
| 14:41.53 | anno^da_ | (if I'm skllled enough to get it working :) ) |
| 14:42.36 | tomgibara | anno^da_: I made an effort to make it as straightforward as possible, the h |
| 14:42.47 | tomgibara | help is pretty good |
| 14:43.13 | anno^da_ | yeah I saw that. I'd come back to you if I dont get it working but it should be possible. :-) |
| 14:43.36 | *** join/#android Darkeye115471 (n=Craig@dsl253-084-234.hou1.dsl.speakeasy.net) |
| 14:45.04 | *** join/#android matt_c_ (n=mcroydon@137.147.45.66.cm.sunflower.com) |
| 14:49.23 | *** join/#android Darkeye115472 (n=Craig@dsl253-084-234.hou1.dsl.speakeasy.net) |
| 14:49.37 | Darkeye115472 | Blarg, still no connection, even with the new DNS nameserver. |
| 14:54.45 | buster | doesnt work? |
| 14:55.21 | buster | dunno.. last time i tried the dns from another provider, it worked.. but maybe they closed it to customers only meanwhile |
| 14:55.54 | Darkeye115472 | huh, that's weird. Another machine on the network is getting through just fine... Must be the pc, I guess. Gonna reboot |
| 14:56.00 | *** part/#android Darkeye115472 (n=Craig@dsl253-084-234.hou1.dsl.speakeasy.net) |
| 14:56.19 | buster | <PROTECTED> |
| 14:56.19 | buster | 208.67.220.220 |
| 14:56.26 | buster | that the OpenDNS one |
| 14:56.28 | *** join/#android yakischloba (n=jake@rnkfoods.com) |
| 14:56.39 | buster | well.. when he comes back ;) |
| 15:03.50 | alex2308 | i switched back from opendns to my isp ones |
| 15:03.53 | alex2308 | opendns sucked |
| 15:04.16 | buster | wouldnt know a reason to take another dns |
| 15:04.25 | buster | (than the isp one) |
| 15:04.34 | alex2308 | isp patch was late here |
| 15:04.38 | buster | in fact i didnt even know about openDNS some seconds ago ;) |
| 15:04.44 | alex2308 | so i switched to opendns for a while |
| 15:04.48 | buster | ah well |
| 15:12.03 | zhobbs_ | claiming sept presales for t-mobile android phone: |
| 15:12.04 | zhobbs_ | http://tmonews.com/2008/08/android-may-be-here-sooner-then-we-think/ |
| 15:13.31 | zhobbs_ | hmmm, is tmobile using gtalk accounts for something? "users will be required to have a Google Gmail account for the phone to work" |
| 15:16.44 | michaelnovakjr | i take the word of people who can't spell interesting with a grain of salt |
| 15:17.17 | zhobbs_ | michaelnovakjr: yeah, I saw that too |
| 15:17.45 | michaelnovakjr | but i guess that is what happens when anyone can get a website :) |
| 15:19.51 | alex2308 | zhobbs_ its not tmobile who makes you create a gmail acc, its google |
| 15:20.55 | michaelnovakjr | i still wouldn't take it as gospel |
| 15:21.24 | zhobbs_ | alex2308: I disagree |
| 15:21.25 | *** join/#android matt_c (n=mcroydon@gozur.sunflowerbroadband.com) |
| 15:21.44 | alex2308 | why |
| 15:22.12 | zhobbs_ | just don't see why you'd need a gmail account for a "vanilla" android install |
| 15:22.54 | alex2308 | activation |
| 15:23.02 | michaelnovakjr | for google talk, calendars, documents, mail |
| 15:23.08 | michaelnovakjr | it will all be google's services |
| 15:23.23 | alex2308 | google forced the gmail accounts |
| 15:23.30 | alex2308 | id still adwise anyone not to use the services |
| 15:23.31 | zhobbs_ | sure, but they imply you need it to use the phone |
| 15:23.57 | alex2308 | i think you need it (as you need an itunes acc) |
| 15:24.07 | yakischloba | alex2308: why would you advise people not to use the services? |
| 15:24.20 | zhobbs_ | alex2308: you don't need an itunes account |
| 15:24.39 | yakischloba | alex2308: honestly you're just speculating |
| 15:24.50 | michaelnovakjr | ah yes, speculating |
| 15:24.54 | michaelnovakjr | that is what all of this is |
| 15:25.09 | michaelnovakjr | when tmobile comes out with a statement or google does, then we can talk |
| 15:25.28 | jasta | i can't say that i'm even going to like Android. |
| 15:25.32 | jasta | as a phone |
| 15:25.38 | yakischloba | i hate how people just spew a bunch of crap every time some immature blog is posted |
| 15:25.55 | yakischloba | google this, tmobile that |
| 15:25.58 | jasta | after seeing 85772, blah. i don't like the progress. |
| 15:25.59 | alex2308 | yakischloba cause they collect tons of data |
| 15:26.00 | yakischloba | who fuckin cares until its actually happening |
| 15:26.54 | yakischloba | 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 |
| 15:27.00 | michaelnovakjr | 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 |
| 15:27.27 | yakischloba | alex2308: so to have it mined to give me non-invasive advertising is not even notable |
| 15:27.48 | michaelnovakjr | alex2308: hate to break it to you but your wireless carrier knows everything about what you do |
| 15:27.53 | jasta | btw, for the first time ever i saw an advertisement in my google maps mobile search results. |
| 15:28.01 | yakischloba | michaelnovakjr: yeah exactly. every time I see one of those articles I just imagine some greasy fool leering at his monitor through thick glasses |
| 15:28.02 | zhobbs_ | I use gtalk, but don't use gmail, docs, calendar |
| 15:28.05 | jasta | it was weird :) |
| 15:28.10 | alex2308 | michaelnovakjr no, there are laws prohibiting it in germany |
| 15:28.35 | michaelnovakjr | alex2308: its in the infrastructure, they do it |
| 15:28.48 | alex2308 | they dont |
| 15:29.06 | alex2308 | data is deleted instandly |
| 15:29.17 | michaelnovakjr | i highly doubt that |
| 15:29.48 | alex2308 | i control that |
| 15:29.59 | michaelnovakjr | i agree with jasta, i don't think its headed in a good direction |
| 15:30.08 | alex2308 | im in the enterprise privacy group |
| 15:30.18 | *** join/#android morrildl (n=chatzill@nat/google/x-8f8ef60ca358fcab) |
| 15:30.18 | yakischloba | wow. if there was ever a wrong guy behind the wheel. |
| 15:31.03 | jasta | 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. |
| 15:31.06 | jasta | just the platform |
| 15:31.21 | jasta | which will be OpenMoko all over again. hours and hours of work just to make it do what i want. |
| 15:31.33 | michaelnovakjr | alex2308: http://www.nytimes.com/2008/05/27/business/worldbusiness/27tapes.html?_r=1&ref=technology&oref=slogin |
| 15:31.38 | jasta | although, being a linux user, this is not necessarily out of the question :) |
| 15:31.39 | michaelnovakjr | it happens :) |
| 15:32.10 | yakischloba | 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. |
| 15:32.20 | alex2308 | michaelnovakjr: yeah, embarassing |
| 15:32.31 | anno^da_ | 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 |
| 15:32.35 | michaelnovakjr | ah, i didn't know he was in control of the red button |
| 15:32.40 | alex2308 | but its not easy to fully control every part of a 250.000 people company |
| 15:32.58 | tomgibara | anno^da_: what ip are you specifying? |
| 15:32.59 | anno^da_ | tomgibara: working now. |
| 15:33.03 | tomgibara | okay |
| 15:33.07 | anno^da_ | :) |
| 15:33.08 | michaelnovakjr | alex2308: that is why your statement of everything deleted instantly is false |
| 15:33.26 | yakischloba | oh yeah he is. he abuses his powerful position to steal peoples source code |
| 15:33.34 | tomgibara | anno^da_: you should be able to scan the barcodes that are on the website |
| 15:33.53 | tomgibara | anno^da_: assuming the webcam isn't built into your monitor :) |
| 15:34.39 | anno^da_ | well yes :D |
| 15:35.00 | anno^da_ | thats why I went upstairs looking for my wired cam :) |
| 15:36.16 | alex2308 | hehe true |
| 15:36.22 | alex2308 | anyway gotta go home |
| 15:36.26 | alex2308 | google ftl |
| 15:36.34 | michaelnovakjr | going to steal source code some more? |
| 15:36.45 | alex2308 | no, finished for today |
| 15:36.53 | yakischloba | alex2308: go home |
| 15:36.55 | michaelnovakjr | good, because that doesn't make you a programmer |
| 15:37.00 | michaelnovakjr | just a big ass |
| 15:43.43 | buster | woooh |
| 15:43.47 | buster | i like big asses |
| 15:46.02 | buster | and i can not lie! |
| 15:46.03 | buster | *dance* |
| 15:46.03 | buster | :p) |
| 15:46.31 | jasta | let's get a little more trigger happy on the /kickban's :) |
| 15:47.27 | yakischloba | aww how cute alex2308 has a website http://daloo.de/ |
| 15:47.45 | yakischloba | lets go download some spl0itz guys |
| 15:47.50 | michaelnovakjr | :) |
| 15:48.53 | yakischloba | a true show of genius. |
| 15:49.00 | buster | what are you so fucked up about, anyway? |
| 15:49.31 | yakischloba | buster: who? me? ;) |
| 15:50.11 | buster | yep |
| 15:50.22 | yakischloba | take it easy buddy :) |
| 15:50.35 | yakischloba | no reason to get upset |
| 15:50.40 | anno^da_ | tomgibara |
| 15:50.43 | anno^da_ | fascinating |
| 15:50.44 | anno^da_ | :) |
| 15:51.08 | tomgibara | anno^da_: Did it work then? |
| 15:51.41 | tomgibara | Note that the framerate is awful, not least because the frames have to be obtained over the wire |
| 15:52.56 | anno^da_ | yeah |
| 15:52.59 | anno^da_ | I know that |
| 15:53.06 | michaelnovakjr | yakischloba: the irc won't be the same as the release gets closer |
| 15:53.41 | yakischloba | michaelnovakjr: what do you mean by that? |
| 15:54.29 | anno^da_ | But it is pretty nice to see that working that good |
| 15:54.29 | buster | more people joining |
| 15:54.30 | anno^da_ | :) |
| 15:55.20 | buster | and asking "omgwtf, i want android on my nokia xyz. where can i dl setup.exe" ;) |
| 15:55.20 | michaelnovakjr | yakischloba: more annoying people actually |
| 15:55.20 | tomgibara | anno^da_: Yeah, when I first got it working, I wasted hours just futzing around with it |
| 15:55.20 | buster | or "i have minesweeper.exe but it doesnt load an my andropid phone, is it broken?!" |
| 15:55.20 | buster | :) |
| 15:55.27 | morrildl | buster: that's a feature |
| 15:55.33 | michaelnovakjr | actually that wouldn't be the case |
| 15:55.35 | buster | of course |
| 15:55.50 | yakischloba | michaelnovakjr: mm yeah. polluted channel soon. |
| 15:56.04 | michaelnovakjr | 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 |
| 15:56.38 | michaelnovakjr | buster although complaining about something as simple as content providers doesn't really say much |
| 15:56.59 | yakischloba | 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 |
| 15:57.03 | morrildl | 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 :) |
| 15:57.25 | buster | michaelnovakjr: i still say that its complicated |
| 15:58.04 | buster | 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 |
| 15:58.30 | yakischloba | buster: its different, not harder or more complicated. |
| 15:58.31 | michaelnovakjr | you must not understand concepts then :) |
| 15:58.45 | yakischloba | buster: i had a hard time getting used to it as well but that was my own shortcoming |
| 15:58.47 | michaelnovakjr | did you bother to read the documentation buster? |
| 15:58.58 | michaelnovakjr | yakischloba: weren't you also learning java? |
| 15:59.14 | yakischloba | michaelnovakjr: yes |
| 15:59.34 | jasta | morrildl: you must not have ever hung out in #c. |
| 15:59.47 | buster | 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.... |
| 16:00.08 | morrildl | jasta: no I haven't. And please don't burst my bubble, I want there to be a place like that ;) |
| 16:02.24 | yakischloba | 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. |
| 16:04.37 | michaelnovakjr | you can use sql, but databases are protected between apps, hence content providers :) |
| 16:05.23 | buster | 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.. |
| 16:08.56 | yakischloba | different strokes I guess. I wouldn't have done it this way, but its not my system. |
| 16:09.06 | buster | 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'" |
| 16:11.19 | buster | meh, actually forget about it. i guess i got some thing wrong anyway. i'm a bit nerved i guess :p |
| 16:12.13 | yakischloba | you sound like it :) |
| 16:13.18 | yakischloba | well as long as we're griping, I hate CSS. |
| 16:13.51 | yakischloba | Actually I just hate how bad I am at all UI design ;) |
| 16:15.00 | *** join/#android Mathiasdm (n=Mathias@vpnc105.ugent.be) |
| 16:19.17 | buster | yakischloba: did you test some different browsers with you css yetÃ? ;) |
| 16:19.30 | yakischloba | buster: no, I'm scared. |
| 16:19.30 | jasta | buster: the ContentProvider URI-based access mechanism is clumsy if you ask me. The abstraction is certainly very leaky. |
| 16:19.50 | jasta | though it is workable. |
| 16:25.24 | *** join/#android jsilvaa (n=jsilva@142.150.154.107) |
| 16:37.37 | *** join/#android sayers (n=sayers@c-76-20-182-119.hsd1.mi.comcast.net) |
| 17:06.34 | *** join/#android eton (n=eton@ppp-58-8-4-68.revip2.asianet.co.th) |
| 17:17.19 | *** join/#android SR71-Blackbird (n=nirvana@unaffiliated/sr71-blackbird) |
| 17:17.41 | *** join/#android plusminus_ (i=590e0deb@gateway/web/ajax/mibbit.com/x-86ba8752819fe072) |
| 17:27.42 | *** join/#android matt_c_ (n=mcroydon@gozur.sunflowerbroadband.com) |
| 17:27.51 | *** join/#android AttractiveApe (n=phil@office.gossamer-threads.com) |
| 17:39.56 | *** join/#android OpnSrc1 (i=harisha1@gateway/tor/x-67ec94a75339d6ea) |
| 17:47.54 | jasta | morrildl: Can you please follow-up about the MediaPlayer issues we discussed yesterday. |
| 17:48.30 | jasta | It is crucial that some functionality is introduced to permit applications to both stream and cache media streams. |
| 17:48.54 | jasta | 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. |
| 17:49.15 | jasta | The former seems best, but I can appreciate that if the MediaPlayer is implemented with IPC that this probably won't work well. |
| 17:49.38 | *** join/#android Dralspire (n=dralspir@56-196.126-70.tampabay.res.rr.com) |
| 17:51.08 | *** join/#android cutmasta (n=cutmasta@62.225.134.181) |
| 17:52.24 | *** join/#android umdk1d4 (n=umdk1d3@adsl-dynamic-64-79-45-15.bridgeband.net) |
| 18:01.02 | *** join/#android matt_c (n=mcroydon@gozur.sunflowerbroadband.com) |
| 18:02.01 | *** join/#android cutmasta (n=cutmasta@62.225.134.181) |
| 18:08.26 | *** join/#android buster (n=buster@lostmind.org) |
| 18:10.32 | *** join/#android pandora-- (n=pandora-@66.238.50.126.ptr.us.xo.net) |
| 18:25.28 | *** part/#android herriojr (n=herriojr@65.173.101.2) |
| 18:48.03 | jasta | yawn |
| 18:49.07 | umdk1d4 | nway |
| 18:51.00 | tomgibara | jasta: I'm pretty sure that cpu performance issues will kill the hope of MediaPlayer running from an InputStream |
| 18:52.18 | tomgibara | 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) |
| 18:53.04 | jasta | it currently supports http, and that's the only one i care about. |
| 18:53.47 | jasta | 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. |
| 18:53.56 | tomgibara | If it uses ranges, then saving a file might be very difficult to implement. |
| 18:54.17 | tomgibara | Yes, I can certainly see why it's useful. |
| 18:55.23 | jasta | this is simply unacceptable not to make it into the first production release. ugh. |
| 18:56.31 | jasta | 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. |
| 18:56.38 | jasta | let the usage of MediaPlayer worry about the implications there. |
| 18:57.03 | tomgibara | I think there will be lots of important -wanted- functionality missing in the 1.0 release. |
| 18:57.11 | jasta | the only caveat that MediaPlayer would need to know abou is that seeking shouldn't be reflected in the teed output. |
| 18:57.28 | jasta | tomgibara: this isn't just wanted functionality, this simple problem will destroy the possibility of my app being on Android. |
| 18:57.58 | tomgibara | jasta: But that latter point is the issue with using http range requests for seeking |
| 18:58.20 | *** join/#android zmig1 (n=lolanon@96.28.203.214) |
| 18:58.29 | tomgibara | I meant functionality that was both important _and_ wanted. |
| 18:58.52 | tomgibara | For me, the lack of any AOT or JIT was a major blow. |
| 18:59.01 | jasta | not to mention this is a credibility issue as Dan committed this functionality to be possible. |
| 18:59.23 | buster | tomgibara, isnt playing from a http connection what tunewiki does? it plays youtube videos |
| 19:00.13 | jasta | buster: tomgibara doesn't work on TuneWiki, and even still, TuneWiki quite likely doesn't cache this output. |
| 19:00.20 | jasta | Or they simply don't use MediaPlayer somehow. |
| 19:01.33 | buster | oh well, i didnt get all you wrote.. read somehow like playing streaming stuff from the web isnt possible.. go on then ;p |
| 19:01.39 | buster | *read |
| 19:01.49 | romainguy__ | tomgibara: For me, the lack of any AOT or JIT was a major blow. << you still haven't tried on a real device |
| 19:02.42 | jasta | romainguy__: who should i talk to about the MediaPlayer? |
| 19:03.28 | umdk1d4 | well tunewiki prolly uses rtsp links from youtube |
| 19:03.47 | umdk1d4 | since thats what the youtube mobile 3gp site uses |
| 19:13.06 | *** join/#android davidw (n=davidw@apache/committer/davidw) |
| 19:14.09 | tomgibara | 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. |
| 19:14.27 | tomgibara | 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. |
| 19:15.03 | tomgibara | Thus the lack of compilation will become important fairly quickly. |
| 19:16.24 | tomgibara | romainguy__: btw, if you have a device handy, I'm happy to send you my postal address ;) |
| 19:35.43 | *** join/#android eton_ (n=eton@ppp-58-8-4-68.revip2.asianet.co.th) |
| 19:45.58 | jasta | tomgibara: the Vogue can run Android, although the processor is way under class of what we all expect Android to be running on. |
| 19:46.11 | michaelnovakjr | jasta, but its still fast :) |
| 19:46.21 | michaelnovakjr | faster than the emulator that's for sure :) |
| 19:46.25 | jasta | yes, it does still run nicely. however, i have noticed something... |
| 19:46.50 | jasta | the emulator also runs very fast when you use a 240x320px skin instead of the default 320x480. |
| 19:47.04 | michaelnovakjr | interesting |
| 19:47.09 | jasta | the animations are much smoother. |
| 19:47.31 | jasta | so maybe the jump in performance is not actually that meaningful... though, the drawing acceleration on the official devices is likely quite significant. |
| 19:47.39 | tomgibara | I have always strongly suspected the basic IO (screen/sound etc) as being the aspect which makes the emulator slow. |
| 19:51.28 | *** join/#android lindever__ (n=eton@ppp-58-8-4-68.revip2.asianet.co.th) |
| 19:51.32 | tomgibara | Also, Google employs a lot of smart people - I'm sure that the performance will be good. |
| 19:51.55 | tomgibara | 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. |
| 19:51.56 | jasta | tomgibara: what do you make of the Dalvik maintainer saying that JIT just doesn't offer much for Dalvik? |
| 19:52.43 | tomgibara | That assumption is probably a valid one, except for the fact that developers will quickly push the boundaries and invalidate it (imo). |
| 19:53.36 | jasta | i don't recall it being an assumption, but rather a confirmed benchmark. |
| 19:53.45 | tomgibara | jasta: I think he's entirely right, but I've never written a VM. |
| 19:53.56 | jasta | the efficiency of their interpretor may well exploit architecture-specific features which make JIT pretty negligible. |
| 19:54.18 | jasta | i know at least that they are abusing a pretty common gcc feature not present on other compilers. |
| 19:55.13 | tomgibara | The gains that people might anticipate from a JIT are almost certainly overstated. |
| 19:55.46 | tomgibara | 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. |
| 19:55.55 | *** join/#android plusminus_ (i=590e0deb@gateway/web/ajax/mibbit.com/x-cfc41ad35ffb9a7e) |
| 19:56.00 | tomgibara | I'm thinking in particular of Lua |
| 19:56.09 | tomgibara | But... |
| 19:56.28 | *** join/#android SUSaiyan (n=SUSaiyan@cc84863-b.zwoll1.ov.home.nl) |
| 19:56.46 | jasta | tomgibara: right, so how can you be so certain that this will have an observed impact on performance? |
| 19:56.47 | tomgibara | There is a significant class of applications for which a small element of compilation will provide staggering improvements |
| 19:57.30 | jasta | 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. |
| 19:58.06 | jasta | 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. |
| 19:58.31 | tomgibara | 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. |
| 19:58.59 | jasta | But what can you infer from that? |
| 19:59.00 | tomgibara | Method calls are relatively expensive and apart from inlining and some other optimizations, you can't remove the cost |
| 19:59.22 | tomgibara | So compiling the code isn't going to gain you very much. |
| 19:59.47 | *** join/#android soulreaper (n=soul@HSI-KBW-085-216-123-245.hsi.kabelbw.de) |
| 19:59.51 | tomgibara | On the other hand - say you want to implement a parser |
| 20:00.39 | tomgibara | The most optimum way in most circumstances is a highly compact lookup table |
| 20:01.13 | tomgibara | 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) |
| 20:01.41 | tomgibara | In that instance, the overhead of the interpreter is going to absolutely kill your performance |
| 20:01.48 | *** join/#android plusminus_ (i=590e0deb@gateway/web/ajax/mibbit.com/x-7948d31b4a0a01b0) |
| 20:02.27 | tomgibara | Because what would simply be loads, branches and compares becomes 'decorated' with all of the work being done by the interpreter. |
| 20:03.11 | tomgibara | This is exactly the reason that all of the in-built code (like MediaPlayer, Bitmap, Audio) stays the hell away from InputStreams |
| 20:03.48 | tomgibara | because just the process of iterating over the byte array backing the buffer will significantly impair performance. |
| 20:03.53 | jasta | 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. |
| 20:04.39 | tomgibara | that may be a factor too, certainly |
| 20:04.40 | jasta | inherent in the language design and class implementations. |
| 20:05.11 | tomgibara | I doubt if its the main reason, since calls to an InputStream are relatively few compared to the number of bytes read |
| 20:05.48 | jasta | it would be interesting to see a non-numerical analysis of this. |
| 20:06.23 | tomgibara | Incidentally, my suggestion is an annotation that you can supply on a method which basically says to the apk installer: compile this AOT |
| 20:07.00 | jasta | well, we know from history that is a generally failing strategy. |
| 20:07.23 | tomgibara | 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. |
| 20:07.27 | jasta | humans are notoriously bad at microoptimizations by hand. |
| 20:07.29 | tomgibara | why? |
| 20:07.55 | jasta | for example, inline and register keywords in most C compilers are now completely ignored. or at least, the compiler does not interpret them literally. |
| 20:08.18 | jasta | because it has been shown that humans don't know what they're doing, but profilers do. |
| 20:08.39 | tomgibara | It's certainly open for abuse - but isn't everything. |
| 20:09.09 | tomgibara | 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 |
| 20:09.18 | tomgibara | That's fine |
| 20:10.12 | tomgibara | 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 |
| 20:10.35 | tomgibara | And it could be ignored if the VM just didn't support compilation |
| 20:10.50 | jasta | Well, one nice thing about this topic is that you can beat it to death with numerical analysis once the code is released. |
| 20:11.27 | jasta | In the mean time, I am going to crusade to get the MediaPlayer extended with my required features. |
| 20:11.34 | tomgibara | Not easily, you can't draw general conclusions from a single device |
| 20:12.55 | jasta | You can draw conclusions about the performance of that device. |
| 20:12.56 | *** join/#android eton (n=eton@ppp-58-8-4-68.revip2.asianet.co.th) |
| 20:13.14 | jasta | And that is quite useful. |
| 20:14.26 | jasta | I suspect that JIT or AOT compilation is difficult for another reason. Architecturally, Dalvik may be quite complicated, leading to real problems implementing this. |
| 20:14.51 | jasta | But I'm done speculating. Until we can analyize it, there's no use discussing it. |
| 20:15.43 | tomgibara | I don't disagree with either of those last two comments :) |
| 20:27.14 | *** join/#android meshuga_ (i=meshuga@c-67-183-112-152.hsd1.wa.comcast.net) |
| 20:31.10 | *** join/#android mxcl (n=mxcl@hq.last.fm) |
| 20:39.12 | *** join/#android eton_ (n=eton@ppp-58-8-4-68.revip2.asianet.co.th) |
| 20:57.06 | *** join/#android chab7 (n=kvirc@212.92.4.114) |
| 20:57.22 | chab7 | hi |
| 21:04.18 | *** join/#android zmig (n=lolanon@96.28.203.214) |
| 21:06.42 | *** join/#android dasilvj (n=dasilvj@did75-1-81-57-20-118.fbx.proxad.net) |
| 21:07.09 | *** join/#android eton (n=eton@ppp-58-8-4-68.revip2.asianet.co.th) |
| 21:31.48 | *** join/#android xavd (n=xavier@nat/google/x-a643fb40c9b9a1e7) |
| 21:34.27 | jasta_ | chab7: hello |
| 21:37.32 | *** join/#android eton_ (n=eton@ppp-58-8-4-68.revip2.asianet.co.th) |
| 21:46.13 | tomgibara | 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). |
| 21:49.25 | jasta | tomgibara: by what margin did you find? |
| 21:50.46 | jasta | btw, looking at the code for BitmapFactory, they are one in the same ;) |
| 21:51.39 | jasta | decodeResource() calls decodeStream. the only difference is that the stream is from res.openRawResource(), which possibly returns a more efficient InputStream. |
| 21:51.45 | jasta | or you could even be seeing something as simple as the kernel's read cache. |
| 21:53.09 | tomgibara | jasta: Read the bytecodes carefully and you'll see that they aren't ;) |
| 21:53.59 | jasta | i'll need a hint then, because i do not see what you see :0 |
| 21:55.08 | tomgibara | 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) |
| 21:55.42 | jasta | ahh yes, i see that you are correct. |
| 21:55.43 | tomgibara | 163628 byte JPG, takes approx 1230ms w/ stream and approx 1100ms w/ asset id |
| 21:56.34 | jasta | tomgibara: JPG file, you mean? |
| 21:56.46 | tomgibara | One proviso is that I wrap the asset stream in a buffered stream to avoid the instanceof test |
| 21:56.53 | tomgibara | That will add some overhead |
| 21:56.54 | tomgibara | yes |
| 21:57.07 | jasta | It's entirely possible that the kernel's read cache may still be in effect here, depending on how assets are read. |
| 21:57.17 | jasta | And yes, wrapped methods would have some overhead. |
| 21:57.58 | jasta | 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. |
| 21:58.14 | jasta | your test is to dissimilar to prove anything, and even then the benchmark margins are very small. |
| 21:58.21 | jasta | too* |
| 21:58.56 | jasta | 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. |
| 21:59.14 | jasta | and, above all else, a complex scheduler that can invalidate our results :) |
| 21:59.48 | 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. |
| 21:59.50 | jasta | but as i said, you'd need to write a JNI module in order to benchmark this even reasonably |
| 22:00.30 | tomgibara | why does JNI allow you to benchmark it more accurately? |
| 22:01.41 | tomgibara | (I know very little about producing reliable benchmarks) |
| 22:02.42 | jasta | tomgibara: Because here you are benchmarking two entirely different code paths that you can't see. |
| 22:02.51 | jasta | nativeDecodeAssert and nativeDecodeStream are both unknown to us. |
| 22:03.07 | jasta | nativeDecodeAsset, for example, may be quite a bit faster for reasons we can't see. |
| 22:03.39 | jasta | 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. |
| 22:03.56 | tomgibara | I see what you mean now |
| 22:03.59 | jasta | 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. |
| 22:04.03 | tomgibara | Yes, I can see that. |
| 22:04.17 | jasta | Then use a FileInputStream from Java for the benchmark. Make sure to use two different files too :) |
| 22:04.25 | jasta | don't let the kernel get the chance to cache either one |
| 22:04.41 | jasta | two different files, but with identical content, i mean. |
| 22:06.22 | jasta | 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 |
| 22:06.26 | jasta | and then run it again after it completes. |
| 22:06.33 | jasta | you will see wildly different results. probably a margin of 10% or more. |
| 22:07.27 | jasta | (fwiw, this is why numerical analysis usually sucks) |
| 22:08.40 | jasta | tomgibara: btw, this is something we could benchmark today. JNI is possible on Android. |
| 22:08.45 | jasta | and not much work, either. |
| 22:08.52 | tomgibara | Yes, I've always struggled to produce reliable benchmarks - it's so hard to generate a replicable environment |
| 22:09.06 | romainguy | 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 |
| 22:09.30 | romainguy | we also introduced a new API on BitmapFactory to load files from file descriptors instead of InputStreams |
| 22:09.31 | jasta | 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 :) |
| 22:09.50 | tomgibara | haha yes! |
| 22:10.25 | romainguy | it's the resolution of the JPG that matters, not its file size |
| 22:11.07 | jasta | romainguy: we're actually talking about the overhead of using an InputStream versus natively reading from a stream. |
| 22:11.14 | tomgibara | romainguy: I'd assume that (I know a little about image compression) - it's large. |
| 22:11.58 | romainguy | jasta: that's why we added an API with file descriptors |
| 22:12.06 | romainguy | but the different is really not big |
| 22:12.17 | romainguy | it had an impact when we were trying to load tons of small images |
| 22:12.32 | tomgibara | romainguy: such as map tiles ;) |
| 22:12.49 | jasta | romainguy: regardless, i don't know that feeding the MediaPlayer this way is what i really want anyway. |
| 22:12.56 | romainguy__ | tomgibara: no, not map tiles :)) |
| 22:12.58 | jasta | i mostly just want the MediaPlayer to be cachable. |
| 22:13.18 | *** join/#android dims (n=dims@c-66-31-154-33.hsd1.ma.comcast.net) |
| 22:13.32 | jasta | designing a media input stream would be tricky, unless you implicitly disabled seeks... |
| 22:14.37 | jasta | btw, i'm getting very nervous that Android is gonna ship without this ability. which would mean Five can't exist :( |
| 22:15.22 | tomgibara | jasta: Unless you use some ugly compromise. |
| 22:15.29 | jasta | There is no ugly compromise. |
| 22:15.41 | tethridge | jasta, you could always have "iFive" |
| 22:15.50 | AttractiveApe | snorts. |
| 22:15.52 | tomgibara | Downloading it in parallel :-/ |
| 22:16.08 | jasta | tomgibara: that isn't so much an ugly compromise as it is an entirely unworkable design :) |
| 22:16.08 | *** join/#android anno^da_ (n=anno^da@p5B07C768.dip.t-dialin.net) |
| 22:16.13 | AttractiveApe | tethridge: hiFive |
| 22:16.19 | jasta | bandwidth is a premium, it's already iffy whether you can even stream reliably. |
| 22:16.21 | tethridge | even better |
| 22:16.32 | AttractiveApe | hmm |
| 22:16.35 | AttractiveApe | or hiFi |
| 22:16.36 | AttractiveApe | I like that. |
| 22:16.44 | tomgibara | Or not caching it, but remembering that th user has played it and then scheduling it for download later (in an interruptible way) |
| 22:16.52 | tomgibara | They are very ugly, I know |
| 22:18.52 | tomgibara | 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. |
| 22:19.03 | jasta | tomgibara: they're not just ugly, they compromise an already ambitious design to the point that it won't work. |
| 22:19.20 | jasta | the user will see right through the abstractions and the experience would be terrible. |
| 22:19.50 | tomgibara | fair enough, you know the problem domain better than I do |
| 22:20.53 | jasta | well anyway, i'm on a mission now to get someone's attention who can fix this. |
| 22:27.54 | *** join/#android blueriver_ (n=Wizard_o@catv-50620aca.catv.broadband.hu) |
| 22:32.42 | *** part/#android blueriver_ (n=Wizard_o@catv-50620aca.catv.broadband.hu) |
| 22:35.38 | jasta | hehe, stupid phone died |
| 22:53.08 | *** join/#android BlackBsd (n=brian@72.168.193.117) |
| 23:05.31 | *** join/#android matt_c (n=mcroydon@137.147.45.66.cm.sunflower.com) |
| 23:08.46 | jasta | tomgibara: i'm coding up that better test of throughput differences between a JNI InputStream and natively reading. |
| 23:10.24 | *** join/#android Darkeye11547 (n=Craig@dsl253-084-234.hou1.dsl.speakeasy.net) |
| 23:10.37 | jasta | 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. |
| 23:11.33 | jasta | and it would be tricky to provide a stream that would work right |
| 23:11.48 | *** part/#android Darkeye11547 (n=Craig@dsl253-084-234.hou1.dsl.speakeasy.net) |
| 23:12.17 | tomgibara | jasta: java typically uses marking for limited seek ahead |
| 23:12.43 | jasta | i don't mean seek ahead. |
| 23:13.09 | jasta | the mediaplayer obviously can seek in all directions, arbitrary distances. |
| 23:14.25 | tomgibara | Some transports only support linear reads anyway (http w/o ranges is one example) |
| 23:14.45 | jasta | still, i think they could support this and just leave non-trivial implementations up to us. |
| 23:15.12 | tomgibara | I'm just off to bed now |
| 23:15.19 | jasta | im heading home from work |
| 23:15.27 | tomgibara | I look forward to hearing your results |
| 23:21.42 | *** join/#android bdjnk (n=bdjnk@ool-4572ad23.dyn.optonline.net) |
| 23:26.29 | *** join/#android Hai-Fai (n=jarmo@hoasnet-fe35dd00-42.dhcp.inet.fi) |
| 23:39.13 | *** join/#android yakischloba (n=jake@c-24-17-53-6.hsd1.mn.comcast.net) |
| 23:50.55 | *** join/#android Dougie187 (n=doug@c-69-244-215-210.hsd1.fl.comcast.net) |
