After a relatively easy coast to simple app coding, I would like to understand better the intricate relationships between various conceptual components in Android.
More specifically, I would like to understand what is Runnable, Looper and Handler.
As you may noticed, the above 3 terms are links to formal documentation in http://developer.android.com so my question may seem strange, so let me explain: That documentation may be perfect for someone who already understands how things work in Android, but I need something that sequentially walks through fundamentals, building on top of previous concepts.
To summarize, I need some sort of tutorial on core inner building blocks of Android. Can you recommend one?
The detailed article Painless Threading is probably your best resource for threading on Android.
The moral of the story is that AsyncTask makes multithreading easier for you.
Runnable is a core Java interface - it represents a code part that can be run (usually by a specific thread).
Handler is an Android class that is responsible for posting a Runnable\Message so that a particular thread will run or process them (in a specific order).
Looper is the structure that holds the Runnable\Message queue that a HandlerThread will read from.
Related
I have an Android app made using Flutter.
Currently, most of the business logic runs on Android native Kotlin, but I love Dart so I am considering moving a lot of the logic to Flutter.
Is there any concern about converting Kotlin's coroutines to Dart's isolate?
There are no general concerns that I'm aware of. Although there are some points that you need to consider before doing the change.
The concurrency paradigm changes from multithread to single thread. This means that you should not think of changing coroutines to isolates, since you will not be using isolates so often or for the same purposes as coroutines.
Isolates are used for "extreme/unique" cases, if you want to perform a long running operation, you normally shouldn't opt out for an isolate, you should perform that with the simple async/await.
It's simpler to use async/await since you don't have to worry about resource allocations or race conditions, but at the same time it allows you to do "dirtier" things, to the responsability is on you.
Last thought on Isolates: they are a separate process so communication between isolates is only done through messages, so basic data should be passed between them and that could give you some headaches if you want to return some big data. (Of course everything is possible with serialization)
Hope this helps you to choose, if not, feel free to comment and we can discuss this further.
I am making a game in LibGDX. I have a GameScreen(screen) class where the main gameplay happens. I want use use multithreading so that user can do his/her own thing in the screen and computer does its own thing in the screen (changing the output of the screen at the same time). I have good knowledge of multithreading in java. But with graphics i'm confused. Any help will be appereciated.Thanks in advance.
You can use threading as per usual. Only thing you have to think of is that just as when working with swing only the graphics thread can do graphics operations so if your worker thread needs anything from graphics use the libgdx PostRunnable command.
Rather late but let me clarify something if I can.
Generally on LibGDX you have to be careful with threading.
Having said that, and if you decide you are not interested in html, you could start a thread normally and when you need to change something in the UI you should use Gdx.app.postRunnable() method
For code example and limitations, have a look here https://github.com/libgdx/libgdx/wiki/Threading
As per the page https://github.com/libgdx/libgdx/wiki/Threading , if you're hoping to create an HTML5 version of your game, then you won't be able to use traditional threads:-
JavaScript is inherently single-threaded. As such, threading is
impossible.
If I want to make a request from an Android device to a remote service, I can use AsyncTask, AsyncTaskLoader, Intent, etc to make the a request apart from the UI thread. It seems there are a lot of options, but I am confused how to choose among them. Could you explain when and which to use? Also, are there any other options besides the ones I have mentioned?
This is an extensively discussed question, since Android provides a long list of mechanisms capable to handle service calls asynchronously, besides the one you mentioned there's also:
IntentService
Native Threads
Now, the key point in your question is "When to use it" and here would be my answer:
In software the only golden rigid rule is the "It depends rule", there's no hard rules for anything in software development there's always different ways to approach a problem in software (i guess that's the reason of the word "soft" in it...) and that's exactly why it always depends, it depends on whatever you need and although one approach might be the most common way to do it like for example "AsyncTask" it doesn't mean at all that AsyncTaks is always the way to go, it always depends on the factors and needs that affect your functionality. There's plenty of things that nowdays get executed using AsyncTaks when maybe all you need could be just a regular common Native Thread.
The only way to be able to make a decision towards the most appropiate approach would be knowing ALL the features around a tool, like for example most people 90% of the time use AsyncTaks just to run doInbackGround on separate thread, but might not even need preExecute, publishProgress, postExecute, etc, and that's something a Regular Thread could do, just like this example there's features for every single object provided in order to do remote calls, however as i already mentioned several times, it all depends on what you need and what tool fits better your needs. Remember there's no hard coded rules for "How, When, and What" to use in software, IT ALL DEPENDS, and making good decisions in that "DEPENDS" makes the difference between good developers from excellent developers...
This is a list of things i usually take on count to implement either one way or another, this list do not apply for all the scenarios but might give you an idea.
AsyncTaks- I know is a good idea to make use of asynctaks when the functionality needs to be monitored, by monitored i mean, i need to keep track of progress during my job, like (download/task progress), because that's exactly what the AsyncTask was originally created for, it was created attached to "The Task Pattern", and if i don't need to make use of at least two methods for monitoring provided by AsyncTaks like onPreExecute,onProgressUpdate, onCancelled etc. I know there might be another way to implement it.
Native Java Threads - I know is good to make use of this tool when my task is not related to any view in android at all, and do not need to be monitored (example: removing/adding data from remote database, and the response might affect just persistence elements that will not be displayed like configuration preferences)
IntentService - When i want to do a one time task in a queueprocessor fashion way, but unliked a native thread, here i would like to have some application context in order to maybe bind an activity etc...
Regards!
I'm developing an app in which I pretend to invoke a REST service for typical CRUD operations. Since I want to separate the requests processing from the UI thread, I'm planning to use an AsyncTask to do the separate work. However, my question here is: how should I desing my AsyncTask(s) model? Should I use one AsyncTask for all CRUD operations (is this even feasible?), or use i.e. 4 AsyncTasks (create, delete, update, retrieve)?
Thanks in advance
I would go with a ContentProvider instead of using AsyncTask.
According to this thread:
https://groups.google.com/forum/?fromgroups#!topic/android-developers/8M0RTFfO7-M%5B1-25%5D
on Android 4 AsyncTasks will be sequential.
So, for that reason alone your solution may be less than optimal.
But, ContentProvider just makes more sense for what you are trying to do, as what happens behind the CRUD calls the user doesn't care. You may want to run this on a separate thread though, as being on the UI thread for too long is bad.
It is really up to you, and perhaps, the REST service which you are consuming.
Some things to consider:
Is the service general enough that it would be easy to do everything in a with a single AsyncTask?
Will your code be easier to read and understand if you do things with a single AsyncTask? I would tend to think that it would be easier to read if you did one AsyncTask for each operation. (ie, CreateTask, UpdateTask...)
Will I get the reusability that I am after with my choice (whatever it is)?
Personally, I would create 4 distinct AsyncTask's, and any reusable code I might put in a base class, but again, it is really up to you for what is going to work best for you.
Personally, I use the Loader framework, available with the compatibility library. I have a subclass of AsyncTaskLoader for each of the CRUD operations, and it works really well!
I guess if you prefer to avoid having lots of classes you could use the same task (i.e. the create and update could technically fit in the same task) - when you subclass your AsyncTaskLoader create a setParameters(...) method which you can call when you create the loader in onCreateLoader().
It might help to read the above after you've reviewed the Loader documentation.
i'm beginning to learn android, i meet a problem in my project,
in my application,i create a background thread which get data from remote server by UDP,
in this thread ,i will parse the data and distribute the message to different activity to process, so i don't know weather is there a mechanism to handle this problem.
thanks for your answer
You should take a look at this article about painless threading in android, and pick a solution that best fits for you.
If you retrieve data from the server repeatedly, maybe you should go with a Service - Handler solution, but AsyncTask seams to be the easiest for me.
I would recommend you to go through the dev guide as suggested by #UBM. Also, if you are looking for different threading constructs and communication, I would strongly recommend you to look at a series of articles on Android threading constructs starting with this article.