Office Hours — Today, April 19

← Saturday, April 16

Apr 19
8:55 AM
Mark M.
has entered the room
Mark M.
turned on guest access
9:05 AM
Ken B.
has entered the room
Mark M.
hello, Ken!
how can I help you today?
Ken B.
Good morning.
I have a bunch of diffuse questions, and some specific ones.
First:
Android comes with a lot of prebuilt styles and styles intended for themes and R.id things and so on
But I can't find any coherent, single description of these items. Am I looking in the wrong places?
Mark M.
you would have to look in some parallel universe, where this stuff is concisely documented
Ken B.
That's conforting.
comforting
Mark M.
usually, people find the concept of parallel universes to be anything but comforting
Ken B.
So, randomly searching around StackOverflow is the best bet?
the concept relieves us of all moral responsibility.
Let's not talk about moral philosophy.
Mark M.
hunting around to see what others have done with their experiments with these themes and styles is one approach
9:10 AM
Mark M.
you can also see what Google uses them for
Ken B.
by looking at google sources?
Mark M.
http://xref.opersys.com/
Ken B.
ha
Mark M.
yes
Ken B.
okay, I'll try.
Mark M.
the Opersys search engine helps, as you can find references to various strings and symbols
Ken B.
What is Opersys search engine?
Mark M.
the link that I posted a bit ago in the chat: http://xref.opersys.com/
Ken B.
Oh, on that site.
Mark M.
yes, you choose your Android version, and you get a somewhat convoluted search form
Ken B.
I have spent weeks refining a dumb project that uses searchview, but I am unhappy with ti.
First, take a look at this:
View paste (133 more lines) 
package com.kbakalar.flickrbrowser;

