| 00:24.33 | *** join/#android yakischloba (n=jake@c-67-160-47-243.hsd1.wa.comcast.net) |
| 00:24.37 | *** join/#android dpino (n=dpino@cm217166.red91-117.mundo-r.com) |
| 00:41.51 | *** join/#android sayers (n=sayers@c-76-20-182-119.hsd1.mi.comcast.net) |
| 00:52.10 | jasta | yakischloba: i'm posting that example now |
| 00:52.34 | yakischloba | sweet. |
| 00:52.44 | yakischloba | sounds like something that would be important to know in the future. |
| 00:52.53 | jasta | yes, probably :) |
| 01:01.08 | *** join/#android eton_ (n=eton@ppp-58-8-8-222.revip2.asianet.co.th) |
| 01:08.50 | sayers | What is the more appreciated way of saving text-like data with android, on the SD card or in a sql db? |
| 01:09.08 | yakischloba | That would depend on what the data is.. |
| 01:09.21 | jasta | and how you plan to use it. |
| 01:09.39 | jasta | and whether or not you want to require that your users have SD cards. |
| 01:09.54 | sayers | Well I plan on using it in a Database like structure but I don't know to much about how quick the Sql db is on the phone |
| 01:10.07 | jasta | then you should use sqlite, obviously. |
| 01:10.16 | yakischloba | sqlite can run on a wrist watch. don't worry about it ;) |
| 01:10.21 | sayers | alright |
| 01:10.22 | jasta | i assure you, the performance of sqlite3 will greatly exceed whatever you come up with on a flat file. |
| 01:10.31 | sayers | wowza |
| 01:10.45 | sayers | Just have to figure out how to use sqllite 3 |
| 01:11.47 | yakischloba | thats what I'm figuring out right now. I'm used to MySQL as far as writing my own queries. |
| 01:12.19 | sayers | I've done very little database work so it'll be new either way |
| 01:12.24 | jasta | sqlite3 has great documentation. |
| 01:12.29 | sayers | yay |
| 01:12.36 | yakischloba | the example Notes application gives some good basic examples of how to use it with android. |
| 01:12.41 | jasta | sayers: why yay? you haven't been reading any documentation so far :) |
| 01:12.52 | sayers | jasta, Yes I have! |
| 01:13.26 | sayers | I just tend to ask broad questions here which point me at the documentation :) |
| 01:19.52 | yakischloba | sqlite looks like its going to annoy me. |
| 01:20.05 | Kraln | why do you say that |
| 01:23.37 | yakischloba | looks like its harder to do date/time stuff than in other dbs. i don't see stuff like timediff() |
| 01:24.16 | yakischloba | not that this is actually a problem. i'm just crying |
| 01:34.13 | *** part/#android Dougie187 (n=doug@c-68-42-59-199.hsd1.fl.comcast.net) |
| 01:35.41 | *** join/#android eton_ (n=eton@ppp-58-8-6-18.revip2.asianet.co.th) |
| 01:38.26 | *** join/#android eton (n=eton@ppp-58-8-6-18.revip2.asianet.co.th) |
| 01:39.16 | sayers | yakischloba, just use java features? |
| 01:39.40 | yakischloba | sayers: thats what I'm doing, obviously. I was just hoping to use something I already knew how to use ;) |
| 01:39.52 | sayers | Ah |
| 01:40.14 | yakischloba | So I guess its up to the developer to decide how they want to store dates in sqlite |
| 01:40.20 | sayers | Well, I don't think running through that tutorial will help me.. I think I'll have to learn by writing and fixing |
| 01:40.24 | yakischloba | unix timestamp format I think?.. |
| 01:40.48 | yakischloba | sayers: if you don't understand relational databases then thats the first step |
| 01:41.09 | sayers | I still need a bit more Android work I think. |
| 01:42.03 | jasta | yakischloba: yeah, in sqlite3, there are basically only 3 types, TEXT, BLOB, and variouses sizes of integers. |
| 01:42.06 | jasta | various* |
| 01:42.20 | jasta | There's no date/time type as far as the storage is concerned. |
| 01:42.21 | *** join/#android yeonhoo (n=yeonhoo@189.58.81.201.adsl.gvt.net.br) |
| 01:42.28 | yakischloba | jasta: yeah. So I assume the most efficient way is to store it as an integer? |
| 01:42.32 | jasta | So, you declare a field DATE or TIME simply as an aesthetic ;) |
| 01:42.49 | jasta | Generally the UNIX timestamp in UTC is a good strategy for storing times, yes. |
| 01:42.54 | yakischloba | Ok. |
| 01:43.38 | jasta | Do note that Java insists on describing and interpreting times as the UNIX timestamp but in milliseconds, not seconds. |
| 01:45.00 | yakischloba | yeah I'm reading that now |
| 01:46.00 | jasta | sigh, i might have to admit defeat on this lame blocking I/O problem :) |
| 01:46.20 | jasta | the big gotcha left here is that you obviously can't use this trick to close a socket which hasn't been opened yet. |
| 01:46.36 | jasta | so, if it's hanging in a blocked connect(), there's nothing you can do but wait for the socket timeout. |
| 01:47.09 | jasta | which means you essentially cannot safely synchronize the death of the I/O thread. |
| 01:47.18 | yakischloba | :( |
| 01:47.40 | jasta | at least for the common case you can nuke it quickly. |
| 01:47.54 | jasta | but a blocking connect() is not so rare. a host that is not responding to you, for example, would do it. |
| 01:48.54 | jasta | Well, shot. |
| 01:48.57 | jasta | shoot* |
| 01:49.33 | jasta | I guess you could use a hybrid strategy here... |
| 01:49.57 | jasta | it would simplify the code non-the-less to know that ONLY executeMethod is uninterruptible |
| 01:51.10 | *** join/#android zer0her0 (n=Z@cpe-74-67-48-253.nycap.res.rr.com) |
| 01:56.03 | *** join/#android aculich (n=aculich@c-76-24-31-156.hsd1.ma.comcast.net) |
| 01:57.50 | sayers | would I want to look up activities to figure out how to forward one activity to the next? |
| 02:00.51 | *** join/#android mr__daniel (n=sysrq@e177157179.adsl.alicedsl.de) |
| 02:02.40 | sayers | alas it's in the api demo |
| 02:03.00 | yakischloba | ;) |
| 02:03.59 | sayers | I forgot about them and now that I'm only 90% out of the android concepts they sorta make sense :D /me does happy dance |
| 02:22.50 | *** join/#android SR71-Blackbird (n=nirvana@unaffiliated/sr71-blackbird) |
| 02:34.24 | *** join/#android aculich (n=aculich@216-15-124-74.c3-0.smr-ubr3.sbo-smr.ma.cable.rcn.com) |
| 02:47.19 | *** join/#android bdjnk (n=bdjnk@ool-4572ad23.dyn.optonline.net) |
| 02:48.44 | sayers | What designates one XML layout for one class and another xml layout for another class? |
| 02:53.04 | f00f- | the tags used |
| 02:53.08 | f00f- | elements specify classes |
| 02:53.14 | f00f- | android classes are autoscoped |
| 02:53.17 | f00f- | if using own calss |
| 02:53.21 | f00f- | specify full package path |
| 02:53.29 | f00f- | <com.sayers android:id=... |
| 02:54.16 | gambler | ei oh ei....is there a better tool for diagrams than Visio? |
| 02:55.46 | sayers | f00f-, so that is done on every tag before android ? |
| 02:58.09 | *** join/#android romainguy_ (n=gfx@nat/google/x-bfe01f6c107c903d) |
| 02:58.23 | sayers | I don't see that in any of the examples |
| 03:00.43 | jasta | sayers: do you mean what associates a layout to an activity? the activity calls setContentView() |
| 03:01.30 | sayers | I think I'm thinking to hard, that is ingeniously simple! |
| 03:03.10 | jasta | also do note that nothing is inherent to the XML layout system that relates it to an Activity |
| 03:03.32 | jasta | XML layouts generically inflate to View hierarchies. setContentView() merely inflates the view hierarchy, and then sets it as its root hierarchy. |
| 03:03.42 | jasta | So, for example, you can compose multiple XML layouts into one, and people often do. |
| 03:04.02 | jasta | For example, it is common to describe a list item in a separate XML layout, and inflate it for each item in a list as necessary. |
| 03:04.24 | jasta | Android even has an efficient system in place to re-use those inflated views, assuming that they are sufficiently generalized (each list item has the same basic layout) |
| 03:04.37 | jasta | This efficiency is hidden away in the details of list adapters. |
| 03:04.46 | jasta | Well, partially hidden. |
| 03:07.09 | *** join/#android muthu (n=sushmu@59.92.89.234) |
| 03:08.03 | ttuttle | jasta: /me particularly likes that bit of cleverness. |
| 03:10.31 | *** join/#android The_PHP_Jedi (n=ThePHPJe@unaffiliated/thephpjedi/x-000002) |
| 03:12.41 | *** join/#android romainguy__ (n=gfx@69.36.227.135) |
| 03:18.23 | *** join/#android romainguy___ (n=gfx@69.36.227.135) |
| 03:19.35 | sayers | Hm... problem is I added a new xml in layout but the setContentView() doesn't seem to have it... |
| 03:23.56 | jasta | can you please rephrase that so it doesn't sound like gibberish? |
| 03:24.46 | sayers | sure |
| 03:27.27 | sayers | I created a new XML file for another GUI with one of my actives, I'm creating an application with multiple activities. However in the new activities java code when I try and load the gui the auto completion feature does not show anything called torcCalc which is the name of the GUI xml file |
| 03:28.38 | jasta | Do you mean that the R.java file was not regenerated to include the new member in R.layout.? |
| 03:28.46 | sayers | yes! |
| 03:28.59 | jasta | Why didn't you just say that, instead of all that other gibberish? |
| 03:29.16 | sayers | I forgot that was the median for all GUI's |
| 03:29.24 | jasta | Anyway, there is probably an error in your XML layout: check your build environment's output. |
| 03:29.30 | jasta | sayers: The what? |
| 03:29.41 | sayers | it handles resources. |
| 03:29.59 | jasta | Dude. I cannot follow the way that you speak. |
| 03:31.05 | jasta | Like, what could R.java being the "median for all GUI's" mean? |
| 03:31.58 | sayers | Ignore that , that was me thinking out loud, sorry. In any event yes it was a naming convention error. |
| 03:32.00 | jasta | R.java is simply an autogenerated file to give you integer handles to your bundled resources, including layouts, strings, drawables, etc. The package manager assigns package-specific unique ids to these resources so they aren't referenced by name. |
| 03:32.13 | jasta | R.java is just a developer convenience so that you can still reference them by name, even though the system does not. |
| 03:33.36 | sayers | I'm in the "learning how things are done" stage, and yes I did search the doc for it but I saw how they had nothing specific in their layouts. |
| 03:34.25 | jasta | Anyway, my advice to you remains the same: if R.java is not regenerated, it is likely because there is a fatal error in parsing the resources you defined. |
| 03:34.31 | jasta | So check your build output |
| 03:36.15 | sayers | yes |
| 03:36.22 | sayers | and your advice worked |
| 03:36.59 | sayers | I feel bad for asking lots of questions :( because I now have another one eek |
| 03:37.02 | yakischloba | Jeez I can't wait for my RAM to arrive. 1GB doesn't go far with 10 tabs in FF, eclipse, the emulator, and a bunch of other junk open. |
| 03:37.11 | sayers | yakischloba, Agreed |
| 03:37.19 | jasta | sayers: There is no need to feel bad, just learn to ask good questions. |
| 03:37.20 | sayers | yakischloba, what operating system are you on? |
| 03:37.27 | jasta | Because you talk a lot of gibberish I can't follow most of the time. |
| 03:37.49 | yakischloba | I'm on OS X 10.4. |
| 03:38.15 | sayers | Should a back button be included in the UI of the application or is the hardware button supported ? |
| 03:38.57 | sayers | to return back to the last activity that is, I know I saw something about it in 'the life of an activity' |
| 03:39.12 | jasta | sayers: We assume the hardware back button is recommended for UIs, but we really don't know for sure. |
| 03:39.40 | sayers | jasta, and to support that look at the activity doc ? |
| 03:39.54 | jasta | It's very hard to appreciate how the end user experience will be with what we have now |
| 03:40.07 | jasta | sayers: the life of an activity has nothing to do with the physical back button. |
| 03:40.32 | sayers | then how would I support them wanting to return to the main screen of my application ? |
| 03:41.11 | jasta | sayers: If it makes sense for your application, you would include a button. However it's unlikely that it makes sense. |
| 03:41.19 | jasta | Do you have a smart phone now? |
| 03:41.23 | sayers | no |
| 03:41.57 | jasta | Well, then you are at a great disadvantage for having a familiarity with the type of user experience Android is trying to create. |
| 03:42.17 | sayers | Indeed |
| 03:42.36 | jasta | Regardless, smart phones allow the user to navigate various screens of an application with elaborate multi-tasking features. |
| 03:43.06 | yakischloba | How can I reset my emulator environment? For example, I want to go back to not having any sqlite databases created. Is that the most practical approach? |
| 03:43.32 | jasta | For example, in an e-mail application, opening the main app from the launch will return to the last screen they were on. if they want to perform some other action, they should be able to somehow cancel out of what they are doing and get back to a new launcher. |
| 03:43.43 | jasta | this can be done iether using the back button, or more explicitly through menu items. |
| 03:43.51 | jasta | for example, if a user opens email, presses compose, then starts typing a message |
| 03:44.02 | jasta | goes back to the home screen, launches another app, then later returns |
| 03:44.28 | jasta | the compose screen should still be up. if that's not what they meant, they can press back again, or go to menu -> cancel message, then return to the inbox where they can press some compose button again or go menu ->c ompose |
| 03:45.04 | jasta | This is just an example of one type of application, but the point is that it is your job to provide explicit activity control in a way that makes sense, but also to trust that the user can use the window manager to navigate effectively (the back button, the home launcher, etc) |
| 03:45.07 | mickrobk_ | yakischloba: try "emulator -wipe-data" |
| 03:45.26 | sayers | Ah. |
| 03:46.44 | jasta | sayers: One general strategy I recommend when designing a mobile UI is to remember that your application is not *THE* application the user cares about. It is simply one of many, and in fact they probably spend very little time interacting with it. |
| 03:47.01 | jasta | This is easier to understand when you've spent some time with a smart phone already, even if its a crappy one like Windows Mobile. |
| 03:47.29 | sayers | ah |
| 03:47.30 | yakischloba | mickrobk_: Thanks |
| 03:47.39 | sayers | I don't have that kind of budget |
| 03:47.45 | jasta | Your app should flow smoothly based on what a user would want to do, and not be forced into the architecture of your application. |
| 03:48.05 | sayers | Makes sense , powerful gui concepts. |
| 03:51.43 | *** join/#android rwhitby (n=rwhitby@nslu2-linux/rwhitby) |
| 04:06.07 | *** join/#android slango (n=kde4@unaffiliated/iamethos) |
| 04:13.47 | *** join/#android romainguy_ (n=gfx@adsl-76-241-19-32.dsl.pltn13.sbcglobal.net) |
| 04:14.37 | *** join/#android romainguy__ (n=gfx@72.14.224.1) |
| 04:22.49 | yakischloba | jeez, all this stuff is beginning to make a slight bit of sense to me. hurray |
| 04:23.03 | f00f- | powerful. |
| 04:23.17 | yakischloba | totally |
| 05:19.57 | *** join/#android romainguy_ (n=gfx@adsl-76-241-19-32.dsl.pltn13.sbcglobal.net) |
| 06:22.08 | *** join/#android duey (n=Nick@203.96.223.40) |
| 06:26.44 | jasta | so, does anyone want to proof my example to make sure i've not done something retarded? |
| 06:31.56 | yakischloba | screw it, lets see |
| 06:32.12 | yakischloba | you've had me waiting about 10 hours now |
| 06:32.28 | jasta | well i was doing research |
| 06:32.29 | jasta | and reviewing code |
| 06:32.33 | yakischloba | i've managed to actually start writing my application in that time |
| 06:32.37 | jasta | i have found something interesting |
| 06:32.52 | jasta | http://code.google.com/p/android-random/source/browse/trunk/CancelHttpGetExample/src/CancelHttpGetExample.java |
| 06:33.06 | jasta | this is the interesting thing i found: http://mail-archives.apache.org/mod_mbox/hc-httpclient-users/200506.mbox/%3c20050615164118.GA4936@uml24.umlhosting.ch%3e |
| 06:33.40 | jasta | basically, the last hurdle to making this truly interruptible is actually a bug in HttpClient (sort of), in that it doesn't take advantage of new Java 1.4 features that can make this work. |
| 06:33.53 | jasta | so HttpClient 4.x may have this fixed. I will need to follow-up to confirm. |
| 06:34.00 | jasta | that would be excellent, as that is the version android is expected to use. |
| 06:36.51 | yakischloba | hmm |
| 06:37.45 | jasta | (but doesn't currently) |
| 06:41.34 | yakischloba | interesting |
| 06:44.09 | *** join/#android eton_ (n=eton@ppp-58-8-18-195.revip2.asianet.co.th) |
| 06:44.19 | yakischloba | bed time now. I'm sure I'll be exploding with questions all weekend now that I've finally gotten rolling though. |
| 06:44.25 | yakischloba | night |
| 06:59.44 | *** join/#android inZane-_ (i=nemo@dslb-084-058-051-019.pools.arcor-ip.net) |
| 07:14.36 | *** join/#android anno^da_ (n=anno^da@p5B07E1C9.dip.t-dialin.net) |
| 07:41.10 | *** join/#android borism (n=boris@194.126.108.2) |
| 08:04.08 | *** join/#android eton (n=eton@ppp-58-8-18-131.revip2.asianet.co.th) |
| 08:23.38 | *** join/#android dasilvj (n=dasilvj@163.5.255.63) |
| 08:31.27 | *** join/#android cutmasta (n=cutmasta@62.225.134.181) |
| 08:36.57 | *** join/#android eton (n=eton@ppp-58-8-209-26.revip2.asianet.co.th) |
| 09:00.43 | *** join/#android dueynz (n=duey@203.96.223.40) |
| 09:45.37 | *** join/#android mari (n=mari@offb-d9be237c.pool.mediaWays.net) |
| 09:56.06 | *** join/#android dueynz (n=duey@203.96.223.40) |
| 10:03.10 | *** part/#android muthu (n=sushmu@59.92.89.234) |
| 10:20.05 | *** join/#android eton_ (n=eton@ppp-58-8-7-37.revip2.asianet.co.th) |
| 10:22.25 | *** join/#android anno^da_ (n=anno^da@p5B07E1C9.dip.t-dialin.net) |
| 10:31.58 | *** join/#android dims (n=dims@c-66-31-154-33.hsd1.ma.comcast.net) |
| 10:51.19 | *** join/#android Dougie187 (n=doug@c-68-42-59-199.hsd1.fl.comcast.net) |
| 11:34.53 | *** part/#android Dougie187 (n=doug@c-68-42-59-199.hsd1.fl.comcast.net) |
| 11:48.01 | *** join/#android eton (n=eton@ppp-58-8-7-37.revip2.asianet.co.th) |
| 12:14.00 | *** join/#android zhobbs_ (n=zach@mail.guardianmfg.com) |
| 12:15.43 | *** part/#android rwhitby (n=rwhitby@nslu2-linux/rwhitby) |
| 12:34.45 | *** join/#android Dralspire (n=dralspir@56-196.126-70.tampabay.res.rr.com) |
| 12:38.06 | *** join/#android Dralspire (n=dralspir@56-196.126-70.tampabay.res.rr.com) |
| 12:40.15 | *** join/#android aculich (n=aculich@c-66-31-201-16.hsd1.ma.comcast.net) |
| 12:47.30 | *** join/#android muthu (n=sushmu@59.92.93.28) |
| 13:03.18 | *** join/#android jsilvaa (n=jsilva@142.150.154.107) |
| 13:11.18 | *** join/#android merck (n=merck@122-116-117-188.HINET-IP.hinet.net) |
| 13:11.46 | merck | here is Google Android channel? |
| 13:17.19 | tomgibara | merck: yes |
| 13:17.56 | merck | tomgibara: thx |
| 13:18.18 | merck | tomgibara: this channel for SDK user? |
| 13:21.02 | tomgibara | yes |
| 13:21.18 | tomgibara | for Android developers basically |
| 13:26.23 | merck | tomgibara: oh, thanks. |
| 13:27.41 | *** join/#android dims (n=dims@c-66-31-154-33.hsd1.ma.comcast.net) |
| 13:41.23 | *** part/#android pjz (n=pj@zachs.place.org) |
| 14:22.28 | *** join/#android sayers (n=sayers@c-76-20-182-119.hsd1.mi.comcast.net) |
| 14:22.34 | *** join/#android AstainHellbring (n=Administ@unaffiliated/astainhellbring) |
| 14:30.25 | jasta | sweet, just confirmed that HttpClient4 does in fact abort a blocking connect(). |
| 14:33.20 | jasta | now to test whether the release in M5 has this code... |
| 14:33.24 | jasta | crosses his fingers |
| 14:38.32 | jasta | hmmmmm. it does, but it might be buggy :) |
| 14:38.34 | jasta | i'll have to test it. |
| 14:41.40 | zhobbs_ | jasta: noticed this story: http://www.anddev.org/viewtopic.php?p=9316#9316 |
| 14:49.24 | *** join/#android sayers_ (n=sayers@c-76-20-182-119.hsd1.mi.comcast.net) |
| 14:59.09 | *** join/#android yakischloba (n=jake@c-67-160-47-243.hsd1.wa.comcast.net) |
| 14:59.11 | jasta | zhobbs_: i remember reading about this as well |
| 14:59.49 | jasta | actually i read another comment from oleg elsewhere too |
| 15:00.02 | jasta | but i would imagine the timeline here works out for google. they are probably trying to encourage a stable httpclient 4.x release |
| 15:00.13 | jasta | as of that writing theyre already way passed beta1. onto beta 4 now. |
| 15:00.40 | jasta | regardless, this is excellent news. httpclient 4.x fixes the 3.x bug that prevents you from interrupting a blocking connect(). |
| 15:00.43 | yakischloba | morning |
| 15:00.57 | jasta | so the strategy i discussed earlier will work perfectly with httpclient 4.x and java >= 1.4 |
| 15:01.05 | jasta | so, android's covered. |
| 15:01.41 | jasta | i'm gonna put together an android-specific example to confirm that the version provided in M5 does in fact use the correct socket shutdown technique. |
| 15:02.00 | jasta | is excited. |
| 15:02.11 | jasta | i will need to rewrite a fair bit of my existing android code if i can prove that this works though :) |
| 15:14.53 | *** join/#android ozarka (n=elineber@12.106.220.2) |
| 15:19.49 | *** join/#android matt_c (n=mcroydon@gozur.sunflowerbroadband.com) |
| 15:21.41 | *** join/#android matt_c (n=mcroydon@gozur.sunflowerbroadband.com) |
| 15:28.57 | *** join/#android davidw (n=davidw@213.47.186.146) |
| 15:38.47 | *** join/#android AhtiK (n=ahti@88-196-185-130-dsl.rgu.estpak.ee) |
| 15:49.00 | jasta | ugh, my co-workers are so melodramatic |
| 15:51.53 | jasta | i guess i just don't get the workaholic thing. if you like your job so much that you feel like you need to be there for 10-14 hours a day, you've really screwed up somewhere. |
| 15:52.10 | jasta | i love how they try to blame it on workload, and the company's performance, bla bla. it's obviously a personal issue. |
| 15:56.27 | jasta | romainguy_: complaining about this made me remember our conversation yesterday. hopefully, i can restate another way: would you be interested in a user-contributed example demonstrating a synchronized download thread cancellation? |
| 15:57.06 | jasta | it seems like a good "best practice" example. |
| 15:57.44 | *** join/#android AttractiveApe (n=phil@office.gossamer-threads.com) |
| 15:58.35 | jasta | and, in some ways it is particular to Android as it requires HttpClient 4.x to implement this strategy effectively. Not many folks happen to be using HttpClient 4.x, however. |
| 15:59.32 | jasta | other third party libraries likely work as well, provided that they can be built to take advantage of new features introduced in Java 1.4. |
| 15:59.50 | jasta | but as it is, HttpClient 3.x cannot, and the URL#openStream approach cannot. |
| 16:00.56 | *** join/#android NiZoX (n=none@2a01:e35:8a13:a2b0:21c:c0ff:fe25:ff68) |
| 16:01.13 | *** join/#android Dralspire (n=dralspir@56-196.126-70.tampabay.res.rr.com) |
| 16:01.35 | muthu | jasta: are you not working all the time ;) |
| 16:04.55 | zhobbs_ | This seems like it'd be way too technically challenging for the timeframe they're talking about here: http://www.engadget.com/2008/07/25/analyst-says-android-and-symbian-to-merge-nokia-and-google-to-g/ |
| 16:05.12 | muthu | its a long process |
| 16:06.33 | zhobbs_ | yeah, I think it's kinda stupid to think that they can just easily merge in a few months... |
| 16:08.23 | *** join/#android yakischloba (n=jake@rnkfoods.com) |
| 16:11.00 | *** join/#android soulreaper (n=soul@78.42.26.87) |
| 16:14.44 | yakischloba | jasta: i just rode by the block party being setup. you going tonight? |
| 16:19.59 | jasta | no, fucking lame |
| 16:20.20 | yakischloba | why? |
| 16:20.23 | jasta | my gf's grandpa is sick, so suddenly we have to go to oregon to visit |
| 16:20.36 | yakischloba | oh man that blows. you've been talking about this for a month or more :( |
| 16:20.49 | jasta | its the right thing to do, but what timing? argh. |
| 16:20.53 | jasta | i was pumped about this for months |
| 16:21.15 | jasta | yeah, i'm really disappointed |
| 16:21.24 | jasta | we're leaving tonight after work :\ |
| 16:35.45 | *** join/#android davidw_ (n=davidw@213.47.186.146) |
| 16:41.21 | yakischloba | that sucks. |
| 16:41.28 | yakischloba | Gone all weekend I take it? |
| 16:41.36 | jasta | yup |
| 16:41.38 | jasta | be back sunday night |
| 16:41.44 | yakischloba | :( |
| 16:43.30 | sayers | can I incorporate API's like google's google calendar api ? |
| 16:43.32 | yakischloba | I just got azn breakfast from Uwajimaya. Eggs, chicken and onions scrambled over rice. Hrm. |
| 16:43.39 | sayers | Is there any dalvek restrictions on that stuff |
| 16:44.25 | zhobbs_ | sayers: I've used a handful of different jars without a problem |
| 16:44.30 | jasta | sayers: google calendar is a web api. that is, it consists of standard HTTP requests and responses. |
| 16:44.48 | jasta | any 3rd party library to implement it in Java will just do that. Nothing magical there. |
| 16:45.03 | sayers | Alright, good just checking before I wrote this app |
| 16:48.44 | yakischloba | you sure write a lot of apps |
| 16:48.59 | yakischloba | you're either really fast or they don't do much |
| 16:49.19 | jasta | or work |
| 16:49.20 | jasta | ;) |
| 16:49.30 | yakischloba | no thats mine |
| 16:49.31 | yakischloba | heh |
| 16:50.47 | sayers | No all my apps work, and they are short. This next one will be a bit larger seeing as it will work with google calendar. |
| 16:50.58 | zhobbs_ | gotta start somewhere |
| 16:51.24 | yakischloba | i prefer to jump in way over my head |
| 16:51.28 | *** part/#android mari (n=mari@offb-d9be237c.pool.mediaWays.net) |
| 16:51.40 | jasta | prefers to read and study before he codes |
| 16:51.44 | jasta | but meh, that's just me :) |
| 16:57.08 | *** join/#android pandora-- (n=pandora-@66.238.50.126.ptr.us.xo.net) |
| 16:59.45 | yakischloba | i learn best just by digging in and experimenting. i can only gain so much comprehension by reading docs by themselves. |
| 17:01.09 | jasta | i have been bitten by C far too many times trying it that way ;) |
| 17:01.44 | jasta | it also taught me that trial and error is a generally failing strategy for software engineering. |
| 17:04.43 | zhobbs_ | I keep typing until it works...and then bitch cause it's so hard to maintain |
| 17:05.15 | zhobbs_ | actually, I used to work with a lot of people I thought just type and typed until it seemed to work |
| 17:05.21 | zhobbs_ | but, that's the web world |
| 17:05.56 | jasta | honestly, that's been most of my professional experience to date. |
| 17:06.03 | jasta | maybe i've just always had bad jobs :\ |
| 17:06.21 | yakischloba | i wouldnt necessarily call what I do trial and error (not that I'm advocating it.) I figure out what i want to do, read some docs, write some code, and then test it to make sure that I understood it correctly. This doesn't necessarily render me transparent to discovering problems before they occur. |
| 17:06.24 | jasta | i can say with confidence that i have only worked (at a company) with 1 engineer i respected. |
| 17:11.07 | jasta | i wish android layouts would let you specify spacing in addition to padding and margin |
| 17:11.26 | jasta | spacing being the default distance between each widget as its packed. |
| 17:11.44 | jasta | s/default/minimum/g |
| 17:12.12 | jasta | i really do not understand why we don't ban that bot |
| 17:12.20 | yakischloba | ;) |
| 17:13.36 | *** join/#android romainguy__ (n=gfx@72.14.224.1) |
| 17:32.08 | *** join/#android SanMehat (n=san@nat/google/x-965a1627e5d84a41) |
| 17:34.29 | *** join/#android borism (n=boris@195-50-197-160-dsl.krw.estpak.ee) |
| 17:37.17 | jasta | dangit, my car is such a piece of crap |
| 17:38.13 | muthu | jasta: the tab activity does not follow the activity lifecycle, right? |
| 17:38.30 | jasta | the activity that hosts the tabhost does. |
| 17:38.56 | muthu | right |
| 17:39.01 | jasta | the other activities which represent the various panels accessible by tabs do not. they are only used for their view hierarchy. |
| 17:39.22 | muthu | yeah, the create, resume etc., are called always |
| 17:39.45 | jasta | there is nothing special about the activity that hosts the tabs. |
| 17:39.52 | jasta | its life cycle is the same as any other app |
| 17:40.02 | jasta | any other activity* |
| 17:40.43 | muthu | yup |
| 17:41.04 | muthu | does the iphone support tabs? |
| 17:41.37 | jasta | of course, many iphone apps use them. |
| 17:41.40 | jasta | for example, the music player |
| 17:41.52 | muthu | hmm, ok |
| 17:42.13 | muthu | donno why people say tabs are not really mobile user friendly |
| 17:42.31 | jasta | because they are thinking of the manifestation of tabs in poorly designed desktop applications. |
| 17:42.57 | zhobbs_ | yeah, I think tabs work well for tunewiki |
| 17:43.33 | zhobbs_ | even though I wish they were a little more powerful |
| 17:43.39 | muthu | right |
| 17:43.45 | muthu | lot of them use tabs |
| 17:44.19 | zhobbs_ | I need TabHost.setCurrentTab(int tab, Bundle extras) |
| 17:44.38 | muthu | yeah |
| 17:44.53 | zhobbs_ | or maybe even, setCurrentTab(int tab, Intent i) |
| 17:45.37 | muthu | there's a lot that can be done |
| 17:46.19 | jasta | what frustrates me is that you basically have to slag off the entire activity manager if you want to implement your entire application within a tabhost |
| 17:46.41 | jasta | (like the iphone music player) |
| 17:47.37 | muthu | looks like its neglected |
| 17:47.53 | zhobbs_ | so TabHost won't destroy activities that aren't being shown (if it needs to) |
| 17:47.58 | zhobbs_ | ? |
| 17:48.15 | jasta | zhobbs_: the host doesn't actually even spawn activities when you switch tabs that are defined by activities. |
| 17:48.30 | jasta | all it does is fire onCreate(), then collect the View hierarchy and attach it to the tabhost. |
| 17:49.15 | jasta | i dont think onDestroy is ever even called, even when the host is destroyed. |
| 17:49.23 | jasta | i could be wrong about that. |
| 17:49.24 | muthu | jasta: how did you handle the tabactivity lifecycle? |
| 17:49.43 | jasta | i didn't have much reason to. all my app ever needed to do was catch ondestroy and disconnect from services and tidy up threads |
| 17:50.14 | jasta | but i arranged it so the hosting activity did everything. |
| 17:50.27 | muthu | ok |
| 17:50.28 | zhobbs_ | jasta: yeah I know and they just keep adding the views to the framelayout, just seems like it'd be nice to remove the views from the framelayout to save resources, or maybe it doesn't matter |
| 17:57.11 | yakischloba | So will my UI state persist if my activity has onPause() then onResume() called? |
| 17:58.16 | yakischloba | (I don't need to, for instance, refill data in TextViews when that happens?) |
| 18:00.57 | yakischloba | I guess I mean to say that the 'icicle' is only used in cases where the activity is actually terminated? |
| 18:01.50 | jasta | yakischloba: the strategy as i see it for recovering an application state is to save state in onFreeze() and recall it in onCreate() |
| 18:01.59 | jasta | you will be given the bundle you save in onFreeze back during onCreate(). |
| 18:02.37 | yakischloba | jasta: Ok thats what I thought. I just never saw it explicitly stated that everything was peachy as long as the activity wasn't terminated. |
| 18:03.08 | jasta | that said, you may want to save changes in onPause or onStop as well. |
| 18:03.14 | jasta | depending on your application logic |
| 18:03.26 | yakischloba | so I didn't know if I had to restore from onFreeze() if I just went onFreeze() -> onPause() -> onResume() |
| 18:03.33 | jasta | for example, if a user is editing an e-mail, and they navigate away, onStop will be fired, and the user probably expects the e-mail to be saved as a draft. |
| 18:03.41 | yakischloba | Yeah |
| 18:03.58 | jasta | say they turn off the phone, days later return, your app should check if drafts exist that haven't been prompted before, and offer to open them as new. |
| 18:04.01 | jasta | so the user can send |
| 18:04.05 | jasta | if they say no, then you just happily leave them in draft |
| 18:04.17 | jasta | but that isn't necessarily the same as the onFreeze/onCreate contract |
| 18:04.27 | yakischloba | yeah I understand |
| 18:04.36 | jasta | onFree/onCreate is more for maintaining state that would not persist indefinitely, only through the resource reallocation phase. |
| 18:05.02 | jasta | For example, the HttpDownloader app I wrote for you. That app should freeze the last source and destination urls and fill them in onCreate() if supplied. |
| 18:05.43 | jasta | i may be wrong about this, the documentation is pretty clear but there aren't a lot of examples to study so... |
| 18:06.07 | yakischloba | My case is a small amount of data that is not really appropriate to persist in any other way until the user is done entering it. |
| 18:06.49 | yakischloba | morrildl's i/o talk helped a bit |
| 18:07.11 | jasta | the real advantage to saving in the onFreeze/onCreate contract is that it's simple :) |
| 18:07.30 | jasta | the persistent approach is tougher. |
| 18:08.51 | yakischloba | yeah. though I'm ending up with pretty verbose code for those methods, probably just due to my lack of familiarity with Java such that I can't figure out a more efficient way yet ;) |
| 18:09.10 | *** join/#android jasonchen (n=chatzill@nat/google/x-0ad9656844e1556c) |
| 18:10.03 | jasta | jasonchen: do you know what the story is on the HttpClient bundled with Android? |
| 18:10.30 | jasta | It seems both 3.x and 4.x beta 1 are included? Is Google planning to keep the 4.x tree in there even if it stays in beta? |
| 18:11.03 | jasta | I'd like to start writing applications to depend on 4.x as it fixes a critical issue for me regarding socket shutdown and threading. |
| 18:11.20 | f00f- | dont use old stuff |
| 18:11.21 | f00f- | 4.x is good |
| 18:11.37 | muthu | yeah why not use the latest? |
| 18:11.47 | jasta | well, because it's beta and the API is changing. |
| 18:11.54 | f00f- | no it's not |
| 18:11.58 | f00f- | check apache httpcomponents |
| 18:12.04 | f00f- | how much have they changed |
| 18:12.05 | f00f- | they're nearing rc |
| 18:12.24 | jasta | i just read a comment from Oleg complaining that now that Android uses httpclient they will have extra pressure to stabilize the API |
| 18:12.29 | jasta | where previously that was not an issue |
| 18:12.36 | jasta | httpclient4* |
| 18:13.11 | jasta | still, i am not going to just blindly assume that google will launch with a beta or rc version of httpclient4. i'd rather have clarification from their team. |
| 18:22.02 | jasonchen | jasta: i don't know off-hand. let me look into that and get back to you here |
| 18:22.34 | yakischloba | Whats the best way to check the Bundle being passed into onCreate() to see if it is being called for the first time or if it contains state information?.. |
| 18:23.03 | jasta | yakischloba: it's yours to do with it as you please. you can layer whatever logic you want. |
| 18:23.17 | zhobbs_ | well, if it's null it's first time probably |
| 18:23.21 | yakischloba | jasta: So there is nothing built-in to indicate that? |
| 18:23.26 | yakischloba | zhobbs: Ok |
| 18:23.30 | jasta | yakischloba: no, would that be helpful? :) |
| 18:23.57 | yakischloba | So it passes null on the first time? Not some generic Bundle without any data? |
| 18:24.12 | zhobbs_ | not a bundle, but just null |
| 18:24.16 | yakischloba | ok |
| 18:24.26 | yakischloba | thats good enough for me. |
| 18:29.45 | yakischloba | jasta: is zhobbs' answer somehow different than what you were thinking of? |
| 18:30.02 | yakischloba | I guess I phrased the question a little weird |
| 18:30.35 | jasta | yakischloba: . |
| 18:30.37 | jasta | err no* |
| 18:31.00 | yakischloba | ok |
| 18:37.40 | *** join/#android anno^da_ (n=anno^da@p5B07E1C9.dip.t-dialin.net) |
| 18:50.39 | *** join/#android yeonhoo (n=yeonhoo@189.58.67.228.adsl.gvt.net.br) |
| 19:04.56 | *** join/#android jota- (n=jota@190.6.0.180) |
| 19:15.37 | *** join/#android kennethr (n=kennethr@nat/sgi/x-fb0b4b0f8dc6ed07) |
| 19:15.47 | kennethr | yes |
| 19:15.55 | kennethr | I have seen & used rotary-dial phone |
| 19:16.29 | kennethr | When will ADC Phase II winners be announced and how? |
| 19:19.08 | zhobbs_ | kennethr: in august sometime |
| 19:19.45 | *** join/#android The_PHP_Jedi (n=ThePHPJe@unaffiliated/thephpjedi/x-000002) |
| 19:19.58 | kennethr | http://code.google.com/android/adc_faq.html#deadline I mean the $275K & $100K awards. |
| 19:20.12 | kennethr | zhobbs_: is this page out of date? |
| 19:21.13 | zhobbs_ | kennethr: yeah, out of date |
| 19:21.46 | kennethr | is there a new date(day/week) or just "Sometime in august?" |
| 19:24.15 | zhobbs_ | the deadline for submission is aug 5 |
| 19:25.31 | kennethr | zhobbs_: is the purpose for the delay documented somewhere? |
| 19:25.47 | zhobbs_ | nothing about round 2 of ADC I is documented anywhere... |
| 19:26.01 | kennethr | where did you get your information, then? |
| 19:27.03 | zhobbs_ | cause I was in the top 50 |
| 19:27.24 | kennethr | was or am? |
| 19:27.40 | zhobbs_ | am |
| 19:27.44 | zhobbs_ | or was, same thing |
| 19:28.00 | kennethr | so it was in e-mail from google ADC people? |
| 19:29.04 | zhobbs_ | they email us instructions and such |
| 19:29.38 | kennethr | they haven't indicated when the winners will be chosen? |
| 19:30.14 | *** part/#android muthu (n=sushmu@59.92.93.28) |
| 19:30.33 | zhobbs_ | it won't take long, they only have to judge 50 entries |
| 19:31.10 | kennethr | so that's a no? who is judging the entries? |
| 19:31.26 | zhobbs_ | dunno |
| 19:31.36 | zhobbs_ | there's a list of the round 1 judges out there |
| 19:32.59 | zhobbs_ | There's some background info on round 1 at google's android blog: http://android-developers.blogspot.com/ |
| 19:42.10 | jasta | i wish the finally block shared scoping with the try block in Java :\ |
| 19:42.20 | jasta | and the catch blocks, too |
| 19:50.10 | zhobbs_ | it'd be nice to have scope carry into objects defined inline |
| 19:51.15 | zhobbs_ | public void doSearch(String s) { Thread t = new Thread() { public void run() { String searchingfor = s; ... ... } }; } etc |
| 19:51.42 | romainguy__ | zhobbs: you can |
| 19:51.46 | f00f- | global vars |
| 19:51.49 | romainguy__ | no |
| 19:51.53 | romainguy__ | just declare the variable final |
| 19:51.55 | f00f- | My.this.bleh also |
| 19:51.58 | romainguy__ | and it will be visible from anonymous classes |
| 19:52.33 | f00f- | everything should be final almost |
| 19:52.39 | f00f- | for speed |
| 19:52.41 | f00f- | ? |
| 19:53.03 | romainguy__ | doesn't matter with local variables |
| 20:02.02 | yakischloba | I'm using an AlertDialog and my single button is aligned to the left of the dialog box. I don't see a way to change its position, but I see a screenshot that has in centered in the dialog. What am I missing? |
| 20:02.08 | AttractiveApe | jasta: get anything for sysadmin appreciation day? |
| 20:02.36 | jasta | well, everyone got a 20% bonus check for the last 6 months of work |
| 20:02.39 | jasta | so that's pretty sweet ;P |
| 20:02.54 | AttractiveApe | ... |
| 20:03.02 | yakischloba | disgusting imo |
| 20:03.10 | yakischloba | should take me out for drinks |
| 20:05.50 | jasta | f00f-: what is the performance implication of final? |
| 20:06.22 | f00f- | it's faster for objects if you dont extend them and let the compiler/vm know |
| 20:06.28 | jasta | the only thing that i can see is that it gets to optimize away dynamic storage duration if it wants. |
| 20:06.45 | jasta | which isn't something the runtime would even want to do very often |
| 20:06.56 | jasta | f00f-: right, but i mean why? |
| 20:07.32 | jasta | the storage duration check makes sense to me, especially since romain just confirmed that it doesn't matter for lcoal variables, since their storage duration would be unaffected. |
| 20:08.00 | jasta | but i can't think of anything else that you could do with a final variable for optimization sake? |
| 20:08.20 | jasta | it seems to me it's mostly a language construct to enforce constants |
| 20:08.30 | f00f- | it must save something to disable inheriatnce/overriding for finals? |
| 20:08.36 | f00f- | yes, perhaps |
| 20:08.38 | jasta | like? |
| 20:08.46 | mickrobk_ | with methods at the least it allows u to skip virtual method invocation |
| 20:08.47 | *** join/#android cybereagle (n=cybereag@unaffiliated/cybereagle) |
| 20:08.50 | f00f- | something |
| 20:09.20 | *** join/#android borism (n=boris@195-50-204-124-dsl.krw.estpak.ee) |
| 20:09.25 | jasta | mickrobk_: yes, that makes sense. |
| 20:10.16 | romainguy__ | final fields are faster to access |
| 20:10.29 | romainguy__ | f00f-: we are talking about two different finals here |
| 20:10.41 | romainguy__ | I was talking about writing: doSearchString(final String s) |
| 20:10.48 | romainguy__ | vs your final class MyClass |
| 20:10.49 | jasta | romainguy__: i can accept that, but i can't see why? |
| 20:10.58 | jasta | i'm curious to learn |
| 20:11.13 | f00f- | oh right.. yeah i meant final classes/methods |
| 20:11.25 | jasta | f00f-: i was talking about final variables ;) |
| 20:11.42 | jasta | specifically member variables. |
| 20:11.47 | romainguy__ | I don't remember the specifics unfortunately, you would have to ask some VM :) |
| 20:12.01 | romainguy__ | "VM guy" |
| 20:12.22 | jasta | i'll see if i can google around |
| 20:12.44 | *** part/#android kennethr (n=kennethr@nat/sgi/x-fb0b4b0f8dc6ed07) |
| 20:13.06 | jasta | btw, i love the developer works articles at ibm.com on java |
| 20:13.21 | jasta | i always seem to randomly hit on them when i'm looking for answers like this :) |
| 20:13.25 | romainguy__ | I wouldn't be surprised if with HotSpot a final getter method would be as fast as accessing a field directly |
| 20:14.04 | jasta | romainguy__: yeah i guess that's what i was hinting at: what is it that a non-final member is required to do that final wouldn't be? seems like maybe a good opt potential but i don't really know what i'm talking about. |
| 20:14.33 | romainguy__ | the compiler and the VM know that the value will not change |
| 20:14.41 | romainguy__ | so they can probably do things like inlining |
| 20:14.55 | romainguy__ | or use some faster way to get access to the value |
| 20:15.06 | romainguy__ | but just like you, I don't know what I'm talking about here ;-) |
| 20:15.26 | jasta | yeah, that's true, but inlining something other than a literal doesn't seem to make any sense from a performance stand point |
| 20:15.32 | jasta | anyway, i'm reading ;) |
| 20:19.43 | jasta | hehe |
| 20:19.46 | jasta | "final is vastly overused for classes and methods (generally because developers mistakenly believe it will enhance performance)" |
| 20:21.21 | yakischloba | lol |
| 20:21.41 | f00f- | uh oh |
| 20:21.43 | f00f- | that's em |
| 20:21.45 | f00f- | Me |
| 20:22.15 | jasta | http://www.ibm.com/developerworks/java/library/j-jtp1029.html |
| 20:27.05 | *** join/#android anno^da_ (n=anno^da@p5B07E1C9.dip.t-dialin.net) |
| 20:27.31 | romainguy__ | jasta: note that the article is from 2002 though |
| 20:27.42 | romainguy__ | who knows that HotSpot for instance did later |
| 20:27.47 | jasta | right, i've eben looking for a more recent article as well |
| 20:27.49 | jasta | and i can't find one |
| 20:28.20 | jasta | which is slowly convincing me that perhaps final is as i thought it to be, a language construct to write more maintainable code :) |
| 20:28.52 | zhobbs_ | romainguy__: thanks, nice to know that final trick for passing to inline classes |
| 20:29.12 | romainguy__ | zhobbs_: that's also how you can "return" values from anonymous classes |
| 20:29.16 | romainguy__ | you create a final array of 1 |
| 20:29.24 | romainguy__ | for instance final int[] result = new int[1] |
| 20:29.49 | jasta | eww ;P |
| 20:31.36 | romainguy__ | ok after checking with the people who know, Dalvik doesn't optimize anything when it's final |
| 20:32.37 | yakischloba | I have an EditText who's contents needs to end up as a Float. Currently I'm just parsing the contents as a String into Float and catching the exception if it cannot be parsed. Is this an appropriate way of 'validating' the contents or is there something better? |
| 20:33.03 | jasta | yakischloba: yes, but a better way might be to prevent the user from entering invalid characters in the first place. |
| 20:33.19 | yakischloba | jasta: Gotcha. Is this a facility of EditText? |
| 20:33.36 | jasta | i'm not sure. if not directly, subclassing may be a possibility. romain? |
| 20:34.46 | mickrobk_ | yakischloba: look through the api demos for edittext, i thought i saw a filter to that effect, i could definitely be wrong |
| 20:34.56 | zhobbs_ | really, that should be a function of the virtual keyboard that should popup when you focus an EditText |
| 20:37.15 | jasta | what virtual keyboard? |
| 20:37.29 | f00f- | a la iphone |
| 20:37.31 | f00f- | he means :P |
| 20:37.54 | jasta | romain said "what virtual keyboard" once too, which made me speculate wildly that android devices would have a physical keyboard |
| 20:38.46 | mickrobk_ | which would be lame, id rather have the phone be thin... :( |
| 20:38.55 | f00f- | aye |
| 20:39.02 | romainguy__ | jasta: that was just a reference to the fact that M5 has not virtual keyboard |
| 20:39.14 | romainguy__ | s/not/no |
| 20:39.42 | jasta | i know, i was just fondly remembering the good old days |
| 20:40.09 | jasta | romainguy__: do you know if there is any reason to call up to the super handleMessage in Handler? |
| 20:40.11 | yakischloba | i think i may prefer having a smaller screen with hardware keyboard |
| 20:40.20 | jasta | i saw a few places do that |
| 20:40.42 | jasta | yakischloba: i prefer that as well. i tend to get my screen all slimy otherwise :) |
| 20:40.46 | romainguy__ | handleMessage is empty in Handle |
| 20:40.54 | romainguy__ | but it's just a good practice |
| 20:41.10 | *** join/#android tethridge (n=tale@207.235.54.1) |
| 20:42.46 | yakischloba | granted I haven't owned a phone with a virtual kb, i have used other peoples and didn't care much for it. tactile response is important to me |
| 20:44.43 | f00f- | right |
| 20:44.45 | mickrobk_ | tactile feedback is nice, but i think if a virtual keyboard was done right it could be really good in terms of how well it predicted what u meant to type |
| 20:44.51 | f00f- | but it better succeed in the marketplace |
| 20:45.06 | f00f- | that is one of my worries |
| 20:45.08 | mickrobk_ | i mean qwerty was designed so letters commonly hit in a row are far apart |
| 20:45.24 | mickrobk_ | i think id have to be alot less accurate with a good virtual keyboard |
| 20:45.29 | f00f- | qwerty was designed by the us military, so who knows what angle they have on it |
| 20:45.39 | mickrobk_ | but noone has managed to get it right |
| 20:45.56 | f00f- | well remember we have predictive text also |
| 20:45.57 | jasta | qwerty was designed to make it easier for video surveillance to pick up what password you typed. |
| 20:45.59 | f00f- | that can help pinpoint |
| 20:46.01 | f00f- | the finger touch area |
| 20:46.04 | f00f- | some heuristics there |
| 20:46.46 | mickrobk_ | qwerty was desgined by a machinist in the 1860's |
| 20:47.16 | mickrobk_ | no wait |
| 20:47.22 | mickrobk_ | qwerty was desgined by a machinist in the 1860's |
| 20:47.23 | *** join/#android shoragan (n=shoragan@sicherheitsschwankung.de) |
| 20:47.29 | f00f- | no wait |
| 20:47.51 | yakischloba | BTW the proper method to use looks like setFilters() |
| 20:47.51 | mickrobk_ | the patent was in 1878 |
| 20:48.41 | mickrobk_ | and it was to provide a mechanical seperation beteween letters typed in sequence in order to reduce the likelyhoood of jams |
| 20:48.55 | f00f- | mmmm |
| 20:48.55 | f00f- | ooh |
| 20:48.58 | f00f- | yeah you're right |
| 20:49.02 | f00f- | altho i still get jams on typwriters |
| 20:49.23 | mickrobk_ | i've never used a typewriter :) i've seen them though |
| 20:49.23 | tethridge | any news in the android world? |
| 20:49.44 | tethridge | new sdk or demo of the newer sdks on youtube maybe? |
| 20:50.10 | f00f- | nah bro |
| 20:55.57 | zhobbs_ | saw the new sdk on bittorrent site the other day.... |
| 20:56.12 | tethridge | that's sad |
| 20:56.14 | zhobbs_ | haha, j/k...did check though |
| 20:57.08 | tethridge | it does amaze me how google doesn't care that it's getting bad press with leaving us out to dry |
| 20:57.43 | tethridge | we don't even get a simple, we know you are expecting something, we'll have it to you soon or nothing |
| 21:01.42 | mickrobk_ | tethridge: http://jbq.livejournal.com/151129.html |
| 21:01.59 | yakischloba | Does anyone have an example of an InputFilter? |
| 21:11.43 | yakischloba | I'm not turning anything up :( |
| 21:15.29 | *** join/#android bdjnk (n=bdjnk@ool-4572ad23.dyn.optonline.net) |
| 21:37.56 | *** join/#android darkbalder (i=c0bc3003@gateway/web/ajax/mibbit.com/x-c7297f9b6ff1ce26) |
| 21:39.32 | *** join/#android eton_ (n=eton@ppp-58-8-4-129.revip2.asianet.co.th) |
| 21:45.02 | jasta | hmm. |
| 21:45.04 | jasta | praises an eyebrow |
| 21:45.15 | jasta | HttpClient 4 in Android seems quite broken |
| 21:45.27 | jasta | hangs for a long time initializing the SSLFactory class, even when you don't require it. |
| 21:53.41 | *** join/#android lindever__ (n=eton@ppp-58-8-3-31.revip2.asianet.co.th) |
| 22:04.44 | *** part/#android ozarka (n=elineber@12.106.220.2) |
| 22:07.03 | *** join/#android eton (n=eton@ppp-58-8-2-174.revip2.asianet.co.th) |
| 22:17.43 | *** join/#android eton_ (n=eton@ppp-58-8-1-252.revip2.asianet.co.th) |
| 22:31.04 | *** join/#android lindever__ (n=eton@ppp-58-8-1-252.revip2.asianet.co.th) |
| 22:35.55 | *** join/#android krau (n=cktakaha@200.184.118.132) |
| 22:36.00 | *** join/#android dims (n=dims@c-66-31-154-33.hsd1.ma.comcast.net) |
| 22:38.11 | *** join/#android lindever__ (n=eton@ppp-58-8-1-216.revip2.asianet.co.th) |
| 22:45.47 | *** join/#android eton_ (n=eton@ppp-58-8-3-38.revip2.asianet.co.th) |
| 22:59.23 | *** join/#android sayers (n=sayers@c-76-20-182-119.hsd1.mi.comcast.net) |
| 22:59.47 | *** join/#android eton (n=eton@ppp-58-8-3-138.revip2.asianet.co.th) |
| 23:22.26 | *** join/#android AstainHellbring (n=Administ@unaffiliated/astainhellbring) |
| 23:34.16 | heat | bleh |
| 23:34.38 | *** join/#android chaddy (n=chaddy@tuxhacker/chaddy) |
| 23:35.22 | chaddy | hello all |
| 23:41.12 | *** join/#android duey (n=Nick@203.96.223.40) |
| 23:52.33 | *** join/#android aculich (n=aculich@c-76-24-31-156.hsd1.ma.comcast.net) |