hi.

hello, Jeffrey!

how can I help you today?

How's it going?

OK, and you?

i wish it would stop raining so i can go workout. lol.

I wanted to follow up on my "invoking intents from chrome" question.

sure!

i haven't been able to read the section of the book you suggested yet, but I didn't want to miss office hours as I may not be able to make the next one on the weekend.

i'm not sure how much you can help in office hours though but i thought i would give it a shot.

I can try

i am just having trouble invoking my own from chrome. i don't know what i'm missing and i can't seem to find any sample code/working examples anywhere.

first: how are you invoking it?

i have an intent filter set up, i have the browsable category in place, package etc.

i try to invoke it either from chrome or adb.

i think i'm missing something. when the app is installed is it supposed to "register" itself with the OS or is there something else I have to do?

When you say "chrome", what exactly do you mean? Are you clicking a link in a page? Are you typing in an address bar? Are you doing something else?

(because the only right answer is: clicking a link in a page)

i have an anchor tag on a web page I load up in chrome on my android device.

OK, that should work in principle

can you post your <intent-filter>?

like this:

um, OK, that's not an <intent-filter>

are you saying that you are trying to use the intent: scheme?

i can get zxing to start as mentioned on that page, but i can't for the life of me get my own to work from chrome. i can invoke it from another test android app i created though. the breakdown must be how i'm creating the URL.

okay, well, what on my app side do i need to get this kind of invoking to work?

are you saying that you are trying to use the intent: scheme?

hmm let me check.

