Office Hours — Today, October 26

← Yesterday, October 25

Oct 26
7:20 PM
Mark M.
has entered the room
7:25 PM
Mark M.
turned on guest access
Steve S.
has entered the room
Mark M.
hello, Steve!
how can I help you today?
Steve S.
Hi, Mark!
Another follow-up question on the progress indicators... Let me paste it in.
View paste 
You mentioned it would be preferable to replace the modal progress indicators I'm using with modeless ones. I'm trying to figure out how I could rework my app to do that.

One problem is that some child activities allow the user to initiate Rest requests that affect what's displayed and what can be done in their parent activities. Using a modal progress indicator prevents up-navigation until after the Rest operation has completed, so that what's displayed in the parent is accurate and no invalid operations can be carried out.

Could I instead use a modeless progress indicator and disable up-navigation? Or would I be replacing one bad design decision (using modal dialogs) with another (disabling up-navigation)?
Mark M.
off the cuff, I'd go with a modal dialog over disabling nav options that the user may be used to using
Steve S.
ok. then redesigning my app to get rid of the modal dialogs becomes harder.
Mark M.
even better would be to figure out how to allow the background updates while still allowing regular nav, though that's probably a lot more work
Steve S.
ok. here's one of the problems i see:
one activity has a list of contacts. you can click on a contact to get information about it and also to delete the contact. if the user deleted the contact (which triggers a rest request) and up-navigated back to the list of contacts, the list of contacts would be out of date.
Mark M.
why?
7:30 PM
Mark M.
you know the contact is being deleted
Steve S.
ok
Mark M.
so, get rid of the contact locally, at least provisionally
Steve S.
ok
Mark M.
in tandem, do the REST request to delete the contact "for realz"
if you get some sort of an error condition from that, add the contact back to the list
Steve S.
ok. so have a separate local list of contacts.
Mark M.
yes, at least to the level of an in-memory cache
a typical architecture is that you have a local disk representation of the model data, which your network I/O is synchronizig
er, synchronizing
Steve S.
ok
Mark M.
but, an on-disk copy is not essential, particularly depending on the nature of the app
Steve S.
ok
Mark M.
you see the same basic flow with a lot of Web apps nowadays: delete the item from the page, while updating the server in the background
if for some reason the server update fails, then have the user deal with the problem
but since success is typical, optimize the flow for the success case
7:35 PM
Steve S.
i was trying to avoid having to maintain a copy, but i guess that's what i need to do.
Mark M.
relatively few apps keep re-re-re-re-re-re-downloading the same data
whether the copy is purely an in-memory cache, or a local data store with a cache for optimization purposes, depends upon the app
Steve S.
can you point me to any examples i could base my redesign on (where i maintain a copy of back-end data)?
Mark M.
that's difficult to answer in the abstract
Steve S.
ok
Mark M.
it depends a lot on the nature of the data and the nature of the REST operations
my book is focused on tactical matters, and so I don't really have any examples there
Steve S.
sure
Mark M.
(though that may change in 2017)
the typical answer is the Google I/O app: https://github.com/google/iosched
for some reason, they don't seem to have released the source for the 2016 edition
and I don't know if the 2015 edition runs anymore
Steve S.
i'll check out the Google I/O app.
7:40 PM
Mark M.
and their app's usage is heavily tilted to reading, with little-to-no writing
most of the data changes are from server updates (e.g., additions to the schedule)
but, it may give you some ideas
Steve S.
great i'll check it out.
your book has been a tremendous help to me. but a lot of the things i have the most trouble with now are larger-scale, architectural issues. if you add some material about that in 2017, that would be fantastic.
Mark M.
the challenge, as I alluded to above, is that the right answer varies a lot by app
the Google I/O app will solve this problem a lot differently than will a brokerage client app
which will solve the problem a lot differently than will a social network client
which will solve the problem a lot differently than will a chat client
ad nauseum
Steve S.
sure, i understand
Mark M.
showing some examples of addressing these sorts of concerns may "fall out" of some other work that I am doing, but I'll be pointing out repeatedly that they are fine for some scenarios but are not silver bullets
7:45 PM
Steve S.
sure
ok. i know what i need to do now. i'll work on rethinking my architecture to maintain copies of back-end data.
thank you so much for the good help! no more questions today. have a good rest of the day.
Mark M.
you are very welcome, and have a pleasant evening (or other relevant day part depending on your locale!)
Steve S.
has left the room
7:55 PM
Romo
has entered the room
Mark M.
hello, Romo!
how can I help you today?
8:00 PM
Romo
Hi, was wondering if you could help me with this http://stackoverflow.com/questions/40273665/col...
Mark M.
I have not worked with CollapsingToolbarLayout
in a regular action bar, I would look to how SearchView is implemented
but, that's not a direct analogue to what you are seeking
and so I am not really in position to help on this one -- sorry!
Romo
That is fine thx for consideration
Romo
has left the room
8:30 PM
Mark M.
turned off guest access

← Yesterday, October 25

 

Office Hours

People in this transcript

  • Mark Murphy
  • Romo
  • Steve S