I kinda know the pro and cons of each of these.
I'm currently developping a RSS feed list, and for that use an asynctask.
I came across a fellow android developer that advised me to use a service, because asyntask is stopped in case the app is in the background.
But then I came to realise the update of an RSS feed isn't that important, therefore why would I slow down my users by running a service ?
I know scheduled job might also help regarding the device performance but once again is it really essential to update the RSS ?
Note : The importance of the content isn't relevant. I just try to understand if I'm forgetting about some essential practice that would justify a service.
Bottom line : When it comes to a task to relative importance (such as updating RSS feed), is it worth it to run a service that might slow down the device ?
Can't we just use asynctask and admit it isn't critical if the app is put in the background ?
As far as practices go you don't seem to have any other option than using an AsyncTask or a service. But let's look at it from another perspective than the importance of the RSS feed at hand. The amount of data transferred is probably low in comparison to bandwidth available to your device. So maybe the probability of your app going to background before your AsyncTask can update the RSS feed is too small. You can also start the AsynTask in onResume(), to make sure that whenever your app comes to foreground your data is up to date, and then check for updates on RSS feed periodically while on foreground.
Sorry for long post but what I'm saying is that at the end the amount of resources you should use depends on you thoroughly studying your domain and your exact use case.
Related
I'm knee deep in this commercial game and currently working on the in-game chat. How I code the chat system depends on rather or not threading will work.
My question(s)....
Does anyone know for sure calling a thread on android or ios will result in a separate process and not hold up the app until complete?
This worries me because I came across another python user who was developing some form of app and they stated that their thread did not run as an individual and their app froze up until the thread completed. (which sucks because python is a cross-platform language)
What I wanna do is have a thread periodically fetch chat data from the server without causing the whole app to pause while doing so. This will allow for a more professional looking chat system and better user experience.
However, if for some reason python threads will not act as expected, I'll have to use a different logic for the chat system.
I'm sure some of you will probably be like, "just test it" but that's just it....I don't wanna (want to, lol) write all that code just to re-write it all over again if for some reason threading doesn't act right on a phone.
I'm not asking for code here....God knows I can code the hell out of an alien battle cruiser from planet Zars equipped with warp 7.5 engines.
If no one can give me a for sure answer then.... (sigh)...... I'll have to just write the code and cross my fingers in hopes of accurate threading behavior on phones for python programmers or be faced with the devastating task of re-writing a large chunk of code..... on the client and server side!
=====================Update as of July 14 2017==============================
I went ahead and wrote the code anyway. Turns out the Kivy API set has some back-end issue with creating Rectangle draw instructions in a python thread. This issue doesn't seem to be relevant when creating widgets from within a thread.
I did find a work around for the draw instruction issues and had things the way I pictured it all but in the end... I saw more cons than pros in the way I was planning my chat system and decided to re-write it anyway.
The new chat system is easier to work with and I don't have to implement code and fonts for multiple languages. (phew!)
So....looking at my original question now....
Yes,
Python threads will run on their own cpu cycle on an Android phone but what you're trying to accomplish depends on your entire setup...back-end and front end APIs.
I'm surprised to see people assume python can't thread when the language has the modules for threading.
Hell I run threaded processes separate from the main thread all the time on PC. In fact, I have this nice email app which can generate emails and send out ads/flyers and maintain a valid email database.
The app uses threading to update the UI system so the user of the app knows what's going on in the background. It's a marketing tool I plan on using later after I release the current app I'm designing now.
I might even release my marketing tool but such a high quality app wouldn't be cheap on the market. Not when marketing cost so much money. Being able to reach your target audience at little to no cost... Sounds too good to be true.
:)
I am working on an application that Looks similar to the Google Play App (swipe view with gridviews inside the fragments, in addition data in the gridview [image + text] is retrieved from a remote server).
My problem is with background tasks. I can’t decide what to use for retrieval of data from the internet. Mainly I am trying to decide whether to use AsyncTask or manual threading.
Of course it would be easier to implement AsyncTask, but after some research I noticed that many people find it limiting.
In my particular case, I want to download data from the internet as Json Objects, parse them and display the data in the gridview. The gridview would have up to 30 items, each item contains a thumbnail and 3 textviews. In Android documentation, they say that AsyncTask is suitable for short operations (few seconds at most). Would filling up to 30 items be considered as a short operation?
I want the data to be fetched concurrently. Also I want to support Android phones from API 8 and above. I read that for different APIs AsyncTask behaves differently (serially or concurrently)
My question is: Is it appropriate to use AsyncTask for my app? Or do I have to do everything manually? Is ThreadPoolExecutor a 3rd way to do this? Is it easier than manual threading?
Any advice would be appreciated, I can't move forward in the implementation without deciding on this issue.
Thanks in Advance!
My understanding is that the comment about using AsyncTasks only for short operations is aimed more at not expecting the same views to be available when a long operation finishes. For example, if a user leaves the app and comes back or the current activity goes away for some reason. Typical ways around this would be to use a Service and start up a plain old Thread there, then send some message telling the current Activity to refresh when the operation is done.
The download and processing of your data is likely to be the longest operation. So I'd use that as a basis for whether this is short or long. If you don't care about persisting data at all and don't mind restarting downloads if a user leaves and comes back, you can just use an AsyncTask with very little thought.
If you are using a GridView, you should only ever be populating enough views to for just over the number displayed on the screen at one time.
I'd say that AsyncTask is fine in your situation assuming it's a few kilobytes of data and not megabytes or hundreds of kilobytes. Megs of data, I'd say move to a Service with a Thread. Hundreds of k, is a toss up.
Also, take a look into Loaders... if you want to see an alternative that is better for this kind of loading.
When attending DroidCon in London last year, a presentation brought to my attention why using AsyncTasks for loading data from the network is unreliable.
This presentation was about the RoboSpice library.
The site also has a very nice infographic explaining why exactly AsyncTasks are unreliable and what RoboSpice does to amend these problems.
Disclaimer:
I am in no way affiliated with RoboSpice, nor have I ever tried it. I was just impressed and convinced by their presentation that it's a tool worth trying.
Friend, I am working in a project exactly as you need, and to support API 8 and above you should use Asynctask to download anything or you will get a crash for API 15 and above, because it won't even let you run your app without AsyncTask even for short operations.
So as I almost did everything that you need and it is working very well for API 9 above, you should use Asynctask, I´ve implemented SherlockActionbar, EndlessAdapter and ViewPager all with AsyncTask, so go on, if you need more help just ask again later.
I'am developing an application which is totally based on fetching data from web services.
In one activity I have to call almost 5 6 different web services which displays different information. This application is target v 2.3 to 4.x, as there are no network communication allowed on main ui thread so I am making 5 6 AsyncTask classes, because its post execute helps me a lot in displaying.
Now I am confused is this approach right or wrong, making 5 6 AsyncTask classes(can't reduce the number of web services or call in one AsyncTask because I have to check data again and again). Is this a good approach or should I change my pattern, and then switch to what approach.
Using this approach my application is working very nice and smooth on all devices.
I think that's a good pattern. It fits nicely into Object-Oriented design and each one performs it's own task.
If your web calls are all directly after each other, you could combine them into one huge AsyncTask if you really want to. That would definitely reduce the nice encapsulation you have now and would make it a lot harder for someone to maintain and debug down the line.
It sounds like what you have is good already, and if it's working well, why fix what's not broken.
I would assume that each ASyncTask class is an API request to the webservice, if so it is the right way of doing it. Any network operation should be done outside the UI thread.
There is also a better way of using ThreadPools to limit the number of Server requests you want to keep active at a time.
Currently I'm receiving a JSON from a server with updated information on a contact. Currently, I iterate through the JSON and do an update on my app on the phone, but for 2000 contacts, it takes up to 50 seconds(I used transactions too, b4 that it took 70 seconds). Is there a faster way to speed this up?
Well, just remember that it's 2,000 row updates, and on a handheld phone/tablet. It's not a high-powered server with an in-memory database. This stuff takes time. Unless you're doing something more than what you're saying, it doesn't sound like you're taking more steps than required (i.e. there's nothing to cut out in order to save time)
Often performance is just as much perception, as it is optimization. One way to deal with this reality is to simply return control of the UI to the user, making your app look snappy and responsive, while doing the contact updates in another thread in the background. That would give your app the appearance of being very fast, even though it still takes 50 seconds to complete all the updates.
Are you using Android's built-in JSON objects? If so, that may be the source of the performance problem. The first time I profiled my app, I was surprised to find that JSON parsing was causing the biggest performance hit (see also this post in the Android Developers Blog).
You should profile your code to find exactly what is taking the most processing power then perhaps you may be able to find a more efficient solution to your problem
Profiling on Android is done making a tracefile on view, then viewing it with Traceview.
See here for detailed information
i have a question. I'm developing an Android Application. Actually, i have a thread in background that makes request to an external API in order to get data when the users clicks in different parts of the app.
My doubt is if this "thread" would be better if i implemented it as a service instead of a Runnable class.
Thanks
The point of a service is that it can run while your app is not resident. If you only want the service to run while your app is open then a thread is the probably the best way to do it.
As i learned some days ago, using AsyncTasks is the preferred, painless way in android to do background tasks. Have a look here to get a good tutorial.
http://android-developers.blogspot.com/2009/05/painless-threading.html
bye
If your information can be used by any other application you could use a service or as they are called in Android, a Content Provider. This way you make the information available to all the applications on the phone. This is a great way of encouraging other developers to build their applications with the info that you've provided. This is just something that you should consider, if it's something strictly related to you're application you can go on with the thread just as CaseyB stated.