Lines Matching refs:we
42 <code>res/values</code> — there are several new strings which we will use
48 field used to hold the cursor we are using.
61 which we will be filling in below.
79 <li>In order for each list item in the ListView to register for the context menu, we call
88 menu callback used for the options menu. Here, we add just one line, which will add a menu item
97 …an extra object that may contain additional information about the object selected. However, we don…
98 …these here, because we only have one kind of object in the Activity that uses context menus. In th…
99 step, we'll handle the menu item selection.</p>
104 …<p>Now that we've registered our ListView for a context menu and defined our context menu item, we…
105 to handle the callback when it is selected. For this, we need to identify the list ID of the
119 <p>Here, we retrieve the {@link android.widget.AdapterView.AdapterContextMenuInfo AdapterContextMen…
132 classes we already know about, be they in our own application or another
133 application, we can also create Intents without knowing exactly which
135 <p>For example, we might want to open a page in a
136 browser, and for this we still use
137 an Intent. But instead of specifying a class to handle it, we use
138 a predefined Intent constant, and a content URI that describes what we
154 operating system to route requests, we also have to provide a Context (<code>this</code>).</p>
158 <code>onActivityResult()</code> and we will implement it in a later step. The other way
163 we will fix that soon. </p>
170 <p><code>onListItemClick()</code> is a callback method that we'll override. It is called when
175 <code>mRowId</code> of the item that was clicked. In this instance we can
176 ignore the first two parameters (we only have one <code>ListView</code> it
177 could be), and we ignore the <code>mRowId</code> as well. All we are
185 to pass in the title and body text, and the <code>mRowId</code> for the note we are
203 to pass in to intent invocations. Here, we are
204 using the Bundle to pass in the title, body and mRowId of the note we want to edit.
207 The details of the note are pulled out from our query Cursor, which we move to the
210 <li>With the extras added to the Intent, we invoke the Intent on the
218 we make only one access to the field, and five accesses to the local variable, making the
225 … methods use an asynchronous Intent invocation. We need a handler for the callback, so here we fill
278 In the case of a create, we pull the title and body from the extras (retrieved from the
282 In the case of an edit, we pull the mRowId as well, and use that to update
297 note_edit.xml layout file is the most sophisticated one in the application we will be building,
315 sophisticated UI we have dealt with yet. The file is given to you to avoid
320 here that we haven't seen before: <code>android:layout_weight</code> (in
330 <p>To give an example: let's say we have a text label
335 be split equally between them (because we claim they are equally important).
339 second (because we claim the second one is more important).</p>
351 <p>This is the first time we will have
388 Then we will grab and store the <code>mRowId</code> so we can keep
401 Find the {@link android.widget.EditText} and {@link android.widget.Button} components we need:
442 We also null-protect the text field setting (i.e., we don't want to set
450 what we are trying to achieve in this case is simple. We want an
477 operation is an edit rather than a create, we also want to put the
506 Intent caller. In this case everything worked, so we return RESULT_OK for the
587 which IntentFilters the activity implements here, but we are going to skip
591 to edit the AndroidManifest file, and we will use this. If you prefer to edit the file directly
638 your changes have been lost. In the next exercise we will fix these