Office Hours — Today, September 1

← Wednesday, August 26

Sep 1
7:25 PM
Mark M.
has entered the room
Mark M.
turned on guest access
7:35 PM
Shobhit P.
has entered the room
Mark M.
hello, Shobhit!
Shobhit P.
View paste 
Hi Mark
Mark M.
how can I help you today?
Shobhit P.
Thanks for holing the session. I have a question regarding implementing MVP architecture for my android application.
7:40 PM
Mark M.
I have very little experience with the Model-View-Presenter pattern
that being said, I can try to answer your questions
Shobhit P.
View paste 
I’m trying to architect the android application in a way in which it is very decoupled, clean and easy to test as well. For that purpose I’m trying to use MVP architecture along with Event bus like Otto. Is there any disadvantage in using Event Bus like Otto for passing all events between REST client, UI and Presenters? I saw that you've talked about Otto in the book as well. However as far as I remember that's for communicating with Services. 

I read a good article here: http://saulmm.github.io/2015/02/02/A%20useful%20stack%20on%20android%20%231,%20architecture/
Mark M.
using an event bus should be fine between your REST access layer and your UI layer
I cannot comment on the relevance for presenters, as I have not attempted to use them on Android, other than cases where some library tries to use that pattern (such as leanback-v17)
Shobhit P.
okay cool. Thanks. This was just one of the things I was considering. According to you what's the best way of architecting a huge application? Is there a section in your book or any other book or an article that you would recommend for learning that?
Mark M.
by definition, a "huge application" could have any number of possible architectures
7:45 PM
Mark M.
a huge game would be written differently than a huge video player...
...which would be written differently than a huge accounting system client...
...which would be written differently than a huge scientific analysis app
and so on
Shobhit P.
I will try to be a bit specific in asking the question.
Mark M.
in general, the bigger it is, the less likely I am to be involved with it, and therefore I don't talk about it much
Shobhit P.
Lets say for example it is an app which has listing of houses and its details and people bid on them live. It would have multiple list views, detail views bidding systems, notification, multimedias etc.
"Huge" is a relative term so my use might not have been correct. Apologies
7:50 PM
Mark M.
my point wasn't so much the size as that different types of apps are, well, different
7:50 PM
Mark M.
I do not claim to be an architecture guy
but there's little doubt in my mind that games, video players, accounting system clients, and scientific analysis apps will have different architectures, at least to some degree
if you are going to ask "how do I architect this app", for the description that you typed in, I cannot really answer that
Shobhit P.
View paste 
I understand. It makes sense. I just thought I might get some tips. Thanks for the replies. 
I got the answer to my initial question. i.e If their is any disadvantage to using otto to communicate with REST and UI. I just thought it may effect the performance of the app in long run.
Mark M.
well, there's no question that an event bus will be slower than, say, a direct method call
however, that's not usually going to be a problem, as you are hopefully not firing off events very quickly
if you start doing hundreds of events per second, start worrying about it
7:55 PM
Mark M.
but the more typical pace for those sort of layer interactions tends to be measured in seconds-per-event, not events-per-second
in which case, the fact that the event bus adds some number of microseconds isn't going to be a big deal
Shobhit P.
Awesome. Thanks for the detailed explanation. It helps.
8:00 PM
Shobhit P.
I have one more question regarding lint checks. To keep code consistent, is it possible to add lint checks to check for example if the variable names are not starting with lower case letters or the bracket in front of "if conditions" is not in the new line etc. Do you know if that level of granularity can be achieved using lint checks?
Mark M.
I do not know, sorry
however, you also have options within your IDE (e.g., Android Studio/IntelliJ inspections)
or outside (e.g., Checkstyle)
I would assume that there is a recipe for checking coding standards like that, but I suspect that it will not involve the Android-specific Lint stuff
but rather it will be more general Java
8:05 PM
Shobhit P.
oh okay. So maybe I am looking at the wrong place. I'll look into Inspections. Thanks
8:10 PM
Shobhit P.
I was looking to use view Injection libraries like ButterKnife just to reduce the boilerplate code. I read at couple of places that view/dependency injection libraries may make the app slower? Is it true? I read a similar question on stackoverflow (http://stackoverflow.com/questions/28123652/do-...) but with no answers.
Mark M.
compile-time ones should not
and I think ButterKnife is done at compile time
that being said, I haven't played with ButterKnift
er, ButterKnife
also, it's similar to the event bus case, where the performance issue is really only a problem if you are doing a lot of it
so, for example, ListView/RecyclerView adapters would be a bit more sensitive to performance issues
but a compile-time annotation processor should result in code that is roughly as efficient as if you hand-rolled it, which is why I would be surprised if ButterKnife added much in the way of runtime overhead
8:20 PM
Shobhit P.
It makes sense. Thanks again for the wonderful insight. Can I ask something about the Automation testing?
*for Android app
Mark M.
go ahead
Shobhit P.
I was trying out MonkeyRunner by Google. However it seems that it works based on the pixel positions. But my concern is that if anything in UI changes, one would have to re-write the test cases, which would be a pain. Also for different devices with different screen sizes, not sure how that would work. Do you recommend any better tool using which I can use the element ID instead?
Mark M.
hold on
sorry, a phone call had come in
8:25 PM
Mark M.
UI Automation is probably more in line with what you're looking for
Shobhit P.
No problem Mark
Mark M.
or, Espresso for instrumentation testing
it's mostly a question of whether you are trying to test interactions between apps or not
Shobhit P.
No its just for testing within the app.
Mark M.
UI Automation is great for integration testing between apps, as you can automate any app, not just yours
Shobhit P.
oh okay.
Mark M.
then I'd be using instrumentation testing, whether directly with JUnit4 stuff or with Espresso layered atop it
(and, yes, I need to get the Espresso chapter in the book... :-)
all of that is part of the Testing Support Library nowadays: http://developer.android.com/tools/testing-supp...
Shobhit P.
Nice! I'll be looking forward to that. That's was a really helpful session Mark. I just want to say that i sincerely admire your work. It was couple of years back when my professor at UoFT introduced me to your book which got me interested into Android and I haven't looked back since then. Thanks for giving the Bible for Android Development.
Mark M.
I am happy to be useful!
8:30 PM
Mark M.
and that's a wrap for today's chat
the transcript will be posted to https://commonsware.com/office-hours/ shortly
the next chat is Tuesday at 9am US Eastern
have a pleasant day!
Shobhit P.
You too Mark.
Shobhit P.
has left the room
Mark M.
turned off guest access

← Wednesday, August 26

 

Office Hours

People in this transcript

  • Mark Murphy
  • Shobhit Puri