**** BEGIN LOGGING AT Tue Nov 25 02:59:57 2008
Nov 25 03:17:47 <Ro9u3oR> anyone have android nstalled on a nokia n800
Nov 25 03:18:04 <spikebike> not I
Nov 25 03:18:13 <spikebike> I do have a g1 and a n800 though
Nov 25 03:18:18 <spikebike> A friend tried and failed
Nov 25 03:19:07 <Ro9u3oR> u have a usb or blueooth keyboard?
Nov 25 03:20:33 <spikebike> bluetooth
Nov 25 03:21:19 <Ro9u3oR> for some reason i can pair my bt w/ n800
Nov 25 03:21:34 <Ro9u3oR> *cant
Nov 25 03:21:58 <spikebike> under android or maemo?
Nov 25 03:22:24 <Ro9u3oR> maemo
Nov 25 03:22:39 <spikebike> never had problems
Nov 25 03:22:49 <spikebike> magic keypress to put it in pairing mode on the keyboard
Nov 25 03:22:55 <spikebike> then tell the n800 tos can
Nov 25 03:22:57 <spikebike> os2008?
Nov 25 03:24:14 <Ro9u3oR> os im not sure of . will it only wrk with 08
Nov 25 03:28:13 <spikebike> I had the keyboard well before os2008
Nov 25 05:42:23 <user__> spike, wa model bt keyboard u have
Nov 25 06:46:25 <ismarc> anyone here got an exchange account on an Exchange 2007 server?
Nov 25 07:17:01 <BHSPitMonkey> maybe.
Nov 25 07:17:09 <BHSPitMonkey> ismarc, who's asking?
Nov 25 09:02:41 <mib_41e190dx> has any one triedn running the OpenCORE test framework (the one mentioned in "pvplayer_engine_unit_test_guide.pdf") after building the entire Android source ?
Nov 25 22:19:58 <famast> ok so I compiled the android source code, but when I launch the emulator from eclipse with the -system and -kernel tags, all my buttons and keyboard portions of the emulator are missing! Only the screen is showing
Nov 25 22:20:34 <romainguy__> are you using a skin?
Nov 25 22:27:53 <famast> no skin
Nov 25 22:29:42 <famast> romainguy__: under "additional emulator command line options" I put -system /home/amast/mydroid/out/target/product/generic/  -kernel /home/amast/mydroid/prebuilt/android-arm/kernel/kernel-qemu
Nov 25 22:30:35 <famast> if I remove both -system and -kernel, it works fine. If I call emulator with those args from the terminal it loads fine (with the exception of an audio output failed warning)
Nov 25 22:31:08 <lresende> is there native support for jsonrpc in android ? and does anyone know about a android app example that uses json-rpc ?
Nov 25 22:31:14 <duncanfoo> hey... I have an issue. At some point I would like to prevent the user from exiting from the current activity until a network operation is complete
Nov 25 22:31:23 <duncanfoo> other than blocking in onStop is there a way to do that?
Nov 25 22:31:48 <famast> duncanfoo: that might be a little frustrating for the user don't you think? What if they get a phone call?
Nov 25 22:31:50 <duncanfoo> jasta, I remember you discussing at one point options for delayed processing in onCreate
Nov 25 22:33:02 <famast> why not run the network operation in a service so if you exit the activity your service continues to run
Nov 25 22:33:14 <duncanfoo> well, its supposed to be a simple demo
Nov 25 22:33:18 <duncanfoo> so I don't want to use a service
Nov 25 22:33:44 <duncanfoo> the problem at present, however, is the activity launches an async network message
Nov 25 22:33:48 <duncanfoo> and wants to process the reply
Nov 25 22:33:54 <duncanfoo> however, if the activity has gone
Nov 25 22:34:05 <duncanfoo> due to orientation change, or pressing back (and thus finish())
Nov 25 22:34:05 <famast> well if you delay your onStop through whatever means (sleep?) I think the OS will just say the activity is not responding
Nov 25 22:34:24 <duncanfoo> yes, that was why I was looking for a better way. hence my questions :)
Nov 25 22:34:28 <famast> ah
Nov 25 22:35:05 <duncanfoo> in most cases the operation will be very quick
Nov 25 22:35:17 <duncanfoo> however, if there is congestion or whatever, it could take some time
Nov 25 22:35:29 <famast> I'm still thinking service, but I'm curious as to what the pros here have to say
Nov 25 22:35:48 <duncanfoo> in reality this would be an issue for any application
Nov 25 22:35:50 <duncanfoo> there is some data
Nov 25 22:35:56 <duncanfoo> and then there is some UI that manipulates that data
Nov 25 22:36:08 <duncanfoo> if the UI does some async manipulation of that data
Nov 25 22:36:26 <duncanfoo> and the reply wants to update some local cached copy
Nov 25 22:36:33 <duncanfoo> and possibly the actiivty UI state
Nov 25 22:36:41 <duncanfoo> then you'll encounter this issue
Nov 25 22:37:20 <duncanfoo> the simplest solution is not to cache the data, but then the performance could be bad
Nov 25 22:38:30 <duncanfoo> btw, a call does not destory the activity
Nov 25 22:38:32 <duncanfoo> it stops it
Nov 25 22:38:34 <duncanfoo> and that isn't a problem :)
Nov 25 22:38:43 <duncanfoo> I want to stop the activity from being destroyed for a short amount of time
Nov 25 22:40:51 <famast> ok what about this
Nov 25 22:40:57 <famast> if you hit back are you still in your app?
Nov 25 22:41:18 <famast> maybe do the processing in a seperate thread?
Nov 25 22:41:53 <duncanfoo> the async reply occurs in a separate thread anyway
Nov 25 22:41:59 <duncanfoo> so what I do currently is something like:
Nov 25 22:42:35 <duncanfoo> onClickHandler() { // ... send network command. replyHandler = new Runnable() { // update data state, update UI } }
Nov 25 22:42:42 <duncanfoo> ie: the rep;ly handler is an inner class of the activity
Nov 25 22:42:57 <duncanfoo> of course, if teh activity is replaced (because of orientation change for example)
Nov 25 22:43:02 <duncanfoo> then the inner class is now on a destroyed actrivity
Nov 25 23:42:50 <jasta> duncanfoo: ?
Nov 25 23:42:56 <duncanfoo> yo
Nov 25 23:44:42 <jasta> you rang? :)
Nov 25 23:45:22 <duncanfoo> heh, well... not sure if had to deal with something like this :)
Nov 25 23:45:29 <duncanfoo> consider... you have an activity that saves some piece of data in a remote database
Nov 25 23:45:44 <duncanfoo> so teh user presses save
Nov 25 23:45:51 <duncanfoo> that does some network crap
Nov 25 23:46:00 <duncanfoo> async so as not to block the UI
Nov 25 23:46:29 <duncanfoo> in my case, I'm running into a problem because when the reply comes back the user might have destroyed the activity for various reasons
Nov 25 23:46:34 <duncanfoo> (pressed back, changed orientation)
Nov 25 23:47:07 <duncanfoo> I'm debating various solutions, but the simplest seems to me to block the user from leaving the activity...
Nov 25 23:47:34 <duncanfoo> typically it would never take more than 2s
Nov 25 23:48:06 <jasta> sorry, *reading*
Nov 25 23:48:47 <jasta> one strategy i have heard romain advocate is to flag the thread during onStop that it is not to send UI updates.
Nov 25 23:48:57 <jasta> or, to flag your handler to not make them.
Nov 25 23:49:09 <jasta> (i assume youre using a Handler, right?)
Nov 25 23:49:32 <jasta> and no, the worst solution is to prevent the user from leaving.
Nov 25 23:53:02 <duncanfoo> that sucked... computer crashed :(
Nov 25 23:53:44 <jasta> did you get my messages?
Nov 25 23:53:48 <duncanfoo> no
Nov 25 23:54:08 <jasta> [15:49] <jasta> one strategy i have heard romain advocate is to flag the thread  during onStop that it is not to send UI updates.
Nov 25 23:54:11 <jasta> [15:49] <jasta> or, to flag your handler to not make them.
Nov 25 23:54:14 <jasta> [15:49] <jasta> (i assume youre using a Handler, right?)
Nov 25 23:54:17 <jasta> [15:50] <jasta> and no, the worst solution is to prevent the user from leaving.
Nov 25 23:54:36 <duncanfoo> its not really a problem to not update the UI
Nov 25 23:54:51 <jasta> what is the problem then?
Nov 25 23:54:52 <duncanfoo> you can call isFinishing()
Nov 25 23:54:59 <duncanfoo> to find out whether the activity has goen away
Nov 25 23:55:13 <jasta> yes, and i told you how to do that.
Nov 25 23:55:23 <jasta> during onStop, flag the thread that the activity has left
Nov 25 23:55:29 <jasta> during onStart, flag it the opposite
Nov 25 23:55:43 <jasta> keep a static reference to the Thread around so you can do this
Nov 25 23:55:45 <duncanfoo> ok, I have something very similar to that already
Nov 25 23:55:59 <duncanfoo> I'm not 100% convinced its not prone to race conditions
Nov 25 23:56:20 <jasta> that depends entirely how you implement it
Nov 25 23:56:24 <duncanfoo> well, consider
Nov 25 23:56:29 <duncanfoo> onStop() you set the flag in the thread
Nov 25 23:56:31 <duncanfoo> in the thread
Nov 25 23:56:37 <duncanfoo> you do something like:
Nov 25 23:56:54 <duncanfoo> response_callback() { if(_activity == null) { ... queue response ... }
Nov 25 23:57:12 <duncanfoo> in onResume() you reset the _activity
Nov 25 23:57:28 <duncanfoo> however, consdier if response_callback and onStop are called concurently.
Nov 25 23:57:42 <duncanfoo> its possible respones_callback is called first
Nov 25 23:57:44 <duncanfoo> so... it does
Nov 25 23:57:50 <duncanfoo> _handler.post(new RUnnable() { ... } }
Nov 25 23:58:00 <duncanfoo> and when the runnable is called, the activity is gone
Nov 25 23:58:13 <jasta> so synchronize then silly :)
Nov 25 23:58:21 <duncanfoo> that doesn't help
Nov 25 23:58:23 <jasta> or use a volatile
Nov 25 23:58:24 <duncanfoo> it is snced
Nov 25 23:58:40 <duncanfoo> I don't think its possible to solve that particular problem, except to requeue
Nov 25 23:58:45 <jasta> i fail to see the problem.
Nov 25 23:59:30 <jasta> if you can construct a small sample, i'd be happy to analyze it for you.
Nov 25 23:59:38 <duncanfoo> syncrhonzied void response_callback { if(_activity != null) { _handler.post(new Runnable() { _activity.processCallback(); } else { // _queue event }
Nov 25 23:59:49 <dmoffett> Would it be unreasonable to have a service handle the update?  Pass the request to the service which can handle the response and make it available to whom ever needs it.  The service can run until response is received or all activities have exited.
Nov 25 23:59:52 <duncanfoo> void onStop() { _thread.clearactivity(null); }
Nov 25 23:59:55 <duncanfoo> or whatever
Nov 25 23:59:59 <jasta> i didnt mean to necessarily synchronize the method, nor do i know what your "response_callback" is or how it's called.
Nov 26 00:00:13 <duncanfoo> at any rate, that isn't the key issue either ;)
Nov 26 00:00:45 <jasta> duncanfoo: your psuedo code is impossible to follow.  you will need to show me real code or explain it with words.
Nov 26 00:01:28 <duncanfoo> o, consider hte contacts application
Nov 26 00:01:35 <jasta> ok
Nov 26 00:01:36 <duncanfoo> you first view the contact
Nov 26 00:01:38 <duncanfoo> and then edit the contact
Nov 26 00:01:43 <duncanfoo> when you press "save"
Nov 26 00:01:46 <duncanfoo> it saves the contact
Nov 26 00:01:53 <duncanfoo> and goes back to the view contact activity
Nov 26 00:02:16 <duncanfoo> now, if this used some remote store
Nov 26 00:02:24 <duncanfoo> when you press "save" in the edit contact page
Nov 26 00:02:26 <duncanfoo> what can save do?
Nov 26 00:02:41 <duncanfoo> obviously it must send the data to the remote database
Nov 26 00:03:02 <jasta> ok, what is your question then?
Nov 26 00:03:03 <duncanfoo> however, if one isn't careful how this thing is coded all sorts of badness could occur, right?
Nov 26 00:03:11 <jasta> no.
Nov 26 00:03:24 <duncanfoo> ok, so what doe ssave do? :)
Nov 26 00:03:36 <jasta> well, depends on how you mean careful.  must you write correct code to get correct behaviour?  yes.  must you invent unsolvable problems?  no.
Nov 26 00:03:46 <duncanfoo> I don't mean it is unsolvable of course
Nov 26 00:03:52 <duncanfoo> I can think of various ways to solve it, but no simple way
Nov 26 00:04:09 <duncanfoo> for example, lets say you have an API like
Nov 26 00:04:16 <duncanfoo> updateContact(Contact c);
Nov 26 00:04:34 <duncanfoo> ideally what you'd like to do is:
Nov 26 00:04:42 <duncanfoo> public void save() { updateContact(c); finish(); }
Nov 26 00:04:53 <duncanfoo> but you cannot do that directly because updateContact might block for some unknown amount of time
Nov 26 00:04:58 <duncanfoo> so you might think:
Nov 26 00:05:25 <duncanfoo> public void save() { new Thread(new Runnable() { public voide run() { updateContact(c); runOnUiThread(new Runnable() { public void run() { finish(); }}} }
Nov 26 00:05:32 <duncanfoo> (ok, that's pretty unreadable)
Nov 26 00:05:50 <duncanfoo> basically start a thread which does the business, and then finishes() the activity
Nov 26 00:05:56 <duncanfoo> that, however, also is bogus
Nov 26 00:06:01 <romainguy> why?
Nov 26 00:06:17 <duncanfoo> because the activity could be killed for at least two reasons:
Nov 26 00:06:19 <duncanfoo> 1/ the user changes orientation
Nov 26 00:06:22 <duncanfoo> 2/ the user presses back
Nov 26 00:06:26 <romainguy> ok so?
Nov 26 00:06:29 <duncanfoo> well
Nov 26 00:06:35 <duncanfoo> what do you show in the view contact activity now?
Nov 26 00:06:38 <duncanfoo> the old data?
Nov 26 00:06:40 <duncanfoo> the new data?
Nov 26 00:06:43 <duncanfoo> if the new data, what happens if the save failed?
Nov 26 00:07:08 <romainguy> if you are using a ContentProvider you won't have any problem
Nov 26 00:07:16 <romainguy> because the save will trigger an update
Nov 26 00:07:18 <romainguy> even in the new activity
Nov 26 00:07:29 <romainguy> if you're doing your own thing, then it's up to you to handle that
Nov 26 00:07:46 <duncanfoo> yes, well that is the question :) the simpest thing is to stop the user from exiting until the save is done
Nov 26 00:07:55 <romainguy> so
Nov 26 00:07:58 <romainguy> no
Nov 26 00:08:01 <jasta> no, do not od that
Nov 26 00:08:01 <duncanfoo> especially since it will always occur in 5s or so
Nov 26 00:08:11 <romainguy> the simplest thing is to do what Contacts does: save on exit :)
Nov 26 00:08:18 <duncanfoo> err
Nov 26 00:08:24 <duncanfoo> but then... i have the same problem, no?
Nov 26 00:08:33 <duncanfoo> what happens if the save fails?
Nov 26 00:08:37 <joeo> The bottom line is that you're supposed to treat Activities as if they were cheap and transient.  They're not suppose to have a ton of state in them.
Nov 26 00:08:40 <jasta> duncanfoo: i'm not sure what you think is so complicated about this.
Nov 26 00:08:48 <joeo> That's what services and content providers are for
Nov 26 00:08:56 <jasta> the design is simple, and the implementation seems simple
Nov 26 00:09:44 <duncanfoo> I haven't heard a solution yet that is simpe
Nov 26 00:09:57 <jasta> ok, using your contacts analogy
Nov 26 00:10:26 <jasta> maintain a local replica of what you think your server database should be.  the user hits save to return to the original screen, now seeing your guessed successful result, firing off a thread to do the real save
Nov 26 00:10:38 <jasta> if the thread ets an error, update the local replica content provider that something bogus happened and revert the value
Nov 26 00:10:58 <jasta> the UI would automagically detect this through the notification system and would update.
Nov 26 00:11:10 <duncanfoo> ok, I'm not saying that isn't possible, but its hardly simple :)
Nov 26 00:11:12 <jasta> then if you want maybe you throw up a notification or something that says their update failed or something
Nov 26 00:11:18 <jasta> or maybe you use a service to retyr later if you want
Nov 26 00:11:26 <jasta> i find that simple.  maybe i just have more experience than you :)
Nov 26 00:11:58 <duncanfoo> well, experience aside, simple would be to show an activity dialog and avoid all of those problems.
Nov 26 00:12:20 <jasta> you're confusing simple with wrong.
Nov 26 00:12:54 <duncanfoo> ok, regardless, I  really wasn't missing anyting
Nov 26 00:12:59 <duncanfoo> there is no way to do it the simple/wrong way
Nov 26 00:14:00 <jasta> regardless, i would solve your problem with a local content provider either way
Nov 26 00:14:09 <jasta> so the user doesnt have to wait for success to continue using the app or see their changes
Nov 26 00:14:14 <jasta> you should just assume succss if you can
Nov 26 00:14:16 <jasta> and react to failure
Nov 26 00:14:38 <jasta> imagine if gmail made you wait each time you opened an email so it could make sure that the "read" flag was set on the server
Nov 26 00:15:04 <duncanfoo> yes, I'm not debating the "correct" way to build anything
Nov 26 00:15:10 <duncanfoo> I'm supposed to build a simple example
Nov 26 00:15:26 <duncanfoo> and I only have so much time to build it ;)
Nov 26 00:15:32 <duncanfoo> I know what it *should* do
Nov 26 00:15:34 <jasta> well, examples should be correct by nature.
Nov 26 00:15:38 <jasta> otehrwise what good are they?
Nov 26 00:15:44 <duncanfoo> assuming the point of the example
Nov 26 00:16:00 <duncanfoo> the point of this example is not to show how to handle that type of thing
Nov 26 00:16:05 <duncanfoo> and building all sorts of infrastructure around it
Nov 26 00:16:15 <duncanfoo> will only serve to obfuscate the message
Nov 26 00:21:42 <duncanfoo> thanks, helpful as usual :)
Nov 26 00:27:11 <Ro9u3oR> anyone running os 2008 on n800?
Nov 26 00:29:59 <ttuttle> Ro9u3oR: that is totally unrelated to android. perhaps you meant it for #maemo?
Nov 26 00:37:47 <spikebike> oh, rats missed r09
Nov 26 00:37:50 <spikebike> ro9
Nov 26 01:15:45 <jasta> have you guys noticed there is a new android-platform mailing list?
Nov 26 01:16:34 <jbq__> jasta: that is *so* last month ;-)
Nov 26 01:16:57 * jbq__ waits for jasta to discover android-framework, android-porting and android-kernel :)
Nov 26 01:17:41 * jasta heads home
Nov 26 01:17:48 <jasta> i can't wait for the holiday break.  i'm gonna get so much hacking done :)
Nov 26 01:18:11 <jasta> that is, if i don't drive up to whistler and go snowboarding :)
**** ENDING LOGGING AT Wed Nov 26 02:59:57 2008