**** BEGIN LOGGING AT Thu Feb 21 02:59:57 2008 Feb 21 04:15:18 wow I forgot I was connected on this box Feb 21 04:38:46 can someone point me to a link that shows how to display an image in android? Feb 21 04:39:31 use an imageview Feb 21 04:39:59 probably some examples in the apidemos Feb 21 04:42:42 ok, I see, thanks Feb 21 04:51:30 there doesn't seem to be an imageview demo, and the docs are wrong here: http://code.google.com/android/devel/data/contentproviders.html Feb 21 04:51:44 how is this documentation wrong? Feb 21 04:52:02 under : Reading Retrieved Data Feb 21 04:52:13 ok ? Feb 21 04:52:14 jtoy: what are you trying to do? Feb 21 04:52:19 there is no stringColumn: imagePath = cur.getString(stringColumn); Feb 21 04:52:30 also: it says: getContentResolver().openInputStream(imagePath); Feb 21 04:52:50 but imagePath is initiliazed as a string, but openInputStream doesn't take a string Feb 21 04:53:01 ok Feb 21 04:53:12 I'll forward that Feb 21 04:55:08 is there an example of using an imageview?I cant seem to be ablt to find one online Feb 21 04:55:36 jtoy: have you looked in ApiDemos? Feb 21 04:56:07 i looked through some of them Feb 21 04:56:33 I'll just gregp through them, sorry for the annoyance Feb 21 04:57:29 are you familiar with using other view objects (textview, etc)? Feb 21 04:57:55 yeah, I'm just not sure how to get the data into the ImageView Feb 21 04:58:10 what's your data? Feb 21 04:58:16 ImageView.setImageXXX() Feb 21 04:58:28 there's like setImageResource, setImageDrawable, etc Feb 21 04:59:02 the data I am trying to use is the contacts photo form the content provider Feb 21 05:00:13 setImageBitmap( BitmapFactory.decodeStream( inputstream) ) Feb 21 05:03:59 i got to go, i'll be back soon, fy the problem i still have is going from : int pathColumn = cur.getColumnIndex(android.provider.Contacts.PeopleColumns.PHOTO); to turning that into a InputStream so I can read the binary data Feb 21 05:04:28 good luck :) Feb 21 05:14:53 jtoy: you might be interested in ContentResolver.openInputStream Feb 21 05:15:07 that is the preferred method for reading binary data from a provider. Feb 21 05:15:15 and actually, the only method. Feb 21 06:01:23 eclipse and the emulator apparently are not speaking to each other tonight... Feb 21 06:01:43 they are very moody Feb 21 06:09:44 aah Eclipse ^^ Feb 21 06:18:02 back Feb 21 07:00:16 man oh man do the graphics for my game absolutly stink Feb 21 07:00:26 i wish i had some more artistic skill Feb 21 07:02:05 :) Feb 21 07:02:08 what kind of game? Feb 21 07:04:16 zhobbs: i'm trying ot make a tetrinet clone for my android submission Feb 21 07:04:29 but it's looking like i might miss the deadline, because i have to do all the gfx myself Feb 21 07:05:15 jerkface03: you still have a month Feb 21 07:05:44 well, this isn't all i do tho. i goto school fulltime. Feb 21 07:05:55 the only time i find to work on this is by not sleeping ;) Feb 21 07:06:08 which explains why i'm talking in this channel at 4am in the morning Feb 21 07:06:11 find some open source games with graphics you can borrow Feb 21 07:06:28 zhobbs: ya i'm defanitly looking at that right now Feb 21 07:06:28 ie tetrinet :) Feb 21 07:06:53 desperate times call for desperate measures :P Feb 21 07:07:20 I don't get java's calendar...I'm doing this: calendar.set(2008,2,21) Feb 21 07:07:42 zhobbs: Java's calendar is 0 based for days and months Feb 21 07:07:42 date.get(Calendar.DAY_OF_WEEK) == Calendar.FRIDAY Feb 21 07:07:55 damn Feb 21 07:07:58 yeah Feb 21 07:08:04 ok, thanks :) Feb 21 07:08:06 it's been a pain for everybody for years Feb 21 07:08:20 just look for "java date" or "java calendar" on Google and you'll find many many rants :) Feb 21 07:08:21 not zero based for years Feb 21 07:08:27 nope Feb 21 07:08:31 it does not matter for years anyway Feb 21 07:08:43 because our years are zero based :) Feb 21 07:09:04 Ahh...if only our months and days were Feb 21 07:09:04 (and leap years computation would be very painful if the base index was different) Feb 21 07:09:13 or if only programming languages stopped being 0 based Feb 21 07:10:09 Hmm, now it's saying it's wednesday....(thursday here) Feb 21 07:10:27 ahah Feb 21 07:10:43 try using the constants instead Feb 21 07:10:50 like Calendar.FEBRUARY Feb 21 07:11:28 maybe the day is not zero based then Feb 21 07:11:31 the month definitely is Feb 21 07:11:51 ok so the day is 1 based Feb 21 07:11:56 and month is 0 based Feb 21 07:12:06 therefore you want 2008,1,21 Feb 21 07:12:42 hehe, works now Feb 21 07:12:47 that's some crazyness Feb 21 07:12:54 see, even after 10 years of Java I'm still messing this up Feb 21 07:13:03 yeah they changed it in Java 1.1 if I remember correctly Feb 21 07:13:14 the idea was that you could use the month as an index in an array Feb 21 07:13:27 without having to allocate an array of size 13 Feb 21 07:13:31 yeah Feb 21 07:13:36 talk about premature optimization... :) Feb 21 07:13:48 anyway, so the best approach is to use the Calendar constants Feb 21 07:13:50 yeah, I would have been happy with months[m-1] :) Feb 21 07:22:29 Java's calendar APIs seem really clumsy to me. Feb 21 07:23:15 file:///usr/local/lib/android/docs/reference/android/content/ContentResolver.html#getDataFilePath(android.net.Uri) -- hehe Feb 21 07:23:20 "Don't touch this. Go away." Feb 21 07:23:28 they are Feb 21 07:23:33 hence the JSR to replace/fix them Feb 21 07:24:15 jasta: localhost URLs don't work well across OS's :) Feb 21 07:24:47 hehe, I get a 404 on that one also Feb 21 07:44:48 romainguy___: oh, yeah Feb 21 07:45:05 well just look up ContentResolver.getDataFilePath ;) Feb 21 07:45:08 the documnetation is hilarious Feb 21 07:55:34 yeah I know :) Feb 21 07:55:39 I remember the check in ^^ Feb 21 07:56:20 you'd think it'd get marked deprecated Feb 21 07:56:31 it's not exactly the same meaning Feb 21 07:57:02 we should have hidden it from the javadocs ^^ Feb 21 07:57:09 how do you mean? it doesn't even seem to be relevant anymore since the ContentProvider has openFile now which doesn't actually yield a path. Feb 21 07:57:29 deprecated just means there are preferred way to do it Feb 21 07:57:37 in this case we don't want anybody to even call this method :) Feb 21 07:57:41 because it should not exist Feb 21 07:58:40 i would say that is one interpretation of deprecated, but it is not what it means. Feb 21 08:00:15 i would say it would be appropriate to deprecate that function. Feb 21 08:00:17 I have to admit I've never seen @deprecated used in such a way Feb 21 08:00:22 no Feb 21 08:00:30 what would be appropriate would be to remove it altogether Feb 21 08:00:52 right, but by convention since you have not already, it would be called deprecated :) Feb 21 08:01:06 no because it's not deprecated :) Feb 21 08:01:11 it should never have existed Feb 21 08:01:17 it's not meant to be replaced or anything Feb 21 08:01:29 again, that's not what deprecated means ;) Feb 21 08:01:51 that's how we used it in the JDK at Sun Feb 21 08:02:17 (and actually the replacement methods were always calling the deprecated ones :) Feb 21 08:02:51 yeah, but that type of thinking is dangerous. just because you've always used a word incorrectly in the past doesn't make it right :) Feb 21 08:03:00 .. Feb 21 08:03:31 since it was basically Sun's policy I believe that's how they intended it to be used Feb 21 08:03:35 but whatever Feb 21 08:03:56 still, dangerous thinking ;) Feb 21 08:04:23 I also know how deprecated are used in the wild Feb 21 08:04:47 many many people don't give a shit about it ^^ Feb 21 08:05:00 of course, i'm overly pedantic, but still it's important to use words as they are in English, not just as they are in engineering ;) Feb 21 08:05:09 and I agree Feb 21 08:05:20 but deprecated has a historical meaning in Java Feb 21 08:05:39 hehe, am i picking on you? :) Feb 21 08:06:10 no Feb 21 08:06:57 didn't mean to annoy, i'm sorry. Feb 21 08:07:05 I'm not annoyed Feb 21 08:07:11 don't thing so highly of yourself :) Feb 21 08:07:24 I've battled hordes of angry Swing users for years, I don't care anymore :)) Feb 21 08:07:24 i wouldn't dare thing it. Feb 21 08:07:40 hehe, sorry sorry Feb 21 08:07:43 lol Feb 21 08:08:04 (and ListView ruined my day ;-) Feb 21 08:08:06 i'm in one of those moods :) Feb 21 08:08:24 hey, i have a productive topic for you Feb 21 08:08:39 what is the difference between setClickable and setEnabled for a button? there must be some nuance i can't imagine here... Feb 21 08:08:49 yep and it's kinda easy actually Feb 21 08:08:52 setEnabled seems to visually affect the widget, whereas setClickable does not. is that the only difference? Feb 21 08:09:06 clickable, like focusable or other "able" properties are meant to be intrinsic properties of a widgets Feb 21 08:09:15 i.e. something that's not supposed to change during the lifetime of a View Feb 21 08:09:33 when a View is clickable, it means it knows how to handle clicks and want to handle them Feb 21 08:09:40 however, enabled is a runtime state Feb 21 08:09:47 oh, so setEnabled is the preferred transient method. Feb 21 08:09:51 yes Feb 21 08:10:05 gotcha, thanks. Feb 21 08:10:23 and setEnabled() as a side effect Feb 21 08:10:29 it will draw the widget in a disabled state Feb 21 08:10:38 right, which is a desirable one in my case. Feb 21 08:10:42 exactly Feb 21 08:11:01 unfortunately we receive many "bug reports" or questions from developers misusing these properties Feb 21 08:11:08 and basically playing a bit too much with focusable :(( Feb 21 08:11:20 I guess it shows our API must be improved Feb 21 08:11:32 get used to it, people are going to be misusing Android for as long as it's available to misuse. Feb 21 08:11:40 oh I know :) Feb 21 08:12:24 we should just make those intrinsic properties read-only and be done with it :) Feb 21 08:12:44 that's something of the opposite extreme. why not just document them better? :) Feb 21 08:13:20 that is, don't do apply the usual Javadoc yada yada "This method sets the view clickable", "This method sets the view enabled". Instead, explain the side-effects, and the nuances ;0 Feb 21 08:13:29 I agree and it's planned Feb 21 08:13:41 unfortunately I also know that many won't read the doc :)) Feb 21 08:13:51 so the first step would rather make the API less confusing Feb 21 08:13:56 then document it extensively Feb 21 08:14:29 like for instance, right now you can setFocusable(false) and setFocusableInTouchMode(true) which doesn't really make sense Feb 21 08:14:34 I once started (but never finished) a project to scan my doxygen comments and try to catch things like "Add sums." applied to functions prototyped int addSums(int a, int b); Feb 21 08:14:49 so we're thinking of merging them to a single property called setFocusMode() for instance Feb 21 08:15:41 i am really looking forward to Android's release. i am going to write so many stupid little games ;) Feb 21 08:15:58 i love like Freecell and Chess, but they're so hard to find on mobile phones it's pathetic. Feb 21 08:16:24 and i'd love to see a networked Chess game. that'd be great. Feb 21 08:16:25 really? Feb 21 08:16:39 well, everything costs money and i'm so cheap Feb 21 08:16:48 :) Feb 21 08:17:15 plus, the paid games are usually some of the worst. i bought a chess game ages ago for something crazy like $15 and the AI was so easy i think it beat me like once Feb 21 08:17:24 it would just move the queen right out in the open first chance it got Feb 21 08:17:35 and would fail to protect itself against OBVIOUS attacks. Feb 21 08:17:50 yeah I quickly stopped playing on PDAs/phones Feb 21 08:18:01 I stick to the goold old portable consoles Feb 21 08:18:08 and i've yet to see any capable networked version Feb 21 08:18:21 that would be the best. a way to just pop on to play a quick game on a server like yahoo games or whatever. Feb 21 08:18:38 I want Java WebStart on my phone! Feb 21 08:18:44 Android should make the free game landscape for mobile devices much improved. Lots of folks will just tinker and build games. Feb 21 08:18:50 (very useful to play Quake 2 deathmatches in class) Feb 21 08:19:17 myself included. i have committed to at the very least creating a Klondike and Freecell game for my girlfriend :) Feb 21 08:19:31 uhuh Feb 21 08:19:37 I can never commit myself to writing games Feb 21 08:19:43 the last one I wrote was for a Palm IIIe Feb 21 08:19:58 it's so easy, though. i nearly finished the Klondike game in a weekend. Feb 21 08:20:07 the only reason I stopped was because my ADC project moved to the foreground Feb 21 08:21:31 anyway, i am so excessively rambling tonight. i'm annoying myself Feb 21 08:21:35 bed time :) Feb 21 08:22:31 good night man Feb 21 09:22:03 sigh, the Sun java compiler misses a lot of really easy optimization opportunities. Feb 21 09:22:28 jasta: because it's not its job in regular Java apps Feb 21 09:22:44 in the 1.1 series, the compiler used to do more optimizations Feb 21 09:22:50 they now prefer to rely on Hotspot Feb 21 09:22:56 who is much much smarter Feb 21 09:23:00 (new StringBuilder()).append(foo).append('=').append(baz); and (new StringBuilder()).append(foo + '=' + baz); are not the same. Feb 21 09:23:19 one requires an extra allocation. Feb 21 09:23:36 yeah, this compilation has changed a few times since Java 1.0.x Feb 21 09:24:02 what reason can you see for not taking that opportunity? it's slapping the compiler in the face. Feb 21 09:24:18 I have no idea Feb 21 09:24:18 just a programmer trying to shortcut several keystrokes but it's very clear that an object can be reused there. Feb 21 09:24:31 but I would not be surprised if they rely on Hotspot Feb 21 09:24:38 or if there's some weird shit in the JLS Feb 21 09:24:58 anyway Feb 21 09:25:05 that's a large part of my general argument as to why it's unfair to call Java "slow". the compiler misses so many incredible opportunities to optimizate that it just hardly seems fair to even compare it to anything else. Feb 21 09:25:19 yeah but that's wrong Feb 21 09:25:31 because as I said Java does not need to do these optimizations at compile time Feb 21 09:25:35 Hotspot gives you so much more Feb 21 09:25:52 anyway, for Android, just don't rely on javac for optimizations Feb 21 09:25:56 it's not even trying Feb 21 09:27:01 romainguy___: Well, that's part of the reason why that's not very good. It heavily fragments the optimization paths, thus impairing Java's portability. Feb 21 09:27:21 I don't quite see how it impairs portability Feb 21 09:27:37 and javac is just *a* compiler Feb 21 09:27:37 Not being very familiar with HotSpot, I think there is still a call for balance between the JVM's opts and the compilers opts. Feb 21 09:27:51 Believe me, the HotSpot guys know what they're doing Feb 21 09:28:28 romainguy___: Well, how does HotSpot improve J2ME performance? Feb 21 09:28:40 I never said it did Feb 21 09:28:46 I'm explaining why javac is the way it is Feb 21 09:28:48 I know that you didn't, and I know that it doesn't. Feb 21 09:29:05 I don't know what Java ME's bytecode verifier does though Feb 21 09:29:14 I suppose it does some optimizations on its own Feb 21 09:29:26 Probably very little, frankly. Feb 21 09:29:36 but Java ME VMs don't have quite the same track record as HotSpot Feb 21 09:29:43 Where the compiler could do so much for HotSpot, J2ME, and any other weird target (say, Android) Feb 21 09:29:56 it would not do anything for HotSpot :) Feb 21 09:30:09 Well, it could refactor it some :) Feb 21 09:30:20 some J2ME VM do some optimizations on the fly Feb 21 09:30:29 Or at least give it a smaller chunk of code to chew on. Feb 21 09:30:32 like the Nokia Serie 60 ones Feb 21 09:30:37 jojo`taf: I believe they have a JIT Feb 21 09:30:42 yes Feb 21 09:30:48 jasta: optimized is not necessarily smaller :p Feb 21 09:31:07 i remember a nasty bug on the Nokia 6630 JIT :/ Feb 21 09:31:12 That hurts Feb 21 09:31:17 romainguy___: Of course. Feb 21 09:31:45 And there's also the fact that javac is the reference implementation of the Java compiler Feb 21 09:32:00 and as such I wouldn't be surprised that they sometimes prefer to output straightforward bytecode Feb 21 09:32:11 but that's just speculation Feb 21 09:32:24 romainguy___: I still consider this a portability issue. If you intend to produce a dumb compiler, and precisely 1 very advanced JVM, your critical opts can only port as far as that 1 JVM, which is not very. Feb 21 09:32:29 not very far* Feb 21 09:32:41 that's not a portability issue Feb 21 09:32:45 it's merely a performance issue Feb 21 09:33:09 I don't know anything about the mobile VMs Feb 21 09:33:20 I am referring to the portability of the implementation's performance, of course. Javac is part of the implementation used, even if the target JVM is not written by Sun. Feb 21 09:33:31 I know some run on a dedicated CPU that understand Java bytecode Feb 21 09:34:09 and optimizations by the Java compiler will always be dwarfed by what a JIT can do for your CPU architecture Feb 21 09:34:16 so again, why bother? :) Feb 21 09:35:00 Because, as I said when I introduced the topic, some optimizations are just so obvious. Feb 21 09:35:22 and again, since the VM can do it better... Feb 21 09:35:52 There is a very large set of opts that they both can do equally well. Feb 21 09:36:07 jasta: why can't you just trust what those guys do? Feb 21 09:36:30 I worked with the javac and HotSpot guys and I am sure they have very good reasons to do what they do Feb 21 09:36:51 Because perhaps their scope is more narrow than mine? Hello, Android doesn't use the VM I'd trust them to do well. Feb 21 09:37:23 but Android does not execute their bytecode... Feb 21 09:37:30 remember it goes through dx? Feb 21 09:38:17 Yes, and if dx wants to perform these opts it can. But then, why not centralize the obvious ones into javac? What advantage is there that doesn't tread the line of oversimplification. Feb 21 09:38:37 jasta: because there's no reason for the javac team to do so Feb 21 09:39:05 they have all the optimizations in HotSpot and it's probably much better for them and for us *when we run Java apps on desktops and servers* Feb 21 09:39:10 It just seems that the decision to do this is based on the assumption that Java will not be ported to environments Sun hasn't predicted or would want to control. Feb 21 09:39:13 which was the main intent of javac... Feb 21 09:39:39 And Sun can punish those ports with a total lack of centralized optimizations in their standard toolchain. Feb 21 09:39:53 but javac is just *a* compiler Feb 21 09:40:03 if you decide to use javac it's your problem Feb 21 09:40:04 not Sun's Feb 21 09:40:14 feel free to use Eclipse's Feb 21 09:40:24 (which is actually what you are using probably) Feb 21 09:40:30 (in which case you cannot blame javac :) Feb 21 09:40:40 The compilers job, principally, is to assemble a dialect aiding humans to a dialect aiding computers. Excessive allocations in that translation is not a feature :) Feb 21 09:40:59 Well actually I tested with javac ;) Feb 21 09:41:05 Then use Eclipse's Feb 21 09:41:10 or any other compiler for that matter Feb 21 09:41:25 but stop assuming you know better than those guys :) Feb 21 09:41:33 :) Feb 21 09:41:56 romainguy___: This is not an issue of "knowing better", this is an issue of having a different scope. Feb 21 09:42:26 then don't blame javac because it's used in a weird way by Android :) Feb 21 09:42:37 javac is the way it is for very good reasons Feb 21 09:42:43 if you don't like them, use another tool Feb 21 09:42:46 that's all there is to it Feb 21 09:42:52 and whining about it won't change a thing Feb 21 09:43:11 (or use all those fancy obfuscators/bytecode optimizers) Feb 21 09:44:00 Ugh. Feb 21 09:45:29 That is a fair point, though. Javac can define its own ideal usage scenarios, and ignoring them is our own fault. Feb 21 09:46:06 (and also memory allocations are very very very cheap in HotSpot :) Feb 21 09:46:56 Anyway, I know I can make Java code run fast with Android so I don't really mind in the end :) Feb 21 09:47:12 I guess I'm just frustrated by the landscape of Java programming. Writing code with a particular implementation in mind seems so alien to me. Feb 21 09:47:30 romainguy___: How do you mean? You personally, or that dx optimizes well? Feb 21 09:47:50 I was talking both about the code we write and the perfs of our VM Feb 21 09:48:17 Err yes, I meant dalvik not dx. Feb 21 09:48:23 jasta: well I do remember writing C code in special ways when I was working on GameBoy Advance :) Feb 21 09:49:36 Fair enough. C has scrambled my brain I guess. Feb 21 09:50:13 jasta: you should write/use a C bytecode compiler to write your app for the contest ;-) Feb 21 09:51:23 It's not that I don't understand Java well, it's just that there is such a massive disconnect between the language and its implementations compared to the languages I'm used to. Feb 21 09:51:49 C has many implementations of course, but really only one that anyone gives a shit about: gcc + glibc. Feb 21 09:52:02 Perl and Python as well. Feb 21 09:52:55 yep Feb 21 09:53:06 I worked with Java for 10 years Feb 21 09:53:12 on a variety of platforms and VMs Feb 21 09:53:13 Perhaps I should just focus my attention on learning Android's implementation very well. Feb 21 09:53:29 so I'm used to think of Java the language, the compiler and then the VM :) Feb 21 09:53:40 (writing Java code for Palm III wasn't fun :)) Feb 21 09:54:12 That's a long time for a 25 year old :) Feb 21 09:54:28 yep :) Feb 21 09:54:34 But I can claim at least 10 on C ;) Feb 21 09:54:51 Really, 10 is the only fair number. Those first two years didn't count. Feb 21 09:55:22 I got started with BASIC first, but that phase didn't last long. Feb 21 09:55:30 same thing for me Feb 21 09:55:46 I didn't really start to feel like a programmer until I switched to Linux when I was 14. Feb 21 09:55:52 but I quickly dropped C Feb 21 09:56:01 I still cannot believe I have to type the .h by hand :) Feb 21 09:56:34 romainguy___: C thrives on convention, so very little is part of the language itself. Feb 21 09:56:51 (that's why you have to type the .h *grin*) Feb 21 09:56:52 I know Feb 21 09:56:54 and I really like C Feb 21 09:57:07 but I'm still amazed that today's IDEs don't generate header files for you Feb 21 09:57:32 and then I don't like to manage memory by hand :)) Feb 21 09:57:46 That's why I really picked up Objective-C only recently when they added a GC in Leopard Feb 21 09:57:54 I still like C, but it is so bruttally hard to learn. That's why it needs to go away. Feb 21 09:58:11 I would say that about C++ Feb 21 09:58:12 not C Feb 21 09:58:30 romainguy___: Well, C++ should have never been. Feb 21 09:58:39 agreed :) Feb 21 09:59:07 What I mean is that C is so prone to abuse; and abuse with very heavy consequences. It is not very accessible in that way, and increasingly less so as time passes. Feb 21 09:59:36 sure but at least it's versatile, efficient and quite universal Feb 21 09:59:51 It is truly not a difficult language to write once you understand the difference between how it was defined and how it is perceived. But that difference takes too long to learn, and too many people just don't want to be bothered by it. Feb 21 10:00:05 Yes, I always enjoy the debate that "Java is more portable than C", because it's so absurd ;) Feb 21 10:00:15 it depends on how you define more portable Feb 21 10:00:22 if you talk about source code, sure, that's untrue Feb 21 10:00:23 No, it depends on how you define "C". Feb 21 10:00:28 that too Feb 21 10:00:36 but this remark often applies to the binaries Feb 21 10:00:46 If you define C as ANSI C89, then it's a downright absurd statement :) Feb 21 10:00:49 and I have to admit I like distributing only one set of binaries :) Feb 21 10:01:50 I actually chose my server for the ADC project to be in C principally because I knew it would need to be heavily portable. I even imagine potentially porting it to one of those hackable media routers :) Feb 21 10:02:53 anyway Feb 21 10:02:56 time to go to bed Feb 21 10:02:59 g'night Feb 21 10:03:00 romainguy___: Yes, that is nice, however for the common case of writing code for UNIX hosts, you don't even need to distribute binaries. There is such a large network of people who will do it for you :) Feb 21 10:03:07 jasta: yeah Feb 21 10:03:17 but as a user there's ONE THING I hate Feb 21 10:03:23 when the app is only distributed as source code Feb 21 10:03:27 it annoys me very much :) Feb 21 10:03:35 apt-cache search? :) Feb 21 10:03:57 still :) Feb 21 10:04:03 Anyway, go to bed. I've wasted far too much of your time today :) Feb 21 10:18:08 romainguy___: you seem up pretty late Feb 21 10:25:43 * jasta wonders if i should care about SQL injection attacks in an Android ContentProvider Feb 21 10:57:24 doubt it Feb 21 10:57:43 but maybe, maybe.... Feb 21 15:47:37 how do you get the phone number of the device itself? Feb 21 16:01:00 jtoy: http://code.google.com/android/reference/android/telephony/TelephonyProperties.html Feb 21 16:02:16 cool, is there a way to get the timezone ? Feb 21 16:03:01 Yes, in J2SE there is, but Android currently doesn't implement it. Feb 21 16:03:04 Or at least, didn't in m3. Feb 21 16:04:02 it would be TimeZone.getDefault() Feb 21 16:09:33 hopefully that gets added soon Feb 21 16:26:36 i stayed up all night coding and only got 3 hours of sleep... Feb 21 16:26:39 now i can hardly stand :) Feb 21 16:27:00 ouch Feb 21 16:27:10 gotta go to work Feb 21 16:27:19 just sleep at work Feb 21 16:27:23 i'm gonna carbo-load this morning Feb 21 16:27:45 got to a stall, have a seat and sleep for an hour or two Feb 21 16:28:16 (someone I used to work with would do that) Feb 21 16:36:56 i've done that once :) Feb 21 16:37:03 but mostly on accident Feb 21 16:39:53 occassionally, i stay up so late it's like i think work doesn't exist ;) Feb 21 16:40:46 it'll be a long day Feb 21 16:42:48 for sure :( Feb 21 16:43:18 it's tough managing a girlfriend and a full time job trying to write for android Feb 21 16:43:31 yep Feb 21 16:43:32 last night i wasn't able to start coding until midnight Feb 21 16:44:21 i had to actually work out an explicit schedule with my girlfriend as to when i get "geek nights" :) Feb 21 16:45:01 hehe, I live with mine and work from home so we see enough of each other no matter what :) Feb 21 16:45:40 can I use the browser to login to a website and then have my program be able to use the site via the cookie set in the browser? Feb 21 16:45:44 http://www.xkcd.com/386/ Feb 21 16:52:03 are there docs/links that explain how to deal with logging into a site so that apps have access to the site? Feb 21 16:52:31 jtoy: do you want to display the output of the site or just process it? Feb 21 16:53:59 I jsut want to be able to use the cookie set via a regular browser session so that I dont need to write code for the app to store the pass/username everytime my app needs to access the website, instead the app will just send some requests to the website and will already be authenticated via the cookie Feb 21 16:54:19 currently I am only pushing data to the website, so I dont need to display output, but that will probably change later Feb 21 16:55:06 Take a look at HttpClient and WebView Feb 21 16:55:38 jtoy: you'll have to store the cookie somehow Feb 21 16:55:47 jtoy: might as well just store the password Feb 21 16:56:06 cookie seems safer, no? Feb 21 16:56:26 thats too bad, on the iphone I can just log in via the browser and then all apps can access that cookie Feb 21 16:56:47 as 2 totally seperate actions Feb 21 16:56:50 well, maybe if you're using sessions it would be safer, but a straight up cookie not sure Feb 21 16:57:52 cookies are the mechanism that supports sessions, zhobbs. Feb 21 16:58:30 yep, but you can have the actual data stored int he client's cookie, or just a session id with the data stored on the server Feb 21 16:58:59 storing the cookie is only marginally safer than the password since it cannot be reversed to a password. but it otherwise offers the same level of privilege as a password. Feb 21 16:59:26 right, so to me that still sounds like cookies are safer Feb 21 16:59:41 that said, the best way to store a password is to hash it, but that can only work if the server supports logins via a hash, not just a plain-text password. Feb 21 17:00:02 in that way, the password is as safe as the cookie, but it is more flexible. Feb 21 17:00:25 at any rate, you probably shouldn't store the password since you'll want the user to re-authenticate once the session times out, no? Feb 21 17:01:24 yes, so I really like having the browser managing the cookies and then my app having access to the browser, but not sure if that is possible Feb 21 17:02:00 it sounds like you are wanting to mechanize the browser, right? Feb 21 17:02:40 if that is the proper wording, this is a common technique on the iphone though Feb 21 17:03:14 I think he wants to know the user's session for a website that they have visited in the past in tthe standard mobile browser Feb 21 17:03:18 you know that a WebView will manage cookies local to your application, right? Feb 21 17:03:45 I didnt know that Feb 21 17:03:51 zhobbs: Oh, I see. Hmm, that could be tricky with the current SDK. Feb 21 17:04:14 jtoy: Yes, it will automatically make a webview.db file local to your app and store things there just like the browser does, local to its package. Feb 21 17:04:53