Office Hours — Today, May 28

Tuesday, May 26

May 28
8:20 AM
Mark M.
has entered the room
Mark M.
turned on guest access
8:30 AM
Urban
has entered the room
Urban
Hi Mark, nice to see you again! Thank you for coming here and helping us with coding :)
Mark M.
hello, Urban! I'm happy to help!
speaking of which... how can I help you today?
Urban
I have a few questions for you and I am hoping you could help me with these
Mark M.
I can try!
Urban
View paste
First question: I have been extensively using the same vector image in different sizes and colors. 
To achieve that, I was simply creating resource each time I needed unique size/color combination. 
However, I realised this is probably a lot of space "wasted" for the "same" image. 
On the other hand, I was doing some research and apparently it is quite CPU-intensive if you are modifying each vector in the layout itself.
That being said, I am wondering which is better approach: having single vector and resizing/recoloring it according to needs or having one vector for each needed configuration?
(sorry for paste things again, tried to prepare questions before so you wouldnt need to wait for me asking)
Mark M.
:-)
I have not done a performance analysis of your scenario, so I do not know which is better, sorry!
Urban
I understand. Just curious: which scenario of the two are you using?
Or is more accepted*
if you know that is
8:35 AM
Mark M.
IIRC, the few times I have done this, I have applied a tint at runtime
Urban
Okay, thank you for your help on this part!
View paste
Second question: same layout on different devices.
At first I thought that using same "dp" values automatically gives you same look on different devices but (obviously) I didnt' account that screen density and device size are also important factors to consider.
That being said, I was thinking of using "smallest-width" (SW) resources and defining layouts in these. 
Is this approach (using SW) approach you would have taken to achieve same layout on different devices or am I missing something?
Mark M.
for small variations in screen size -- such as different phone sizes -- usually I can get away with a single layout resource, with the right set of constraints in the ConstraintLayout
for large variations in screen size -- such as phones to tablets -- then -swNNNdp resources would come into play, as I probably need different actual structures to use the screen space
frankly, for a lot of the work that I do, I have to meet the requirements put forth by graphic designers, who often do not take these things into account
so, I do the best that I can with a single layout, and we just largely ignore tablets :-(
Urban
Thank you for that. So if I understood your correctly you are not using diferent layouts for different screen sizes? Because I have seen the need to change text or image size for smaller devices and even in different languages
Mark M.
in terms of text size, I use the autosize attributes
8:40 AM
Mark M.
in terms of image size, I either use percentage-based sizing or perhaps have different dimension resources based on -swNNNdp
ideally, you only have a different layout resource when the actual visual structure is different (e.g., switching from a single column to side-by-side presentation)
Urban
Thank you very much for that! So I believe I should be using more of these principles compared to having whole layout different. I havent heard of autosize before but I will definitely check that out! That being said, I believe that you are using different sw-dp configurations when you need as I suggested, correct?
Mark M.
if the visual structure changes, then yes, you need to have different layout resources
if the visual structure is the same, but things need different sizes, a single layout resource should suffice
Urban
Thank you very much for this!
View paste
Third question: constant variables in Kotlin.
What is the difference if I define const variable as top level (above class) or inside companion object in a class?
Because as far as I know the only difference is accessing these but recently I was woried defining them one way takes more resources compared to defining them the other way.
Mark M.
they should be fairly equivalent in terms of the size of the bytecode that the compiler generates
and they will be equivalent in terms of runtime memory consumption
8:45 AM
Mark M.
the companion object approach is more wordy, but it streamlines Java interoperability a bit (they are just static fields), and it provides a namespace for the constants
public top-level constants tend to pollute the namespace a bit
so, I tend to use private top-level constants for stuff I only need in the current file, and companion objects for public constants
but, I'm sure there are arguments for other patterns
Urban
thank you very much for that! I have been using the same principles as you but I was just thinking it might be difference in memory. Now that I know this is not the fact I believe I am fine using the same principles in the future
View paste
Next question is a little bit connected with SQL.
As suggested I have been using prepared sentances to manipulate my SQL base when dealing with user-input and "normal" setnaces when dealing with pre-defines things (such as resources, ...)
However, I have recently remembered that in rooted devices one has access to internal storage so theoretically one could temper these and by doing so inject things into my database.
Should I be woried for these and change everything in prepared statements or am I overreacting by thinking this?
Mark M.
runtime memory consumption is determined by what the object is, not how you reference it
if the device is rooted, it is "game over" -- whoever has the device can do whatever they want
prepared statements will not change that
Urban
I was reffering to online bases, not the SQLite ones
Sorry, I should make this more clear
I am using MySQL but the principlese should be the same for all of them
Mark M.
I guess I am confused then -- are you saying that you are using JDBC to talk directly to MySQL from your Android app?
8:50 AM
Urban
I am using PHP to manipulate MySQL databases I have on server somewhere.
Mark M.
but that PHP is also on the server, so your Android app is talking to the PHP-based Web service
right?
Urban
That is true. And I have been using prepared sentances to insert all user input and for pre-determined values from my resources non-prepared statements
Mark M.
but those prepared statements have to be "prepared" on the server
your Android app is making HTTPS requests, using some Web service API (e.g., something REST-like)
root privileges would not change that
and anything on the planet could make HTTPS requests of that Web service, if anyone cared to
Urban
I am sorry, I dont think I was clear enough. I was reffering to cases where one of the variables I have send to the server was obtained directly from my resources
So basically it is the value I wrote directly in the resources myself
Mark M.
that does not really matter much when it comes to Web services
I could make HTTPS requests of your Web service from this browser
so, if an attacker wants to attack your server, they do not need to go to the trouble of rooting a device and modifying your app
they just need to write a program that makes HTTPS requests
8:55 AM
Mark M.
and, if they want to know what values that your app already uses, they can monitor your network communications or decompile the app, neither of which require root
Urban
I see what you mean. So basically the best way would be always to use prepare statements for all variables I am dealing with on server side
just to be safe from these sorts of attacks
Mark M.
I am not a PHP/MySQL developer, so I cannot say for certain what the best practices are there
my guess is that what you are saying is correct
in general, you need to make sure that your Web service is safe from SQL injection attacks
Urban
which server language and database are you using, just of curiosity=
Mark M.
in many cases, I do not know -- some server team handles that, and I just use the Web service API
if it is my stuff, then I am tending to use Kotlin on the server
and most of my databases are small enough that SQLite suffices
Urban
Thank you very much for your help on this matter!
I have run out of my questions for today
Thank you sooo much for your help as always
Mark M.
you're welcome!
Urban
Thank you for doing this, stay safe and see you other time when I will be stuck with things :)
9:10 AM
Eugene S.
has entered the room
Eugene S.
Heeey, Mark!
Is there a proper way for re-launch previous activity, when it's on background of view? For example, activity A launches BottomDialog, which is actually Activity B and after that Activity B produce restarting activity A.
Mark M.
"which is actually Activity B" -- so the bottom sheet is an activity?
regardless, startActivity() with an Intent that has FLAG_ACTIVITY_REORDER_TO_FRONT is probably what you want
Eugene S.
yes, I think for discreetly reload previous activity, the current view should also be activity
9:15 AM
Mark M.
FLAG_ACTIVITY_REORDER_TO_FRONT will reuse an existing instance of the started activity and only create a new one if there is no such instance on the back stack of the current task
quoting the docs: "For example, consider a task consisting of four activities: A, B, C, D. If D calls startActivity() with an Intent that resolves to the component of activity B, then B will be brought to the front of the history stack, with this resulting order: A, C, D, B. "
Eugene S.
Okay. I'll go find out about this flag. Thanks!
Mark M.
so, startActivity(Intent(this, ActivityA::class.java)).addFlags(Intent.FLAG_ACTIVITY_REORDER_TO_FRONT)))
Eugene S.
got it!
9:20 AM
Urban
has left the room
9:30 AM
Mark M.
that's a wrap for today's chat
as usual, the transcript will appear on https://commonsware.com/office-hours/ shortly
the next chat is Saturday at 4pm US Eastern
have a pleasant day, and stay healthy!
Eugene S.
has left the room
Mark M.
turned off guest access

Tuesday, May 26

 

Office Hours

People in this transcript

  • Eugene Smykov
  • Mark Murphy
  • Urban