https://homeostasis.scs.carleton.ca/wiki/index.php?action=history&feed=atom&title=Mobile_Apps_2023W_Lecture_7 2026-05-12T22:12:29Z Revision history for this page on the wiki MediaWiki 1.42.1 https://homeostasis.scs.carleton.ca/wiki/index.php?title=Mobile_Apps_2023W_Lecture_7&diff=24334&oldid=prev 2023-02-02T03:21:44Z

<p>Created page with &quot;==Notes== &lt;pre&gt; Lecture 7 --------- For next time: doing HTTP requests &amp; getting responses, working with REST APIs in Android and Kotlin Today: Processes &amp; Threads in Android A process is a running program on UNIX/Linux (and Windows) - has its own share of memory and CPU resources - isolated from the rest of the system (cannot see the memory of other processes) The CPU runs a process for a while then switches to running other processes - the OS scheduler in the...&quot;</p> <p><b>New page</b></p><div>==Notes==<br /> <br /> &lt;pre&gt;<br /> Lecture 7<br /> ---------<br /> <br /> For next time: doing HTTP requests &amp; getting responses, working with REST APIs in Android and Kotlin<br /> <br /> Today: Processes &amp; Threads in Android<br /> <br /> A process is a running program on UNIX/Linux (and Windows)<br /> - has its own share of memory and CPU resources<br /> - isolated from the rest of the system (cannot see the memory of other processes)<br /> <br /> The CPU runs a process for a while then switches to running other processes<br /> - the OS scheduler in the kernel chooses which process to run next<br /> - a process can make a request that causes it to be paused (a system call)<br /> - or a process runs for too long and a timer goes off and it is interrupted<br /> <br /> A thread is part of a process, it is a CPU context<br /> - basically, the state associated with running the program<br /> - we can have just one thread, which is what we have with a standard sequential program<br /> - or we can have a multi-threaded process, with multiple CPU contexts<br /> (so logically it is doing more than one thing at the same time)<br /> <br /> So an app is running in at least one process, but an app can have multiple processes<br /> - and apps can even share processes in some situations (but they have to all<br /> be created by the same developer)<br /> <br /> In Android, there is the concept of a &quot;UI thread&quot;<br /> - so in the main app&#039;s process, the UI thread is the one interacting with the user, controlling the visible activities<br /> - you can have other threads, but they will be worker threads and may not manipulate the interface<br /> - they must send requests to the UI thread, it will then update the screen<br /> <br /> If you do time-intensive operations in the UI thread, the UI thread will block and so the interface will freeze until the operations finish<br /> <br /> So why not always put things in threads, why would we use separate processes for an activity, app, or background service?<br /> - threads share all memory<br /> - so if you&#039;re doing something dangerous or unsafe, or something that just should be separate, you want to do it in a separate process<br /> - processing user input is in general unsafe, so often good to segregate it<br /> <br /> Modern web browsers are multi-process precisely because of this<br /> - web page content isn&#039;t trusted, could be malicious, so is put into a separate process to keep it from messing with info in other tabs/windows<br /> <br /> See https://developer.android.com/guide/components/processes-and-threads<br /> for background<br /> <br /> Multithreaded programming in C is a real pain<br /> but it isn&#039;t so bad in Kotlin/Java, things stay separate in a nice way for the most part<br /> <br /> We really need to make our app concurrent so it can deal with a user, the network, storage (files, databases) and processing data all at the same while keeping the interface responsive<br /> &lt;/pre&gt;</div>

Soma