Office Hours Transcript: 2021-05-22

Scott joined


whoops – hello, Scott!


how can I help you today?

I’ve got an Activity using DrawerLayout. Its content is a viewpager with 3 fragments. navigating through the fragments is handled by a bottom nav bar.


navigating to other activities is handled in the nav drawer


one of the fragments needs to have a tabbed view that switches between 2 fragments.


I’m not sure how to add this tabbed view in.


I can’t figure out how to have each tier 1 fragment have its own toolbar layout, but keep the nav drawer connected to the Activity toolbar.


some examples of what I want are seen in Google Drive and Play Books apps

do you allow horizontal swiping between the three pages in your ViewPager, or is switching between them handled purely via the bottom nav bar?



I’m thinking that swiping would be enabled on the tab fragment though


Google Drive is the best example of what I want. It’s got all of the elements.

OK, particularly if you switch to ViewPager2, you probably can have that fragment host its own ViewPager2, using TabLayout for the tabs

I am using ViewPager2, and I currently have an implementation like this


the problem is, the tabs aren’t part of the toolbar

tabs-in-a-toolbar was dumped as a UI pattern several years ago


so I am not aware of any out-of-the-box implementations of that


it’s possible there is a library floating around for it, and you could try to roll something yourself


note that, by my interpretation of "toolbar", Drive has its tabs below the toolbar

right, that’s below the toolbar


if you are seeing a line or something between the toolbar and the tabs, and you want to get rid of that, try setting the elevation of the toolbar and the tabs to be the same

ok the way I have this setup in xml is an AppBarLayout that functions like a LinearLayout




I have the TabLayout in this AppBarLayout. Is this a bad approach?

I don’t know – I have not tried it


if it works and gives you what you want, it’s probably OK


once upon a time, back when Google was pushing tablets, they had a UI pattern that literally had tabs in the toolbar – basically to the right of "Shop" in that Material Design image you linked to


that did not work well on phones in portrait mode, and I forget off the top of my head what they were doing for that (drop-down to switch content, perhaps?)


so that’s what I was referring to when I said "tabs-in-a-toolbar was dumped as a UI pattern several years ago"


but in terms of the actual mechanics of doing what you see in that Material Design screenshot… I have not set up that particular UI structure, and so off the top of my head I do not know the best approach


I tend to be a bit of a caveman when it comes to complex app bars, so my default position is to have the tabs outside the app bar, but positioned beneath it


but, it’s entirely possible that having the tabs in the AppBarLayout, or something like that, is a better approach

I see. Well that’s where I run into problems because I don’t know how to link everything up appropriately if every fragment has its own AppBarLayout


are there other Tab patterns that don’t try to make the tabs look like they are a part of the toolbar?

I don’t know how to link everything up appropriately if every fragment has its own AppBarLayout

I thought only one fragment needed its own tabs

The bottom nav tabs are [Contacts, Favorites, Recents] for a phone app.


the Contacts fragment needs a [Personal, Team] switch to display different groups of contacts.

so, that fragment has a TabLayout at the top

that’s the goal


but it also needs the hamburger icon that opens the nav drawer attached to the Activity

tabs do not have a hamburger


and, you already have the hamburger

yeah. I’m not asking the right question

I’d like to move on to another question

I’ve only developed professionally for one app. Everything else I’ve done with Android has been simple little projects.


I’m curious about how other apps communicate with their back end.

well, there are lots of options

For us, we maintain a connection through a Socket object (I think). So, if the server has a message for us, it’s delivered over this socket.


new contact request, someone liked your post, incoming call, … that kind of stuff.

that’s certainly possible, or possibly handled similarly via websockets

is there a commonly used library for listening to events with websockets?

OkHttp supports websockets


and there are a few more out there

do any of these (that you know of) support custom protocols?

what do you mean by "custom protocols"?

we don’t use http for our communication. We defined our own protocol for communication

websockets are layered atop HTTP


so, it sounds like you’re using real low-level sockets


and implemented a custom protocol on top of them

yes that’s correct


we had a bunch of communication issues early on in our company’s history

that was a common approach a couple of decades ago, and still has its place in some scenarios, but we have a ton of higher-level options now

We eventually hired a couple of Java experts to bang out a library to handle this communication layer.


still using our custom protocol.


I don’t understand the decision to do a custom protocol. It has been a pain for me for many years.

