Office Hours — Today, March 22

Saturday, March 19

Mar 22
3:55 PM
Mark M.
has entered the room
Mark M.
turned on guest access
4:00 PM
Ron
has entered the room
Mark M.
hello, Ron!
how can I help you today?
Ken B.
has entered the room
Ron
View paste (13 more lines)
Is it possible to communicate simultaneously over WIFI and through an Android device's network (call plan) to 

the Internet? Here is what we are attempting to do:

1. We have a custom 3rd party device that communicates by WIFI. This WIFI device retrieves various 

instrumentation data that we can read into the Android device via WIFI commands. The WIFI device does NOT have 

any access to the Internet though.

2. We need to take the data that we read from the WIFI device and send REST service Http commands through the 

Internet to our servers. We assumed that we could do this over the Android device's normal network 'call plan' 

but we can't seem to figure out how to configure the Android device for dual simultaneous access to local WIFI 
...
Mark M.
(BTW, hi, Ken -- I'll be with you next, after I read Ron's novel-length question... :-)
"Is it possible to communicate simultaneously over WIFI and through an Android device's network (call plan) to the Internet?" -- I think there's some official support for that in Android 6.0
and I'm under the impression that if you throw enough reflection at the problem and limit your app to only device models that you test, you might be able to get that working on earlier versions of Android
however, I have not tried the Android 6.0 stuff out to know how it works (e.g., how can you force HttpURLConnection to use such-and-so network)
Ron
Just to clarify, we only need the WIFI to be local and the Internet to be on our call plan.
Mark M.
from Android's standpoint, I'm not aware that the distinction matters
Ron
Any other suggestions?
Mark M.
not from an Android app standpoint
I look at this as a networking hardware problem
Ron
Okay, we will put our thinking caps on and play with 6.0 tonight. Thanks!!!
4:05 PM
Mark M.
let me take a question from Ken, and I'll be back with you shortly
Ken: your turn! do you have a question?
Ken B.
has left the room
Ken B.
has entered the room
Mark M.
hello again Ken!
Ken B.
Okay, how about now?
It kept asking me to log in.
Mark M.
if you're asking if I can see your message, yes, I can
Ken B.
So I am having problems with the back stack.
Shall I paste a 30 lines here?
just boilerplate, but it works funny.
Mark M.
if it's code, you might consider using a gist or pastebin or something, just for formatting
that being said, if you want to try pasting it here, you're welcome to
Ken B.
I don't know how to do those things.
Here it is.
View paste (79 more lines)
package com.kbakalar.flickrbrowser;

import android.content.Intent;
import android.os.Bundle;
import android.support.design.widget.FloatingActionButton;
import android.support.design.widget.Snackbar;
import android.support.v7.app.AppCompatActivity;
import android.support.v7.widget.Toolbar;
import android.view.Menu;
import android.view.MenuItem;
import android.view.View;

public class ViewPhotoDetails extends AppCompatActivity {

    @Override
...
that doesn't look so terrible.
This is launched with a specific intent from my MainActivity.
The prlbem is with the "up" button.
4:10 PM
Ken B.
IF I leave out the "onSUpportNavigationUp", the back button deletes the old MainActivity and starts a new one (with null instance state).
That means I can't restore the configuration of MainActiivity, of course.
Mark M.
presumably, that behavior is coming from your manifest configuration
Ken B.
let me show you.
View paste (32 more lines)
 <application
        android:allowBackup="true"
        android:icon="@mipmap/ic_launcher"
        android:label="@string/app_name"
        android:supportsRtl="true"
        android:theme="@style/AppTheme">

        <!-- android:theme="@style/Theme.Flickr"> -->

