On Sun, Nov 14, 2010 at 5:29 AM, Peter Webb <[email protected]> wrote: > Basically, in Notepad the intents are read (mostly) in > onPrepareOptionsMenu(). The system is "polling" the intent status > within the code. That strikes me as a somewhat arbitrary decision; > menu items are not directly connected to intents, and intents > themselves are asynchronous activities. Other apps appear to work > similarly.
Let's dissect this one sentence at a time, skipping the last one because I don't know what you are referring to. > Basically, in Notepad the intents are read (mostly) in onPrepareOptionsMenu(). Intents are not "read", any more than snowplows or sand dunes are. I am assuming what you are referring to is the call to addIntentOptions(). This technique has been generally abandoned by Google, particularly for their own apps, as they are concerned about "menu spam". I wish they would update this example to remove it. > The system is "polling" the intent status within the code. No. NotesList is saying, "yo, Android, what activities out there know how to deal with these...ummm...note thingies?" and is automatically adding menu items for each match, if any. > That strikes me as a somewhat arbitrary decision; > menu items are not directly connected to intents, and intents > themselves are asynchronous activities. Menu items can be directly connected to Intents, though that's not required. A menu item with an attached Intent will call startActivity() on that Intent. Otherwise, it is handled by your code in onOptionsItemSelected(). addMenuOptions() attaches Intents to each of the menu items it puts in the menu, so you do not have to otherwise deal with them. Intents are not asynchronous activities, any more than are baseballs or broomsticks. The *use* of Intents for startActivity(), startService(), and sendBroadcast() are all asynchronous. > What I was expecting was a method called something like > onReceivedNewIntent() which I could override, and centralise my intent > handling logic. ??? > That would mean that intents were using the same > pattern as UI events, and explicit polling logic is unneccesary. Again, there is no polling. > Is this it? Do I have to include my intent checking logic into some > other handler that I know will be called, like onPrepareOptionsMenu, > or is there some way of explicitly wiring an event handler to a > received intent? I would attempt to forget everything you attempted to interpret out of this section of Notepad. Sufficient quantities of alcohol may do the trick. :-) > Sorry about the noob question; I still don't "get it", and feel like I > am missing something important. Well, maybe. IMHO, addIntentOptions() was a silly thing to put in Notepad in the first place, even back when we thought it was relevant, simply because it's a fairly advanced technique and Notepad is specifically supposed to be for noobs. If you call startActivity() with an Intent, that will be received via onCreate() (normally) or onNewIntent() (occasionally) in the activity that you asked for. If you call startService() on an Intent, that will be received by onStart() of the service. If you call sendBroadcast() on an Intent, that will be received by onReceive() of any BroadcastReceiver registered to respond to Intents like the one you broadcast. I'm not sure how much this reply helped clear up your confusion, but if nothing else, perhaps it may help you form more targeted questions. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android 2.2 Programming Books: http://commonsware.com/books -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