perhaps just post the URL that you are using in the link that you are clicking on (that isn't working)

i knew i should have brought my work computer home. i can't seem to remote into it.

can you explain what you mean by that's not an "intent-filter"?

well, an <intent-filter> is an XML element that goes in your manfiest

er, manifest

right. i am pretty sure i created that, too.

how else would you connect this URL to the app's activity?

most projects that I know of use https: (or http: [ick]) URLs

so you have an <intent-filter> that advertises that you support https://your.domain.goes.here.com/whatever/you/...

and then any links to that URL will do one of three things:

1. take the user to the Web page, if your app is not installed

2. give the user a chooser, to either open your app or a Web browser

3. go straight to your app, on newer versions of Android, if you set up all the assetlinks.json stuff

i'm desperately trying to figure out how to make it do either 2 or 3.

does debug mode have any affect on it? i compile, build, and deploy the app. it's nowhere near the app store yet.

custom schemes will not work especially well, as many apps have no idea what to do with them

and that's what line 82 is doing

i tried one of the "http" variants as well.

OK

that's what I was seeking originally, when I asked you for your <intent-filter>

does just installing the app do what's needed to "register" these intent filters with the OS or is there something more to it?

just installing the app is sufficient

i think i tried the line 61 variant as well.

same thing, just a different domain

(and path)

but in that one the scheme is http instead of zxing.

right

that is what most apps use

at least, those that try doing this sort of thing

okay, if I can't get anywhere with this then perhaps i'll back up a bit and explain why i'm doing this inthe first place as there may be another way.

in this documentation, Google explains how to set up "app links", which is basically the <intent-filter> stuff using the https/http schemes that we discussed above

is the digital asset links file absolutely necessary? i don't have one and I think someone on the forums mentioned they got it to work without it.

in my list of possibilities above, digital asset links is required for #3

it is not required for #2

got it. i figured that. as i'm in proof-of-concept mode right now, #2 is adequate. i just can't seem to get the deep links to work.

i have an industrial bluetooth printer that has no "plug in" from the maker into the android printing system like brother, epson, hp, etc. have. I need a way to print data from a web page. perhaps there is a different way?

i think web bluetooth api is still experimental right?

beats me

what does the printer manufacturer advise?

I already wrote an app that can print to this printer. I was just hoping to pass the data to it from the web page.

they advise using a third-party app that does exactly what i'm trying to do, but the licensing is cost prohibitive.

what do you mean by "pass the data to it from the web page", specifically?

if i can figure out this deep linking thing I've got the rest.

well, intents can receive data in an extra, right?

i want to send the data to be printed from a web page to my app which controls the printer.

an Intent can contain extras

deep links cannot express extras

i know all of this is theoretically possible. i just can't seem to get the first step working.

intent: scheme URLs cannot express extras

so, if your plan relies upon extras to work, you seem to be out of luck

so, what do you mean by "pass the data to it from the web page", specifically?

what is "the data"?

i thought you could use something like "S" variables.

sorry, but I do not know what that means

the google developer page i first referenced says you can pass data in extras. maybe they're just including it in the url.

Note that S.<name> is a way to define string extras. S.browser_fallback_url was chosen for backward compatibility, but the target app won’t see browser_fallback_url value as Chrome removes it.

their documentation is seriously confusing

lol.

you're telling me. it suggests looking at the Intent.java source for more info. gee, thanks, google!

do you think the section in your book can still help me?

I am looking at the "The basic syntax for an intent-based URI is as follows:" and not seeing it mention extras

if nothing else, I have examples that at least used to work

though I'll admit I haven't played with them recently

how much data are you trying to pass to the app?

If the activity you invoke via an intent contains extras, you can include these as well.

I would greatly appreciate the examples.

probably a few lines of text max. about the length of a receipt printed for a typical grocery store visit.

i know this is possible because an app called mobi print does exactly what i want.

you should be able to encode those as query parameters on an https URL, though those are somewhat annoying to get out of the Uri

exactly what i'm trying to do.

yeah, true.

one thing to note is that no solution here is universal

the manufacturer has an app that can accept PDF files and accepts intents but they didn't declare BROWSABLE so it can't be invoked by chrome.

universal in what way?

there may well be Android browsers that fail to handle your URLs in the way that you intend

i heard 6.0 and up supports this.

there are dozens, if not hundreds, of Web browser apps for Android

i am targeting only one specific device and it works with that app i mentioned, so I think I am okay out there.

oh, yes, our company only uses chrome.

this is an internal enterprise app.

oh, well, that helps

a lot.

the best thing that I can recommend, as a starting point, is to read that chapter and play with my sample apps

where do you make your samples available?

are they included on the warescription site?

all of the book samples are at https://github.com/commonsguy/cw-omnibus

great thanks.

the chapter will point you to specific ones and walk through how they work

https://github.com/commonsguy/cw-omnibus/tree/m... and https://github.com/commonsguy/cw-omnibus/tree/m... should be the two main ones

that's exactly what I need.

does your office hour end in 30 min?

yes

we've had an office half-hour so far :)

ok. well, since nobody else is here can i fire away with another question?

go right ahead!

awesome.

i'm curious about best practices with list views and such. i have a list view with several columns, but on a small screen form factor i'd like to know how to best manage so many columns. adding horizontal scrolling seems clumsy to me.

most apps that I see don't use columns too much, for that very reason

either each row is a card, or its some sort of expandable thing, or the list just has key elements that fit nicely and rely on the user to click to get at the rest of the info in some other activity/fragment

yeah, that's what i figured. i inherited this app so i'm trying to figure out how to make it more mobile friendly.

i need these rows/cards to be searchable/filterable and be able to be organized similar to how you would organize/alphabetize rows on a desktop app.

searching/filtering does not necessarily imply that everything that is search criteria has to be shown all the time

does your book discuss this at all? perhaps some sample code? i'd like to re-organize it the way you suggest but still be able to filter/search/organize. maybe that could be done by opening up an options fragment prior to display?

no, I focus mostly on the SDK, not on how to assemble various UI structures

true. i'm just trying to imagine how to do what you're suggesting.

ok.

the closest thing that I have is the ToDo sample app that is profiled in "Exploring Android" and "Android's Architecture Components"

"Exploring Android" is the long-term replacement for the tutorials in "The Busy Coder's Guide to Android Development"

in there, you build up a to-do list app

i'll start there. if you're aware of any apps out there that do what you suggest i could certainly take a look at them.

i guess gmail does that with the inbox.

um, well, lots

heh.

Will you continue to support both books or are you phasing out the busy coder's guide?

F-Droid

i must admit I really need to read through the latest version. i'm behind a few revs.

F-Droid, Play Store, any app with content, etc. tends to have search that transcends what is shown on the UI

That F-Droid app looks cool. I will have to check it out.

open source, so you can see how the sausage is made

anyway, about the books

is it frowned upon to take up space at the top of the screen with options other than a search bar?

I'm in the early days of basically rewriting everything, to blend in Kotlin, Jetpack, and the AndroidX edition of the support libraries

I don't know what "options" would entail

I have used a two-tier search panel, with the bottom half folding open to expose filtering options

well, right now we have column headers that you can click to sort them (i.e., alphabetically, etc.)

that's a very desktop-y approach

absolutely.

but, having a panel that you can fold open to expose controls for sorting/filtering, then collapse the panel afterwards, is reasonable

i'd like to remove all this "Win CE" style stuff. lol.

i'm leaning towards having a config button that will pop something up for all that stuff to save real estate for more results.

right. that's what i'm after. we do have a "hamburger menu" of sorts but it's not ideal. It's being used as a main menu.

and that's a fine role for a nav drawer

i need to work on navigation as well. we probably don't have a whole lot of time to discuss navigation but does your book talk about how to handle recreate state when your app requires a login?

I don't think so, though I'm not certain what "recreate state" means in this context

well, the developer before me doesn't save any state or anything. if you exit the app or navigate away from it you don't get to go back to where you left off.

it always goes back to the "home" screen.

if the user has been away for over 30 minutes, that's standard behavior

if you are seeing this for shorter periods away from the app, the app is doing something to trigger this behavior

yeah, the app is purposely constucted to do this. i have to undo it.

that's going to be fairly specific to your app, so I can't really help much with that

generally speaking, if I have data that i'm building up over several screens before sending it over to the server, where is the best place to store such temporary data while the app is in operation and then where is the best place to store it when the app is paused?

roughly speaking, there are three tiers of this sort of thing:

1. as objects in your app itself, for state that you don't mind losing when your process gets termianted

er, terminated

2. as values in the saved instance state bundle, if they are small and you'd like to ensure that you get them back for that 30-minute window

3. on disk somewhere, for anything that doesn't fit #1 or #2

#2 is what i would like to research further. i'm interested in keeping this data during that 30-minute window.

i am using azure data services to store to disk. it uses a sqlite db and then when syncs happen the data is sent to the cloud.

you would populate the Bundle that is passed to your onSaveInstanceState() method of your activity/fragment

okay, so if the user's token expired and a login had to occur such that i couldn't automatically resume to the page where they left off I could check for this bundle and read a flag that let me know what screen they were on and repopulate then.

yes

coolness.

Android would send the user to the activity that they had last been in -- you would determine that you need to authenticate, and so you would hold onto their last position somewhere, authenticate, then send them to where they need to go

i've been quite fortunate to get so much accomplished this office hour. i guess 7:30pm is ideal for east coast people.

:)

it also works for West Coast folks who are still at work

true. well, i guess i'm just lucky today then.

ahh, well, the rub is that i'm using an ms azure library that controls the authentication part.

I haven't used that, so I cannot really comment on how you would deal with your scenario in terms of it

this library opens a webview that ms azure uses to present a login web page. i get a token after that. so i figure i need to save some state in the bundle letting me know what activity they were on when the app exited.

possibly, though the bundle is more for cases when the user leaves your app for an extended period of time

authentication should be quick

so, you should be able to hold the navigation state somewhere in memory as your primary option

sure. i understand. what i mean is...the user could navigate away from the app for twenty minutes and his/her token could expire. i would hate for them to have to re-enter several screens of data.

another scenario i noticed is that the app is currently designed to always go to the home page even after bluetooth pairing, connecting to wifi, or other cases when the apps navigates away to somewhere else.

i will definitely look into the bundle stuff.

let's get ready to bundllllllllle!

how do i get a transcript of our conversation?

I post the chat transcripts to https://commonsware.com/office-hours/ shortly after the end of the chat

great thanks.

OK, that's a wrap for today's chat

thanks again.

the next chat is Thursday at 9am US Eastern

have a pleasant evening!

you, too.