← Thursday, December 29, 2016 | Tuesday, January 3 →
Dec 30 | 7:25 PM |
Mark M. | has entered the room |
Mark M. | turned on guest access |
Dec 30 | 7:50 PM |
ndrocchietto_ivano | has entered the room |
Mark M. |
hello, Ivano!@
|
Mark M. |
(give or take a @)
|
Mark M. |
how can I help you today?
|
Dec 30 | 7:55 PM |
ndrocchietto_ivano |
ehy Mark to you and your secret Dragon Lair, as i read for the last transcriptions really nice discussion last time. Well I am still busy between testing, cool libraries and kotlin, but maybe you can help me on that. Android has context
|
ndrocchietto_ivano |
is correct to say that context in some way is useful way to pass the android logic in other classes?
|
Mark M. |
um
|
Mark M. |
a lot of software architects have serious issues with the whole Context thing
|
ndrocchietto_ivano |
I mean I pass into a contructor context and in this way I can split a class in more part calling some methods in one and others in another one to...
|
ndrocchietto_ivano |
not violate the single repsonsibility concept, the cohesion of the member variables with his methods
|
ndrocchietto_ivano |
in more pragmatic words
|
Mark M. |
if you are asking whether decomposing classes into separate ones is a good thing, then yes
|
Mark M. |
if anything, Context seriously violates the single responsibility concept
|
ndrocchietto_ivano |
i do not get
|
ndrocchietto_ivano |
Context is kinda of like Object in Java
|
Mark M. |
Android's Context is a great example of a "God object": https://en.wikipedia.org/wiki/God_object
|
ndrocchietto_ivano |
exactly
|
ndrocchietto_ivano |
great glad you agree with me
|
ndrocchietto_ivano |
I am really into MVP
|
Dec 30 | 8:00 PM |
Mark M. |
now, in Google's defense, the Android, Inc. team started work in this in the 2004-2005 timeframe, IIRC
|
ndrocchietto_ivano |
and I have a lot of doubt if I should divide for features the class
|
ndrocchietto_ivano |
packages*
|
Mark M. |
I cannot really answer that
|
ndrocchietto_ivano |
interesting so I should kind of follow Uncle Bob, trying to find as much as dependency injection possible
|
Mark M. |
all else being equal, smaller, more-focused classes are better than bigger ones
|
Mark M. |
however, all else is rarely equal
|
ndrocchietto_ivano |
to put on the center of the Bob ball pure and abstract java no android code
|
Mark M. |
having a pure-Java module in an Android project can be useful
|
ndrocchietto_ivano |
for junit testing
|
ndrocchietto_ivano |
and also all this use of interfaces
|
ndrocchietto_ivano |
sometimes it looks to me a bad idea to make communicate a presenter with a view by mean of an interface
|
ndrocchietto_ivano |
the code is less readable,
|
Mark M. |
my general rule is to use interfaces or abstract classes where there is a 1:N or M:N relationship between classes
|
ndrocchietto_ivano |
?
|
Mark M. |
I don't use interfaces just for the sake of having interfaces
|
ndrocchietto_ivano |
ah ah
|
Mark M. |
if there will be N implementations of the interface or abstract class, and so there is real polymorphism going on, then they're fine
|
ndrocchietto_ivano |
aaah i see
|
Mark M. |
one thing to bear in mind, though, is that a lot of Java advice is really aimed at server-side Java, where you have lots more heap space and such
|
Dec 30 | 8:05 PM |
ndrocchietto_ivano |
ah
|
ndrocchietto_ivano |
is undestandable
|
Mark M. |
sometimes, we have to make software architecture sacrifices to allow our apps to run acceptably well on low-end phones
|
ndrocchietto_ivano |
server should have more memory i guess
|
ndrocchietto_ivano |
is something i cannot catch
|
ndrocchietto_ivano |
what is the necessity to cover android 1
|
ndrocchietto_ivano |
in 2016
|
Mark M. |
if you mean the Android One line of phones, I do not know how well those sol
|
Mark M. |
er, sold
|
Mark M. |
however, there are plenty of other low-end Android phones that are not officially part of Android One
|
Mark M. |
particularly if you are distributing through more channels than the Play Store
|
ndrocchietto_ivano |
i mean android donut
|
ndrocchietto_ivano |
1.6
|
Mark M. |
oh, I haven't really considered 1.6 to be worth worrying about in a couple of years, at least
|
ndrocchietto_ivano |
i see
|
Mark M. |
again, it depends a bit on your distribution channels
|
ndrocchietto_ivano |
sure
|
Mark M. |
with the Play Store, we get good metrics, both overall (monthly device dashboards) and for your own apps
|
ndrocchietto_ivano |
true
|
Mark M. |
other channels might reach more people with seriously old phones, but we might not have the data to justify it
|
Mark M. |
but trying to get a modern Android app to support 1.6 would be *painful*
|
ndrocchietto_ivano |
definetely
|
ndrocchietto_ivano |
just think over memory exception, or animation not implemented
|
Dec 30 | 8:10 PM |
ndrocchietto_ivano |
anyay the second thing i cannot understand in the open source android community is over documentation, there are all these important libraries,
|
ndrocchietto_ivano |
that make testing easier and are the standard de facto today, but
|
ndrocchietto_ivano |
the second versions usually do not have documentation, enough documentation
|
ndrocchietto_ivano |
and the method names change a lot....
|
ndrocchietto_ivano |
so that become really difficult to use the second version of these libraries ( ex rxjava2) if you do not know well rxjava1 but
|
Mark M. |
I am not quite certain what your question is, sorry
|
ndrocchietto_ivano |
ok
|
Dec 30 | 8:30 PM |
ndrocchietto_ivano |
thanks Mark and have a nice evening
|
Mark M. |
you too!
|
Mark M. |
the next chat will be next year
|
Mark M. |
more specifically, Tuesday at 9am US Eastern
|
ndrocchietto_ivano |
have a nice year eve bye
|
ndrocchietto_ivano | has left the room |
Mark M. | turned off guest access |
Dec 30 | 8:50 PM |
Mark M. | has left the room |