the custom protocol approach would have been essential in the 1990’s


and into the early 2000’s


so, depending on when your firm got into this mess, it might have made sense at the time

I started working for this company in 2014, and we were using bazaar for version control


company started in 2011 I think.

yeah, that one didn’t win in the marketplace of ideas

it took a major effort to get our head engineer to agree to switch to git


I think using a custom protocol is somehow related.

well, version control usually is a purely internal matter



I’ve got 2 more questions. Biggest one is last.

go ahead!

is there a market for very short term Android contract work? Like 1 month max?

shorter than a month would be difficult if you are working directly with a solo developer


if you’re working with some firm, it’s not completely out of the question that they could provide you with somebody for shorter than a month, but that’s mostly going to be a matter of relationships – do they think you might come back for more work in the future, for example

I would be interested in the solo developer route

OK… are you asking as the hiring firm, or are you asking as being the solo developer (and providing short-term contract services to others)?

being the solo developer

ah, sorry, I was thinking in the reverse


I would say that sub-month contracts are infrequent – you’re starting to get into "gig economy" territory if you get too short

ok I’ll google that phrase later and dive into it


all right last question


This was my submission for a job application


I’d like to get your feedback on it in whatever capacity you can provide.


The project has been submitted already and I’ve been scheduled for a second interview.

the first thing that catches my eye: 47.7% shell? 13.9% Perl? those seem unusual in an Android project

yeah it was just the Android Studio wizard again


created a bunch of stuff


the hooks/ folder for example


I have no idea what that is

Studio did that?!?





maybe GitHub did it

yeah, that feels like maybe GitHub Actions or something

I created the project in GitHub first, then pulled down locally.


It was a real pain. I went the other way for my next application.

OK, here are some notes…


You went with Volley and the framework JSONObject. Both work. Neither are very popular, and both give off a vibe of "out of date developer".


yeah, I had submitted this before I asked you about it last week. We talked about OkHttp as the better choice.

for a REST-style API, I recommend that you try to pick up Retrofit for networking and either Moshi (ideal) or Gson (reasonable) for JSON parsing

I did use Gson in this project. Maybe I didn’t use it appropriately?

oh, I see – you used both


in RepoViewModel, you have a mix of JSONObject and Gson references


now, the JSONObject might be coming out of Volley – it has been years since I used it and I forget its API

I think that’s correct


I don’t recall doing anything specific to get a JSONObject

if you switch off Volley, that will get rid of JSONObject as a side effect, which is nice


Next… you do the networking directly in the viewmodel. That’s not out of the question, and for a toy app it’s reasonable. Doing that work in a repository singleton that the viewmodel talks to is probably a better pattern to demonstrate.


if nothing else, it adheres more to Google’s recommended architecture approach


IMHO, the objective of an interview project like this is to demonstrate that you can get the work done, and that you are likely to be able to adopt whatever stuff they already are using


that’s why I worry about the Volley choice, as it suggests that you’re "stuck in the mud" and might not be able to adapt easily to other stuff


the point isn’t necessarily to make all the right technical choices in the project, but to show that you


er, but to show that you’re "on the lead lap", so to speak, with how stuff gets done

Do you see anything that could be improved with the package structure?

eh, in a project like this, I don’t really worry too much about that


there are so many different approaches to code organization

makes sense

my other off-the-cuff concern is that you have limited error handling

I’ve only ever worked on one big Android project, and I inherited it. So, package structure is something I’m really not sure about.

I will be stunned if anyone judges you on your choice of package structure

That’s a good comment. I think I suck at error handling

back to errors… you catch exceptions when the API forces you, but then you log them and otherwise do nothing


so the user does not know that something went wrong

yeah. I knew this but decided it was better to spend the time on cleaning up the "everything works" experience.


given the same amount of time spent on the project, maybe I should have put a little more into error handling.


toss up a toast at least

right – the presentation of the error isn’t the big thing


it’s that you’re thinking of letting users know about the error


in a lot of firms, somebody else is going to be deciding what the error state looks like


your job will be to ensure that when something goes BOOM, that you render that error state


and demonstrating that is a nice thing – not essential, but nice



This was part of another project, but I ran across the fragment and Activity getting different instances of the viewmodel.

by default, they will

took me like 3 hours to figure out what was going on


all right that’s time. This was a great session for me. Thanks so much!

happy to help!

have a good day

you too!

Scott left