import android.app.SearchManager;
import android.app.SearchableInfo;
import android.content.Context;
import android.content.Intent;
import android.net.Uri;
import android.os.Bundle;
import android.support.v4.content.ContextCompat;
import android.support.v7.app.AppCompatActivity;
import android.support.v7.widget.LinearLayoutManager;
import android.support.v7.widget.RecyclerView;
import android.support.v7.widget.SearchView;
import android.support.v7.widget.Toolbar;
import android.util.Log;
...
It is a searchable that is engineered to be its own searchable as well, in order to allow the user to refine his query.
First, is that a reasonable strategy?
Mark M.
I haven't tried that
on the whole, I've been underwhelmed by Android's search framework
9:15 AM
Mark M.
I haven't worked with it seriously in ~5 years
which is why I yanked my chapter on it, as that chapter was stale
Ken B.
Is there another strategy for refining a search that is more common.
Mark M.
I'll hopefully have time to try it again in the future
I can't really answer that
Ken B.
In trying to figure it out, I rewrote the Android tutorial doc for searchview in English. You are welcome to it.
Mark M.
sounds like a great post for your blog, if you have one
Ken B.
No blog.
Have you any experience with launchmode singletop
Mark M.
a bit
on the whole, I try to avoid fussing with launchMode
for exported activities, sometimes it is unavoidable
Ken B.
what is an exported activity
Mark M.
one with an <intent-filter>
i.e., one that a third-party app can start
Ken B.
ok
9:20 AM
Ken B.
I am confused about onSaveInstanceState/ onRestore*
It seems that onSave.* is called at various times in the cycle, depending on the weather or the phase of the moon. Is that observation valid?
Mark M.
it is called around the time of onPause()/onStop(), in cases where the activity is not being immediately destroyed
Ken B.
For example, sometimes it is called just after onCreate (and before the onCreateMenu) which makes it hard to save the state if part of the state is created there.
Mark M.
I have never seen that
Ken B.
hm.
I may be hallucinating.
Mark M.
if you come up with a sample app that can reproduce the behavior, shoot me a link, and I can take a peek at it
Ken B.
Easy to do after too many hours at the terminal.
It's this one.
See where I am testing searchView = null in onsave instance state
Mark M.
yes
it'
9:25 AM
Mark M.
it's possible that launchMode is somehow triggering this behavior
Ken B.
that is because it is called before oncreateoppitons menu
Mark M.
though I'm not aware that it would be
you're also using AppCompatActivity, which I generally avoid
Ken B.
I used it becasue google asked me to.
Next.
Mark M.
BTW, ot'
Ken B.
huh?
Mark M.
BTW, it's not completely out of the question for onSaveInstanceState() to perhaps be called before onCreateOptionsMenu(), but there would have to be some specific reason for it (e.g., configuration change)
Ken B.
That would be quick work for the wrist, to force a configuration change before the app menu appears.
Mark M.
so, your defensive programming might be needed
agreed
statistically, it is improbable
and so if you're seeing it repeatedly, it's likely stemming from something else
Ken B.
The books say that the state of views that have id's are saved.
automaticall, on config change.
Mark M.
for user-mutable state, yes
Ken B.
but that doesn't seem to hold for the contents of the textedit in searchview.
So I have to save it myself here.
Am I doing right?
Mark M.
most likely
I seem to recall running into this too
Ken B.
assuming, of course, I want to save a partially entere query on state change.
9:30 AM
Mark M.
let's rephrase it as "well-written widgets will save their user-mutable state automatically"
9:30 AM
Mark M.
SearchView may be screwing up the state management
Ken B.
so this is not an hallucination.
Mark M.
I don't think so
OTOH, you could be hallucinating this chat
Ken B.
Which relieves you of all moral responsibility for it.
Mark M.
you were hallucinating the moral responsibility, too
Ken B.
Now, there are two paths into onNewIntent
Both are from searchview, one from a text query and the over from a spoken query
See onNewItent.
Mark M.
I don't completely grok the "a searchview in a different activity requests a search on second and subsequent calls" comment
Ken B.
You would think that forwarding the query would remove focus from the query widget. Which is true for text, but not for voice.
9:35 AM
Ken B.
I am thinking ahead. I am supposing that this thing can be invoked as a searchable from a separate activity.
In that case, the activity will be created, and onCreate will be called rather than onNewIntent.
Once the thing exists, calls go through onNewIntent.
Mark M.
that assumes the thing exists
if you have some nav option that keeps this activity around yet lets you go back to some outside activity, OK
Ken B.
right.
Mark M.
but if, say, the user presses BACK from this activity, it's destroyed, and the separate activity would wind up creating a new instance of this activity on a future search
Ken B.
So that complication doesnt' exist.
Things are not as bad as they seem. Only nearly so.
Mark M.
but, with regards to the difference in focus behavior, I can't explain that
if anything, I would have expected the inverse behavior (text would keep the focus, voice would not)
9:40 AM
Ken B.
I am concerned about all this complicated logic I need to save and restore state.
It seems klugy.
is it typical?
Is there a clean way to do it ?
Mark M.
"typical" varies by app, but what you have is not unreasonable
assuming that it's all necessary, which I'm not really in position to comment upon
Ken B.
that, I guess, was my question. Whether I was way off base.
I have tested it all to try and eliminate some of it, and it is all necessary.
Mark M.
in terms of "clean", cleanliness, like beauty, lies in the eye of the beholder
9:45 AM
Ken B.
The logic is there just to preserve the status quo ante. When the user changes configuration, I want show the same state he started with. It just doesn't seem good that it takes so much logic to do "nothing".
Mark M.
ah, but this isn't just for configuration changes
Ken B.
what else/
View paste 
?
Mark M.
while that may be the more common scenario, it's also for when your process gets terminated but the user returns to your app's recent task fairly quickly (e.g., within a half-hour)
in that case, Android is going to try to return the user to the app in the state in which they left it, versus coming through the front door of the launcher activity
and so, your new activity in your new process gets your saved instance state
this is why Bundle is limited into what it can store -- that data has to be able to be passed across process boundaries
Ken B.
by terminated, you mean he hits the back button, or home button?
Mark M.
user is in your app, then navigates to another app (HOME, incoming call, you launch the other app, recent-tasks list, whatever)
when your app is not in the foreground, your process can be terminated at any point
Ken B.
Because, I think when I hit the back button then restart, I don't get a Bundle.
Okay.
9:50 AM
Ken B.
I am surprised and chagrined that the Google documentation is so raggedy ass. I gues they expect you to read the source, like a real person.
Mark M.
the docs vary in quality
and, Android is vast
but yes, it would be nice if they spent more time on the docs
when some balding guy in eastern PA can write about as much as Google does about Android, there's a problem
Ken B.
True. But if some of these writers were working on my product (and a bunch did) they would have learned a thing or two by now.
Mark M.
oh, I don't doubt that Google has the knowledge and experience
what they lack is people writing the documentation
Ken B.
Okay, I am going to have to let you go. I can't think of anything else right now. But I'll be back.
Mark M.
OK
the next office hours chat is tomorrow, 4pm US Eastern
9:55 AM
Ken B.
Adios
Ken B.
has left the room
10:00 AM
Mark M.
turned off guest access

← Saturday, April 16

 

Office Hours

People in this transcript

  • Ken Bakalar
  • Mark Murphy