Office Hours Transcript: 2021-05-22
Scott joined
hello
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?
latter
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
oh
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
ok
I have the TabLayout in this AppBarLayout. Is this a bad approach?
I don’t know – I have not tried it
ok
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
let’s go back to https://material.io/components/tabs#anatomy
I’d like to move on to another question
sure
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
so does AndroidAsync: https://github.com/koush/AndroidAsync
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
anyway
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?!?
yeah
oh
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…
ready
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".
(sorry)
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
ok
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.
understood
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
agreed
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