        <activity
            android:name=".MainActivity"
            android:label="@string/app_name"
            android:theme="@style/Theme.Flickr">
            <intent-filter>
                <action android:name="android.intent.action.MAIN"/>
...
Mark M.
OK, that more or less fits my expectations
however, your code has overridden onSupportNavigateUp(), and you are calling finish() there, returning true
personally, I find Google's "up" stuff to be a train wreck, and so I avoid it
Ken B.
Yes, if I do that, it does what I want-- it restarts my MainActivity.
ha
Mark M.
OK, so... what's the problem?
4:15 PM
Ken B.
If I leave out the onSupportNavigateUp(), it acts wierd, as I described above.
Mark M.
it's working pretty much as I would expect
Ken B.
It creates a brand new virgin MainAcitivy and deletes the old
from the stack, Imean
Mark M.
that's not surprising
back != up
unless you do what you are doing with finish()
your manifest configuration says "when the user presses up, create an instance of this activity"
Ken B.
Why wold I ever want the default behavior?
oh
Mark M.
perhaps the "up" activity != the "back" activity
Ken B.
okay.
Okay, next q
Mark M.
wait!
let me take another question from Ron, and then I'll swing back to you in a bit
Ron: your turn! do you have another question?
Ron
Is there any way to search through your old chats?
Mark M.
use site:commonsware.com as a qualifier in a Google search
now, that'll pull in my blog posts as well
Ron
Great! We just found this bit academia regarding HTTP to multiple connections:
Mark M.
that's a little long for me to read right now
Ron
We are going to signoff, THANKS!
Ron
has left the room
Mark M.
you are very welcome!
Ken: back to you!
Ken B.
RIght.
4:20 PM
Ken B.
View paste (83 more lines)
package com.kbakalar.flickrbrowser;

import android.app.SearchManager;
import android.content.Context;
import android.content.Intent;
import android.net.Uri;
import android.os.Bundle;
import android.support.v7.app.AppCompatActivity;
import android.support.v7.widget.SearchView;
import android.support.v7.widget.Toolbar;
import android.view.Menu;
import android.view.MenuItem;

public class SearchActivity extends AppCompatActivity implements
        SearchView.OnQueryTextListener{
...
Again, I start this with a specific intent.
It doesn't do anything except return the text result, embedded in a URL.
Mark M.
"return"?
oh, wait, there's setResult()
Ken B.
right.
View paste
<?xml version="1.0" encoding="utf-8"?>
<searchable xmlns:android="http://schemas.android.com/apk/res/android"
    android:label="@string/searchable_label"
    android:hint="@string/searchable_hint"
            android:voiceSearchMode="showVoiceSearchButton|launchRecognizer"
    >

</searchable>
Note the voiceSearchMode
As long as I type the query, everything works as planned.
If instead I speak the query, the recognizer accepts the input and then a new copy of SearchActivity is pushed on the stack and opened.
It will keep doing that -- I can make the stack as deep as I want, with multiple copies SearchActivity.
4:25 PM
Mark M.
that's in part because SearchActivity isn't really the vision here
the idea behind Google's search system is that you have search options elsewhere in your app, that lead to a search results activity
having a dedicated "this is where the searching shall be done" activity, that fills both roles, isn't really what they had in mind
Ken B.
Yes, I thought there was something confused about that.
Wait.
What is the second role again?
You say both roles.
Mark M.
first role: collecting a search query
second role: showing search results from processing said query
now, android:launchMode="singleTask" may be sufficient to allow you to implement both roles in the same activity
Ken B.
MainActivity shows the search results. It shows the database items that have the key. This thing only collects a query (so far).
Mark M.
um, OK
Ken B.
MainActivity displays the items with the collected key.
Mark M.
Android thinks its the activity that is showing the search results
Ken B.
It's funny that it works fine with typed input, but fails mysteriously with voice input.
hm.
But only for the voice input...
4:30 PM
Mark M.
that's because that's going through Google's search framework, versus your own SearchView
and you are advertising that this activity is the one doing the search, via your <intent-filter>
Ken B.
The light is slowly dawning.
Mark M.
android.intent.action.SEARCH says "I exist to show search results"
Ken B.
I am little confused by the nomenclature "searchable"
Mark M.
yeah, well, in part that's because I nuked my chapter on search, as it's such a mess
Ken B.
It seems to mean "searcher" rather than "searchable"
Mark M.
:-)
Ken B.
anyway, searchable is an adjective. Why not use a noun to name a thing?
Mark M.
¯\_(ツ)_/¯
Ken B.
Okay, so I have fallen in to another one of these holes where Android provides bizzare behavior in lieu of an error message.
Mark M.
from Android's standpoint, there's no error
Ken B.
So then, I am right that a
Mark M.
it's just trying to follow instructions
and in your case, your instructions don't line up with what you're expecting
Ken B.
"searchable" is something that does searches, rather than something that can be searched (for something).
Is that right?
Mark M.
I'd phrase it more as saying "this is how I can be searched, using Google's device-level search system"
Ken B.
YOu don't need to stand up for android.
Mark M.
good, because I'm sitting down right now
4:35 PM
Mark M.
I do need to dive back into this again and see if I can try to help people make sense of it
Ken B.
Okay, I am going to use the ActionView on the same Activity that displays the results. That makes more sense anywat.
anyway.
ONe more?
Same text.
Mark M.
go right ahead, since there's nobody else here
I try to rotate between chat participants, which is why I interrupted you earlier to give Ron another shot
Bryon
has entered the room
Ken B.
When I reconfigure to landscape, the appearance of the query input widget changes. It no longer appears over the app bar, and instead fills the entire screen with a big white space with a keyboard at the bottom.
Mark M.
such as now, since we have a new chat participant -- let me take a question from Bryon, and I'll be back with you shortly
Ken B.
cool.
Mark M.
Bryon: hi! welcome to the chat! do you have a question?
(Ken: what you're seeing sounds like standard EditText behavior in landscape)
Ken B.
ugh.
Bryon
Looking for advice on calling REST services
4:40 PM
Mark M.
at a high level? use Retrofit and HTTPS
4:40 PM
Mark M.
did you have something more specific in mind?
Bryon
We currently us loaders. I'm wondering is there is a better more up to date approach
Mark M.
um
I'm not an especially big fan of the loader framework, though you're welcome to use it
what you use with respect to dealing with Web service results depends a *lot* on the nature of the app
if you're asking what else to use instead of loaders, retained fragments are another option, and the one that I tend to use
at least, for activity-level result caching
Bryon
What kind of threading would you usein that scenario?
Mark M.
often, I'll just use a plain thread, but an AsyncTask can work
it depends a bit on what else you need to do once you get the Web service results
Bryon
What kind of considerations?
Mark M.
the fact that you're using loaders suggests that this is a Web service call whose scope is a single activity
Bryon
Mostly, yes
4:45 PM
Mark M.
in that case, if you need to have the activity (or a UI-based fragment) do something with the Web service results, an AsyncTask in the retained fragment is a reasonable approach
as you can trigger the post-call work in onPostExecute()
but, if the Web service is not really downloading anything (e.g., we're just posting something), a plain thread might work
and, more often than not, I'm not doing this sort of network I/O in the UI layer anyway, but instead am using an IntentService, some persistent backing store, application-level caching, etc.
and in those cases, you're looking more at threads coupled with an event bus or something like that
there are also many fans of the RxJava approach, though I haven't gotten into that yet
Helen of Troy is said to have had "the face that launched a thousand ships"; threading in Android is the problem that launched a thousand solutions
let me return to Ken's question from just when you arrived, and I'll swing back to you in a bit
Ken: as I parenthesized, what you're describing sounds fairly normal
android:imeOptions can help manage this, at least for EditText
Ken B.
So, is there anyway to get the same single-line query on landscape as is provided in portrait by default?
4:50 PM
Mark M.
ah, and android:imeOptions exists on SearchView as well
Ken B.
Okay, I'll look.
Thanks. That's all for now. I am sure to get in much more trouble soon.
Mark M.
look at flagNoFullscreen
as an imeOption
Ken B.
okay.
Mark M.
OK, that sounds fine
Bryon: back to you! do you have another question?
Bryon
Thanks for the help. My employer blockscampfirenow so I'm trying to interact on my phone. This is my first time in your office hours. Just wanted to check it out.
Mark M.
that's an odd site to block
anyway, if either of you come up with another question in the remaining few minutes, chime in!
BTW, if you missed the announcement, Version 7.2 of the book was released yesterday
4:55 PM
Bryon
I saw that. Looking forward to the updates
Ken B.
adios
Ken B.
has left the room
Ken B.
has entered the room
Ken B.
OH!
Bryon
Will the new N network config replacesome of your security library capabilities?
Ken B.
a short one.
Mark M.
Bryon: somewhat, for the SSL configuration
I'm actually chatting with the NetCipher maintainers -- one of them suggested implementing a quasi-backport of the network configuration options
Ken: go right ahead
Bryon
OK, thank you.
Ken B.
View paste
        getSupportActionBar().setDisplayHomeAsUpEnabled(true);
//     TODO:   activateToolbarWithHomeEnabled(); for support of older versions?
from VIewPhotoDetails, that I sent you.
What is the difference?
Mark M.
presumably, it's a question of whether you are using a Toolbar as your action bar/app bar, or whether you are using the default implementation
but, I'm not an AppCompatActivity expert by any means
this has been an epic chat in terms of questions that hit upon things in Android that I don't like... :-)
Ken B.
Okay, next time.
5:00 PM
Mark M.
the next chat is tomorrow at 7:30pm US Eastern
and that's a wrap for today's chat
Ken B.
has left the room
Mark M.
the transcript will be posted to https://commonsware.com/office-hours/ shortly
have a pleasant day!
Bryon
You too
Bryon
has left the room
Mark M.
turned off guest access

Saturday, March 19

 

Office Hours

People in this transcript

  • Bryon
  • Ken Bakalar
  • Mark Murphy
  • Ron