**** BEGIN LOGGING AT Fri Nov 14 02:59:57 2008 Nov 14 06:22:41 what's android.process.acore? Nov 14 06:23:49 Home + Contacts + other stuff Nov 14 06:25:07 interesting. Home runs really slow for me lately Nov 14 06:25:22 just did a top and it runs at about 40-50% for a couple of seconds just going back from the Browser and a few other apps Nov 14 06:25:26 or when returning from a call Nov 14 06:25:37 sometimes much longer. i've had ANR show up 3 times today Nov 14 06:25:50 known issue? Nov 14 06:26:19 it was probably restarted Nov 14 06:26:33 and if your device is actively busy in the background, there's not much poor Home can do about it Nov 14 06:26:42 Home has a quite expensive startup actually :( Nov 14 06:29:00 hmm, seems to be happening a lot today Nov 14 06:29:03 for some reason Nov 14 06:29:14 i should just quit running the browser. it is absurdly slow Nov 14 06:29:26 it drives me mad that google didn't make a local reader app :\ Nov 14 06:29:47 not enough time Nov 14 06:29:54 ...is it coming? :) Nov 14 06:30:42 no idea Nov 14 06:30:46 hmm Nov 14 14:57:18 hi ... Someone knows a page with a deep(/technical) explanation about how works android package (.apk) installation? ... thanks Nov 14 14:57:49 I don't know the details, but I know that the source code is available. Nov 14 15:29:43 jbq: doesn't get much more detailed than that :) Nov 14 15:46:37 is there an equivalent of runOnUiThread that I can call without the actiivty itself? Nov 14 15:47:03 basically I have some listeners which are implemented by an activity, and I want calls on these listeners to be invoked in the ui thread Nov 14 15:47:17 and I don't want to pass the listener AND the activity Nov 14 15:47:44 what kind of listeners? Nov 14 15:47:50 application specific Nov 14 15:47:59 if they are button/key/etc listeners, they'll be on the ui thread Nov 14 15:48:07 no, they're my application specific listeners Nov 14 15:48:27 ie: interface NetworkMessageArrivedListener { public void arrived(String msg); } Nov 14 15:48:33 and you want to trigger them from another thread, but run them on the ui thread? Nov 14 15:48:39 yes Nov 14 15:48:43 currently, in the activity I do Nov 14 15:48:51 just dispatch them through a handler then Nov 14 15:48:58 public void arrvied(String message) { runOnUiThread(new Runnable() { ... } } Nov 14 15:49:00 handler->Handler Nov 14 15:49:04 but that sucks Nov 14 15:49:23 which handler? Nov 14 15:49:28 one you create Nov 14 15:49:47 in hte object which calls on the listener? Nov 14 15:50:00 create a Handler in your UI thread, then post messages to it, and have it call your listeners in response Nov 14 15:50:17 the Handler will run in the thread where it was created Nov 14 15:50:33 its annoying that I cannot get at the activity handler... Nov 14 15:50:42 since it, after all, has one :) Nov 14 15:55:34 Activity creates the handler in an intiializewd Nov 14 15:55:36 initilaizer Nov 14 15:55:42 and then initializes mUiThread in a constructor Nov 14 15:55:46 actually, in attach Nov 14 15:55:47 duncanfoo: i dont think that you understand how Handler works... Nov 14 15:55:55 possible :) Nov 14 15:56:02 likely even! :D Nov 14 15:56:14 there would be no reason to access the handler that the activity is using unless you intended to screw with internal events generated and handled by the Android system. Nov 14 15:56:33 I want to dispatch runnables in the ui thread :) Nov 14 15:56:41 in other words, there can be many handlers on the same thread. Nov 14 15:57:00 and there will still only be one event loop running on that thread, dispatching to multiple handlers. Nov 14 15:57:06 to what I saw saying beofre... it seems activity is assuming that the thread that constructs the runnable is the ui thread Nov 14 15:57:06 this is intended usage, even. Nov 14 15:57:14 constructs the handler actually Nov 14 15:57:29 what I'm saying is shouldn't attach initialize _handler, not an initializer? Nov 14 15:57:40 it's nothing to do with activity. unless you specify, Handler attaches to the looper of the current thread. Nov 14 15:57:52 I understand that Nov 14 15:58:05 I'm talking about the implemenation of activity Nov 14 15:58:07 looks buggy to me Nov 14 15:58:21 forgive my skepticism, but how so? Nov 14 15:58:27 I just explained Nov 14 15:58:39 can you point me to a particular area of its implementation? Nov 14 15:58:47 final void attach(Context context, ActivityThread aThread, Instrumentation instr, IBinder token calls Nov 14 15:58:53 mUiThread = Thread.currentThread(); Nov 14 15:59:04 but handler is initilaized as: Nov 14 15:59:21 private Thread mUiThread; Nov 14 15:59:23 private final Handler mHandler = new Handler(); Nov 14 15:59:30 handler dispatches to the thread that creates it, correct? Nov 14 15:59:48 so the assumption here is that the thread that calls attach is the thread that constructs the activity Nov 14 16:00:00 well, less important than where it dispatches to is which looper it attaches to, whcih is on the thread that created it. Nov 14 16:00:17 then mUiThread should be set in the constructor Nov 14 16:00:19 not in attach Nov 14 16:00:25 since that is where handler is created Nov 14 16:01:16 i agree that this seems incorrect. Nov 14 16:01:47 especially considering that mUiThread looks like a simple crutch to allow for runOnUiThread. Nov 14 16:01:51 ok, anyway, using a handler for my callbacks works a treat! Nov 14 16:01:54 thanks Nov 14 16:06:05 Does anyone know a good way to simulate network interruptions short of driving to an area that does not have good network connectivity? Don't ask the about the silly things I have tried. I don't want to turn the network off just simulate network fading in and out. Nov 14 16:07:04 dmoffett: stick the device in a fridge / microwave? Nov 14 16:07:27 a foil shield seems to work. 5 layers of heavy-duty aluminum foil did the trick last time I saw it done. lead would probably be better, of course, but it's harder to find and more dangerous. Nov 14 16:07:34 dmoffett: on the emulator, i have been simulating it by simultaneously saying gsm data off and using an iptables rule to drop packets Nov 14 16:08:07 i thought about making a script, but never did :) Nov 14 16:08:47 I once used some big pots for a satellite transceiver Nov 14 16:08:49 that worked ;) Nov 14 16:09:00 not that you want to stand very close to those suckers then they are transmitting Nov 14 16:21:27 Seems that a pressure cooker seems to work well enough. Thanks for the ideas. Nov 14 16:22:10 A script would be much more elegant. :-) Nov 14 16:38:11 we use a box here that has like 10 layers of aluminium foil wrapped around it.. works great :) Nov 14 17:38:27 romainguy: you there? Nov 14 17:39:17 i elected to conveniently use @android:style/MediaButton.{Previous,Pause,Next} to style my media buttons like the other android apps, however i can't figure out how i can toggle MediaButton.Pause/Play. Nov 14 17:40:00 the MediaController appears to just setImageResource(com.android.internal.R...) which i don't have access to. is there any way to access the drawable by style and set that? Nov 14 17:40:10 otherwise i'm going to have to just copy in the images :\ Nov 14 17:42:03 looking at ImageView, i doubt i can access that information. hmm. Nov 14 17:43:13 oh wait. hmm, this drawable is also in android.R.drawable Nov 14 17:58:39 so I fail... can Nov 14 17:59:02 *can't get my button to show -> http://pastebin.com/m372a520a Nov 14 17:59:30 remove .png Nov 14 18:00:44 awesome! thanks jasta Nov 14 18:00:49 also, think twice about using AbsoluteLayout. if you used it only because you don't know anything about other layouts then you are almost certainly wrong. Nov 14 18:01:00 k Nov 14 18:01:55 I'm probably vertianly wrong :/.. guess I better look into layouts more Nov 14 18:02:08 my personaly preference is to try to make a LinearLayout work first. Nov 14 18:02:14 it's my "go to" layout. Nov 14 18:02:19 personal* Nov 14 18:03:08 it is flexible enough to satisfy the vast majority of layouts you see in use by Android apps. Nov 14 18:05:45 hey yakischloba Nov 14 18:06:01 yo Nov 14 18:07:13 jasta: cool thanks. A bit more to this than I'm used to. Nov 14 18:07:39 g1er: if you haven't already, look at the ApiDemos. spent a lot of time there. Nov 14 18:08:12 specifically Views, Layouts, LinearLayout Nov 14 18:10:31 jasta: hows it goin Nov 14 18:10:49 pretty good, working on some UI improvements to Five Nov 14 18:11:23 nice. I'm down by you at my old job right now Nov 14 18:11:42 im working from home today :) Nov 14 18:11:43 working on my weekend, as usual :/ Nov 14 18:11:45 ahh Nov 14 18:11:47 nice Nov 14 18:26:42 i've gotta drive out to my gf's dad's house tomorrow so i'm also working on making five work better over EDGE :P Nov 14 18:27:15 reencoding to a lower bitrate and such (but recovering to the original when 3G is restored) Nov 14 18:35:13 heh Nov 14 18:35:15 does anyone know off hand how to prevent screen rotation? some property in the manifest i think i just cant remember Nov 14 18:35:50 configChange="orientation" Nov 14 18:36:25 awesome thanks Nov 14 18:37:01 android:screenOrientation="portrait" <- will this also do it? Nov 14 18:37:42 yes that one Nov 14 18:37:51 habe not tried it.. just searched in and-dev Nov 14 18:38:13 hmm, screenOrientation="sensor"? Nov 14 18:38:30 that will change the orientation based on the sensor Nov 14 18:38:38 surprisingly :) Nov 14 18:38:49 yeah except i havent seen that ever do anything? are you sure it works? Nov 14 18:38:54 yes Nov 14 18:38:57 it looks like its on for MovieView? Nov 14 18:39:13 I don't know what MovieView is :) Nov 14 18:39:15 are we talking the accelerometer sensor or something else? Nov 14 18:39:33 it's in Music, loaded up anytime a movie is playing (from the sd card, or in YouTube i think) Nov 14 18:40:50 I better don't enable it... it will be a neverending onCreate() onDestroy() :P Nov 14 18:41:57 YouTube doesn't use MovieView Nov 14 19:44:05 is there a way to simulate the phone falling asleep on the emulator? Nov 14 19:44:11 or at locking it? Nov 14 19:44:27 at least* Nov 14 19:44:55 press the red key? Nov 14 19:45:32 oh, i've been using -skin hvga i forgot about all the buttons Nov 14 19:46:34 I don't remmeber which one on the keyboard is the red key Nov 14 19:46:35 does this eventually simulate cpu sleep? Nov 14 19:46:38 no idea Nov 14 19:46:39 f4, i think Nov 14 19:47:04 fortunately i have not had to concern myself too much with cpu sleep yet. i hold a wake lock pretty much always Nov 14 19:56:30 what is the home key supposed to do? Nov 14 19:56:39 it appears to stop the current activiuty (call onStop()) Nov 14 19:56:41 but not destroy it Nov 14 19:56:46 and go back to the application manager thing Nov 14 19:56:55 that's the point. Nov 14 19:57:05 applications are designed to stay running as long as there are resources to allow them to Nov 14 19:57:17 how can I go back to my application? Nov 14 19:57:44 by selecting the app icon in the manager? Nov 14 19:58:06 a number of different ways. generally, by just opening it again like you did the first time. Nov 14 19:58:25 and android should restore your app to the state the user left it in. Nov 14 19:58:29 assuming that you cooperate Nov 14 19:58:32 ok, so I have application with an activty stack a->b Nov 14 19:58:38 I press home when in B Nov 14 19:58:42 read the Activity documentation. there is a lot of detail you need to understand. Nov 14 19:58:43 I get onStop() called on B Nov 14 19:59:01 when I click on my application I get actiivty A, not B at the top... Nov 14 19:59:21 so the state is not being restored as I expect Nov 14 20:00:21 because your app is broken, or you are setting parameters you don't understand. Nov 14 20:00:57 again, read about the activity lifecycle. i am certain it will reveal something you misunderstood before. Nov 14 20:01:16 when I press home I get onStop() called on the activity at the top of the stack. When I re-click on the icon, I get onCreate/onResume() called on the activity at the top of the stack Nov 14 20:01:20 sotty Nov 14 20:01:23 at the bottom of the stack Nov 14 20:03:01 I would have expected onResume() to be called on the activity that was previously at the top of the stack. Nov 14 20:03:39 and that is what normally happens, but there are a great many ways you can affect this default behaviour. Nov 14 20:04:02 and you've probably mistaken used one of them. Nov 14 20:04:34 and my recommendation to you remains to read the activity documentation. Nov 14 20:04:54 yes, I read that stuff before many times ;) I've just finished rearranging the application to correctly deal with orientation changes Nov 14 20:05:05 which destroys & re-creates the top-stack activity Nov 14 20:05:07 all that stuff works Nov 14 20:05:41 are you calling finish for any reason? Nov 14 20:06:02 it does call finish if the user logs out, or a fatal application error occurs Nov 14 20:06:16 and you are certain this code path is not being taken mistakenly? Nov 14 20:06:40 if finish() was called from activity B Nov 14 20:06:53 then...? Nov 14 20:07:05 then shouldn't onActivityResult be called in activity A (B is always started as a sub-activity) Nov 14 20:07:46 sub activities don't get resumed as you think they do Nov 14 20:07:54 ahha Nov 14 20:07:59 now we're getting somewhere :) Nov 14 20:09:17 also, i remain skeptical that you are managing the lifecycle properly still :) Nov 14 20:09:40 heh, well its entirely possible! So am I supposed to manually start a sub-activity then? Nov 14 20:09:55 how do you mean "manually"? Nov 14 20:10:21 ok, the applicaiton progresses as follows: login->interact->interaction detail, etc Nov 14 20:11:19 ok? Nov 14 20:11:34 so the first activity is login. The user logs into the system, progresses to the interact activity (which at this point is a sub-activity). as I said, at present if the user presses home, interact is stopped, and we go back to the applicaiton picker. When the aplication is restarted, I get onCreate called on login again. At this point, am I supposed to manually res-tart the interact activity? Nov 14 20:12:04 so your login activity spawns the entire rest of your application as a sub activity? that is incorrect behaviour. Nov 14 20:12:35 how so? Nov 14 20:13:25 other than things not getting relaunched as I expected, that is :) Nov 14 20:13:45 sub activities are designed as a way for you to communicate simple pieces of information between the caller and some other activity the user might expect. like to choose a contact or email. Nov 14 20:13:50 and then return the users choice to you Nov 14 20:14:00 I mean, what is the point of a sub-activity? I used a sub-activity because I am then given an explicit callback when the interact ends (via a call to onActivityResult) Nov 14 20:14:08 leaving this activity explicitly is the same as the user "cancelling" this selection. Nov 14 20:14:41 imagine if you open an app that says "pick a contact to listen to the ring tone", the user clicks to list contacts, then just aborts the whole operation by pressing home. when they return, they expect to see your main activity again. Nov 14 20:14:47 because they have gestured to you to cancel the selection Nov 14 20:14:59 yes, ok Nov 14 20:15:01 applications are not supposed to design their entire work flow using sub activities Nov 14 20:15:06 it is quite incorrect behaviour Nov 14 20:15:09 ok Nov 14 20:15:34 the reason I used sub-activity was for the notifications I received... Nov 14 20:15:40 that is, I could tell the difference between Nov 14 20:15:47 the user returning from a sub-activity Nov 14 20:15:59 please explain precisely what information you need from your login activity Nov 14 20:16:06 i can almost certainly offer you a better design Nov 14 20:16:07 ok Nov 14 20:16:11 the user logs in Nov 14 20:16:19 moves to the interact activity Nov 14 20:16:22 and now presses back Nov 14 20:16:27 I want this to log the user out Nov 14 20:16:49 previously, I used the onActivityResult in the login activity to login the user out,. Nov 14 20:16:51 ok, so in onResume of Login just check if the user is logged in or not, and log them out if they are logged in. Nov 14 20:17:02 and stop using sub activities Nov 14 20:17:08 btw, this behaviour is stupid, i think :) Nov 14 20:17:16 what behaviour? Nov 14 20:17:24 if the user presses "back" out of your activity a bunch, they don't expect to be logged out. Nov 14 20:17:34 f they progress back to a login screen? :) Nov 14 20:17:44 what would they expect to happen? Nov 14 20:17:57 they would expect that if some short window later they reopen your app, it is already logged in Nov 14 20:18:14 much like if a user logs into facebook, closes their browser, and opens it again shortly after. they want to still be logged in. Nov 14 20:18:27 logging in consumes resources... Nov 14 20:18:34 I mean, it keeps a connection open to the server Nov 14 20:18:40 right, so don't log out except after a period of inactivity. Nov 14 20:18:52 an inactive connection does not take resources. Nov 14 20:18:59 making a new connection, however, does. Nov 14 20:19:20 there is actually back and logout Nov 14 20:19:29 I have them both doign the same thing at present Nov 14 20:19:34 I guess back could do something different Nov 14 20:19:40 like not work ;) Nov 14 20:19:48 or go back to the application chooser Nov 14 20:19:53 regardless of what i think of your wrong design, i have told you how to implement it properly in android. Nov 14 20:20:05 I was originally using onResume actually Nov 14 20:20:06 log the user out if logged in during onResume() of the Login activity. Nov 14 20:20:23 but I think I could determine why onResume was called Nov 14 20:20:26 couldn't. Nov 14 20:20:32 I will look again Nov 14 20:20:41 because you didn't read the fucking documentation i told you to read 30 minutes ago Nov 14 20:21:00 as I said.. I was *originally* using onResume Nov 14 20:21:03 to do exactly that Nov 14 20:21:09 but there was some issue Nov 14 20:21:13 and it's the right place to be doing it. Nov 14 20:21:14 which lead me to use a sub-activity Nov 14 20:21:22 so whatever issue you had was your fault, and you need to fix it Nov 14 20:21:27 right, I will go back and try that ;) Nov 14 20:21:57 thanks! Nov 14 20:23:04 by the way, the wireless carrier performs an orderly shutdown of any connection that has been inactivity for some period. i think like 10 minutes. Nov 14 20:23:26 so while you might perceive that you are leaving a connection open indefinitely, you in fact are not, deferring to the android system and the wireless carrier to close it when appropriate. Nov 14 20:23:39 the application has to send keepalive, so I don't think the carrier could do that Nov 14 20:24:11 i'm saying that you would let it die when you don't need the connection around. Nov 14 20:24:17 like most other applications do. Nov 14 20:25:13 what I'm saying is that the application needs to ping the server end, otherwise the server closes it. so therefore the connection cannot be shutdown automatically due to inactivity. the inactivity needs to be detected at the application level Nov 14 20:25:14 for instance. i have a streaming media app. if the user backs out of my app, i still leave the connection manager around in case they return shortly. if they do not, one of the carrier, remote peer, or my own socket timeout will close it, and then i don't care. Nov 14 20:25:41 the activity is not at the network level in this case. Nov 14 20:25:47 but if they do return shortly, tehn a new connection is not needed. Nov 14 20:25:51 yes Nov 14 20:25:58 I'll almost certainly do that Nov 14 20:26:19 if you are sending keep alives, then you need to appreciate that your app will keep these connections around potentially forever. Nov 14 20:26:35 which is a massive drain on battery life. i hope your users expect that. Nov 14 20:26:41 yes, hence the detection needs to be at the application level Nov 14 20:26:57 if i open your app, login, then decide i'm done with you and press home... when are you going to close that connection if i never return? Nov 14 20:27:26 yes, that is precisely the issue I was trying to deal with :) obviously, I want to kill the connection at some point. I was hoping to do so immediately Nov 14 20:27:31 but that isn't very easy to work out with the android model Nov 14 20:27:40 so it needs to be timeout based Nov 14 20:27:47 you do so after a period of inactivity, as i told you. Nov 14 20:27:51 exactly Nov 14 20:27:56 you clearly do not understand the work flow of android apps Nov 14 20:28:14 by the way, unless you are using an AlarmManager, your keep alives won't do shit. Nov 14 20:28:26 ? Nov 14 20:28:40 the cpu will fall asleep on you shortly after the screen turns off. Nov 14 20:28:57 and my threads will get no activity? Nov 14 20:29:01 when the cpu sleeps, your timers will no longer work, so your client will never send a keep alive Nov 14 20:29:23 the keep alive is currently sent in a thread Nov 14 20:29:24 the only way to wake the cpu back up again is to either have th eserver send data (which triggers the radio to wake up the cpu), or to use an AlarmManager (which is very expensive) Nov 14 20:29:52 basically the thread sleeps and periodically wakes, and sends a message Nov 14 20:30:09 ok, if that won't work, then I'll need to fix that too! Nov 14 20:30:13 and that won't work. Nov 14 20:30:38 sleep() and other timing routines are built to sleep a minimum of the timeout you specify, not a maximum. Nov 14 20:31:02 if you suggest that you want a sleep of 2 minutes, for instance, and the cpu falls asleep, that sleep will not return until the cpu wakes again Nov 14 20:31:05 which might be hours later. Nov 14 20:31:27 the carrier in the mean time would have reset your connection (which incidentally would have woken the cpu for you to deal with disconnection) Nov 14 20:31:50 its actually a wait, but I guess that would work in the same way Nov 14 20:31:55 regardless, your keep alive would not function. Nov 14 20:31:59 indeed Nov 14 20:32:07 yes, all non-realtime timing routines will be affected by the cpu sleeping Nov 14 20:32:22 only a realtime alarm (as with AlarmManager) is capable of waking the cpu from sleep to do something Nov 14 20:32:28 and this should be used sparingly, as it drains the battery substantially Nov 14 20:33:01 implementing long-lived tcp connections efficiently on mobile devices is a very complicated topic. Nov 14 20:33:08 indeed! Nov 14 20:33:10 ok, that's very good info. thanks Nov 14 20:33:13 by the way, i implemented IMAP IDLE / push e-mail support in the Email app. Nov 14 20:33:21 I mean if the user drops out of the app Nov 14 20:33:27 then it should drop the connection quite quicky Nov 14 20:33:37 what i'm telling you is that your work flow does not match android's work flow, and you must change it. Nov 14 20:33:44 the lifecycle is substantially different from the iPhonme Nov 14 20:33:47 do not use keep alives, allow your connection to fail. then recreate it if the user wants it again Nov 14 20:33:48 where the app initially lives Nov 14 20:33:51 but do not explicitly disconnect it Nov 14 20:33:57 it *must* have keep alives Nov 14 20:34:02 I cannot change the server arch Nov 14 20:34:10 whiel teh user is using the app Nov 14 20:34:14 the connection must be kept alive Nov 14 20:34:20 while the user is using the app you dont need keep alives Nov 14 20:34:25 because there is transmission Nov 14 20:34:32 (assuming the protocol actually _does_ anything) Nov 14 20:34:46 consider this scenario... Nov 14 20:34:54 I'm telling you that in this case Nov 14 20:34:58 the user opens your app, logs in, then sets the phone on their desk Nov 14 20:34:59 the client does need to send keep alives :) Nov 14 20:35:03 30 seconds later, the phone falls asleep Nov 14 20:35:07 they pick the phone back up several hours later Nov 14 20:35:08 otherwise the server kicks the client Nov 14 20:35:10 should your connection have been alive? Nov 14 20:35:24 well, that is a good question... and I don't know the answer Nov 14 20:35:31 for this application, the answer is probalby yes Nov 14 20:35:33 the answer, you fool, is that you let your connections time out and die Nov 14 20:35:38 and you recreate them on demand Nov 14 20:35:49 *ugh* Nov 14 20:36:03 ok Nov 14 20:36:06 and the alert the user Nov 14 20:36:07 unless you intend to have your server wake the phone up for some reason, you want the connection to die Nov 14 20:36:08 expected to get Nov 14 20:36:14 telling them the server farm is burning down Nov 14 20:36:19 that went missing Nov 14 20:36:22 because you dropped the connection Nov 14 20:36:27 nice Nov 14 20:36:28 your app is a monitoring application? Nov 14 20:36:40 yes Nov 14 20:36:42 as I told you Nov 14 20:36:47 then why would it _ever_ disconnect? Nov 14 20:36:59 i mean, why would it not be a service that starts on boot, and runs forever? Nov 14 20:37:00 holy fuck Nov 14 20:37:14 anyway Nov 14 20:37:23 the application lifecycle on the iphone was very obvious Nov 14 20:37:25 the user starts the app Nov 14 20:37:29 loooks at the monitoring Nov 14 20:37:34 and terminates the app when they are done Nov 14 20:37:36 the lifecycle on the iphone is miserably broken Nov 14 20:37:44 the lifecycle is very obvious Nov 14 20:37:45 this is not how android works, because android is not miserably broken. Nov 14 20:37:51 it is when the application is running Nov 14 20:37:51 it's obvious because it's wrong! Nov 14 20:37:55 it is not Nov 14 20:38:09 it is different Nov 14 20:38:12 that does not make it wrong Nov 14 20:38:14 if i am a sysadmin, and i have an app that will alert me if my servers crash Nov 14 20:38:21 why on earth would i ever NOT want such an app running? Nov 14 20:38:34 you really cannot think of reasons why? Nov 14 20:38:38 like, for exmaple, my cow-orker Nov 14 20:38:41 came on shift? Nov 14 20:38:47 why, when i press home, go check my email, then eventually put my phone in my pocket, would i not want to still be alerted of my server farm catching fire? Nov 14 20:38:56 because it is no longer my responsibility Nov 14 20:38:58 it is a coworker Nov 14 20:39:04 well then have an app that lets you explicitly enable/disable monitoring Nov 14 20:39:08 and lets you pick a schedule for this if you want Nov 14 20:39:18 but for the love of god don't require the app running in the foreground to do its job Nov 14 20:39:31 at any rate, what is clear is that models are substantially different ;) Nov 14 20:39:31 that is like saying that if i go check my email i will no longer be able to tell if my server catches on fire Nov 14 20:39:35 and that makes no fuckin sense Nov 14 20:40:00 right, because the iphone model doe snot permit apps to run in the background. android fixed this broken design. Nov 14 20:40:22 and in return the entire lifecycle of an application si entirely nebulous :) at any rate Nov 14 20:40:27 your app, from the sounds of it, should be a persistent service which the user controls through your activities Nov 14 20:40:36 but is not implemented by those activities Nov 14 20:40:43 yes, that is more or less how it works Nov 14 20:40:51 no, i can assure you that is not how you've designed it. Nov 14 20:40:58 oh? Nov 14 20:41:02 you might think you have, but only through a series of tragically incorrect assumptions Nov 14 20:41:17 ok Nov 14 20:41:34 do you have a service component? Nov 14 20:41:40 yes Nov 14 20:41:49 it is the piece that connects to the server Nov 14 20:42:03 the activities get their data through that compoennt Nov 14 20:42:07 from the server Nov 14 20:42:14 how do they communicate with the service? Nov 14 20:42:24 notifications Nov 14 20:42:27 an interface Nov 14 20:43:15 through aidl? Nov 14 20:43:21 or through broadcast intents? Nov 14 20:43:37 sorry, its not a service in that sense. Nov 14 20:43:44 thats what i meant Nov 14 20:43:46 it is a static class Nov 14 20:43:52 which the activities communicate with Nov 14 20:43:54 if you dont have a service, you don't have what i described. Nov 14 20:44:12 android is just gonna kill your app when it feels like it and suddenly your alert system will not function Nov 14 20:44:24 and the user won't have any idea it's not working either. Nov 14 20:44:29 yes, I realize that. for now what I've done is good enough Nov 14 20:44:45 apart from the fact it doesn't work Nov 14 20:44:49 ;) Nov 14 20:44:51 you should implement a long-lived service which uses the AlarmManager to send keep alives, and you should display a notification while its connected os the user knows Nov 14 20:45:23 and then your entry point should be a simple "welcome" activity which checks if the service is connected, if it is, proceed to the main UI Nov 14 20:45:30 if it is not, ask the user to login or whatever Nov 14 20:45:34 right Nov 14 20:45:39 once in the main activity, offer controls to enable/disable the service Nov 14 20:45:50 do not use sub activities at all, and implement all work in the long-lived service Nov 14 20:46:17