Jun 1 | 3:50 PM |
Mark M. | has entered the room |
Jun 1 | 3:55 PM |
Mark M. | turned on guest access |
Jun 1 | 4:10 PM |
Paul R. | has entered the room |
Paul R. |
Greetings.
|
Mark M. |
hello, Paul!
|
Mark M. |
how can I help you today?
|
Paul R. |
I have a quick question. In Exploring ... page 202, Step #5 there is a "dangling" } in the onSupportNavigateUp() method.
|
ansh s. | has entered the room |
Paul R. |
Is this in fact intentional or unintentional.
|
Mark M. |
that is unintentional -- I snipped the wrong lines
|
Mark M. |
(BTW, hello ansh -- I will be with you shortly!)
|
Mark M. |
there's an errata notice for this at https://commonsware.com/AndExplore/errata
|
ansh s. |
Hello everyone
|
Mark M. |
it should be fixed in Version 0.7, which hopefully will be released on Monday
|
Jun 1 | 4:15 PM |
Paul R. |
Ok then. That's all I have for now. But I'll hang out for a while.
|
Mark M. |
OK, if you come up with another question, let me know
|
Mark M. |
ansh: over to you! how can I help you today?
|
ansh s. |
View paste
|
Mark M. |
few APIs nowadays need a Handler, and Handler on its own is a fairly old and low-level bit of Android
|
ansh s. |
View paste
|
ansh s. |
View paste
(5 more lines)
|
ansh s. |
oh am sorry, i actually had all my doubt on clipboard, and i had to paste that one by one
|
Mark M. |
no problem
|
ansh s. |
is it all readable? i mean, i can see only a part of it here
|
Mark M. |
there is a "View paste" link above what you pasted that provides the entire block of text
|
Mark M. |
"Threads are just blocks of individual executable codes" -- more importantly, threads run in parallel, particularly on CPUs with multiple cores
|
Mark M. |
"The characterstic property of threads are that threads are completely independent of each other’s resources" -- no, that is incorrect
|
Jun 1 | 4:20 PM |
Mark M. |
"for eg if ui thread has buttons and stuff, then another thread can’t access those buttons or change some textview’s text" -- another thread *can* access those things, but may result in a crash, because Android only supports a single-threaded GUI and tries to prevent one thread's code from accessing views created on another thread
|
ansh s. |
oh okay
|
Mark M. |
"So the android uses handler and looper for ui thread" -- Handler and Looper and MessageQueue simply implement a message-processing loop. We have had those in GUIs for decades, at least back through Windows 3.1.
|
Mark M. |
"So, in Android terms, this handler becomes very significant as it can help achieve inter thread communication( even when threads are originally independent of each other)" -- a Handler is mostly used for communicating back to the main application thread, and even that is very low-level
|
Mark M. |
in other words, if in 2019 you are using a Handler, there are probably better solutions for whatever problem you are trying to solve
|
Mark M. |
*occasionally* we need a Handler to supply to some Android framework API (e.g., LocationManager), but that is relatively uncommon
|
ansh s. |
well I myself am tired of sticking my head in understanding handler... i just saw its use somewhere in a camera2 api code so i thought of giving it a look
|
Mark M. |
otherwise, your explanation is a reasonable starting point
|
Jun 1 | 4:25 PM |
ansh s. |
thankyou
|
Mark M. |
I sincerely hope that the new CameraX library does not force developers to use Handler :-)
|
Paul R. |
Is that CameraX library a JetPack library?
|
Mark M. |
yes, just released around the time of Google I|O
|
ansh s. |
i was somewhat unsure about the use of handlerThread class. By the way, is my assumption of handlerThread class being used to make an infinite running thread stands correct?
|
Paul R. |
Ah, ... I'm still assimilating Google I/O ... 2018.
|
Mark M. |
ansh: HandlerThread is a thread with a message loop, similar to the stuff powering the UI thread
|
Mark M. |
if you need a Handler for some API, and you want the callbacks to be called on a different thread than the main application thread, HandlerThread is a fine solution
|
Mark M. |
(given that I hope developers do not need to work with Handler much, so this will be infrequent)
|
Mark M. |
Paul: yeah, I haven't gotten to the CameraX presentation yet on YouTube
|
ansh s. |
"HandlerThread is a thread with a message loop, similar to the stuff powering the UI thread" yeah right, and this makes a thread infinitely running in backround until stopped, yes?
|
Mark M. |
yes, though you can do that with your own while(true) {} if you wanted
|
Mark M. |
a HandlerThread happens to run indefinitely, but that is not unique to HandlerThread
|
Jun 1 | 4:30 PM |
ansh s. |
yes i know!, that looper.getlooper() and looper.prepare() code , right?
|
Mark M. |
I think so -- it has been a while since I looked at these classes, so I forget the exact methods
|
ansh s. |
there are a lot of articles on this topic and everyone speaks differently, but all have one thing common : "this api is very rarely used and i have used it only about once or twice in my entire career"
|
Mark M. |
it was more important in the 2009-2014 timeframe
|
Mark M. |
and, for people creating things like the Android extensions to RxJava and Kotlin coroutines, Handler is still important
|
Mark M. |
similarly, LiveData and probably a few of the other Jetpack libraries use Handler
|
Jun 1 | 4:35 PM |
Mark M. |
but for modern app development, most people are using these other things layered on top of Handlers (RxJava, coroutines, LiveData, etc.)
|
Mark M. |
leastways, most people *should* be using those things
|
ansh s. |
yepp, and yet i find their usage in many other places like camera and media player apps :/ this class is so confusing, i wish it to get layered up completely and everywhere
|
ansh s. |
yes i know! i always use work managers, livedata and asynctasks
|
ansh s. |
i usually follow droidcon tutorials there was this droidcon sf 17 or 18 where this was being used in making a basic camera app. i think i can get back to it now.
|
ansh s. |
would probably be back here soon , camera 2 is a mess . hope you don't mind hehe
|
Mark M. |
I have not touched that API in a few years, and I barely understood it then, so I may not be of much help
|
Jun 1 | 4:40 PM |
Mark M. |
you might want to look at that new CameraX library and see if it fits your needs
|
ansh s. |
I have seen your name being appreciated in the readme of fotoapparet library. am sure you can handle me sir :D
|
Mark M. |
I appreciate the kind words, but that comment was based on work that I did a few years ago
|
ansh s. |
i will be looking into cameraX , but i thought of looking into current camera options since cameraX is in alpha stage as of now
|
Mark M. |
on the other hand, though, CameraX should be the long-term Google direction for a relatively simple camera API
|
Mark M. |
if you are trying to create a super-fancy camera app, you will need the Camera2 API
|
Mark M. |
for a basic camera app, I would use CameraX, Fotoapparat, CameraKit-Android, or something along those lines
|
Mark M. |
partly, because the Camera2 API is confusing
|
Mark M. |
partly, because there are lots of hardware-specific tweaks that you need to do to get somewhat consistent results
|
Mark M. |
that's why I gave up writing my own camera libraries (CWAC-Camera, CWAC-Cam2)
|
Jun 1 | 4:45 PM |
Mark M. |
my understanding is that CameraX, in particular, is going to try to handle those hardware-specific tweaks, so users of the library will get more reliable results
|
ansh s. |
currently am making nothing, just trying to dwelve deeper into basic android components so that if i got a job in some fancy social media company, i could be of use.
|
Mark M. |
ah
|
ansh s. |
i wonder how companies like snapchat and tiktok have overcome those limitations
|
Mark M. |
with large engineering staffs, lots of time, and the $$$ to have relationships with device manufacturers
|
ansh s. |
hehe
|
ansh s. |
i am sometimes confused if am utilising my time right. like you know, diving deeper into messed up stuff even though i could simply create a basic camera app using camerakit, publish in playstore and add fancy words in my resume
|
Jun 1 | 4:50 PM |
ansh s. |
sorry for turning the conversation a little informal
|
Mark M. |
I cannot really provide career advice
|
Mark M. |
from what I see in terms of hiring in the US, they do not hire so much based on "knows the Android Camera2 API", as they hire on "knows Android"
|
Mark M. |
that is based purely on public job listings and the like, and I am sure that in Silicon Valley there is a lot of private recruiting going on
|
Mark M. |
and some of that will be for camera experts, TensorFlow experts, and other specialities
|
Mark M. |
there is nothing wrong with learning the Camera2 API, if that is how you want to spend your time, of course
|
Jun 1 | 4:55 PM |
ansh s. |
haha thanks for your insights. well i don't know what would asked or not asked in the interview , i like doing android stuff, i want to build a custom camera app without using libraries, and i will make one , either with camera2 or cameraX
|
Mark M. |
(technically, CameraX is a library)
|
ansh s. |
oh sir you are pulling my leg XD
|
ansh s. |
okay *clearing* without using fotoapparet or camerakit
|
ansh s. |
I want to manipulate those bitstreams xD
|
Mark M. |
CameraX may have benefits over those libraries, partly because it is from Google and some firms prefer Google solutions over third-party solutions
|
Mark M. |
however, CameraX is layered atop of the Camera2 (and probably Camera) APIs, just like those third-party libraries are
|
Paul R. | has left the room |
Mark M. |
so, if you are looking to demonstrate expert-level camera knowledge, go for the Camera2 API
|
Mark M. |
if you are looking to demonstrate getting camera functionality working and that's it, use a library, as it will be less painful
|
Jun 1 | 5:00 PM |
ansh s. |
the last 2 lines made a lot sense, thanks
|
ansh s. |
i am done with my doubts, sir. thankyou for your time
|
Mark M. |
the transcript will be posted to https://commonsware.com/office-hours/ shortly
|
ansh s. | has left the room |
Mark M. | turned off guest access |