Mar 9 | 3:55 PM |
Mark M. | has entered the room |
Mark M. | turned off guest access |
Mark M. | turned on guest access |
Suleyman O. | has entered the room |
Mark M. |
hello, Suleyman!
|
Mark M. |
how can I help you today?
|
Suleyman O. |
Hello Mark!
|
Suleyman O. |
I have a couple of stupid questions :)
|
Mark M. |
there are no stupid questions here
|
Mark M. |
stupid answers from me, well... :-)
|
Mar 9 | 4:00 PM |
Suleyman O. |
I'm on a later stage of my application and I am trying to provide different resources for different screen sizes. Because of the nature of my layouts, I'm more concerned with height than the width of the device, can I use only "smallest height" as the only resource qualifier? Or should I use "smallest width" anyways?
|
Mark M. |
there is no "smallest height" resource qualifier
|
Mark M. |
there is current height, current width, and smallest width
|
Suleyman O. |
oh, I may have gotten lost in the documentation. What about available height? Is that a good choice for me, or should I still go for the smallest width?
|
Mark M. |
sorry, I used "current" when I should have used "available" in my previous statement
|
Mark M. |
you are certainly welcome to use available height, and that is probably what you want here
|
Mark M. |
smallest width is the same regardless of whether the device is portrait or landscape, and it serves as a general "how big is this thing, anyway?" guide
|
Mark M. |
available height depends upon the actual orientation
|
Mark M. |
and the device is taller in portrait
|
Mar 9 | 4:05 PM |
Mark M. |
so if you are concerned that your layout will not fit or make appropriate use of the vertical space, you probably want to use the available-height resource set qualifier
|
Suleyman O. |
Got it, so then I guess I would have to use smallest height in portrait, and smallest width in landscape to achieve best results
|
Mark M. |
possibly -- it really depends on what you're doing with your layouts, and whether you really need to tailor for all those scenarios
|
Suleyman O. |
Yep, maybe I'm just overthinking it
|
Suleyman O. |
Will have to experiment and see
|
Suleyman O. |
Thanks Mark! I needed someone else's view on this problem, as I have been postponing this work for a long time :D
|
Mark M. |
happy to help!
|
Suleyman O. |
My second question is more opinion based
|
Mar 9 | 4:10 PM |
Suleyman O. |
I’ve been wanting to implement the blur effect in my application for a long time. I found a couple of libraries, but also discovered render script which achieves the same thing but obviously is a bit harder. My question is, what would you personally recommend? I tend to be very careful with external libraries.
|
Mark M. |
to be honest, I have no idea
|
Mark M. |
do you mean that you want to blur some JPEG image?
|
Mark M. |
(or PNG, WebP, etc.)
|
Suleyman O. |
I have a simple ConstraintView that hosts a couple of icons, and I want to blur the background of the ConstraintView
|
Mark M. |
OK, but where is the background coming from?
|
Suleyman O. |
As of now it's just a shape drawable
|
Mark M. |
um, OK
|
Mark M. |
personally, I would use a library, as RenderScript is not well documented
|
Mar 9 | 4:15 PM |
Mark M. |
but if you want to just look at a library, see how they do it, and roll your own, you could do that too
|
Mark M. |
there are a bunch of open source libraries for that task: https://android-arsenal.com/tag/176
|
Suleyman O. |
Yeah, you are right, I couldn't find a lot on RenderScript. And thanks a lot for the link! I think I'll try some of those libraries.
|
Suleyman O. |
I guess you have to rely more on external libraries, especially with Android
|
Mark M. |
it depends on what you are doing but, yes, on the whole, Google tries to keep the framework SDK relatively lean
|
Suleyman O. |
Do you find it frustrating sometimes? That sometimes seemingly simple things have to be manually implemented
|
Mark M. |
if by "manually implemented" you mean "use a library", that does not frustrate me
|
Mar 9 | 4:20 PM |
Mark M. |
if by "manually implemented" you mean "not provided in the Android SDK", the SDK is made up of two parts: the framework and Google-supplied libraries
|
Mark M. |
the problem with the framework is that it is baked into the firmware, and Android devices don't get many (or sometimes any) updates
|
Mark M. |
so libraries -- whether Google-supplied or independently-authored -- are better where possible, so you have consistent implementations across devices and can update them for bug fixes, etc.
|
Suleyman O. |
hmm, I see. That is true. I guess it's an advantage as well, since those libraries can be easily updated
|
Mark M. |
right
|
Suleyman O. |
Thank you very much for your time Mark
|
Mark M. |
you're welcome!
|
Suleyman O. |
And thanks for enduring my stupid talk :)
|
Suleyman O. |
Have a great day!
|
Mark M. |
neither of those questions were stupid!
|
Mark M. |
you too!
|
Mar 9 | 4:25 PM |
Suleyman O. |
Thank you :D See you!
|
Mar 9 | 4:40 PM |
Suleyman O. | has left the room |
Mar 9 | 4:55 PM |
Mark M. | turned off guest access |