I have an issue in my current project.
I am currently making some GET requests to a restful API (and this works perfectly). But to be more user-friendly, I would like to optimize it in order to totally consume the bandwidth.
I tried to do it with threads with an ExecutorService which receives an ArrayList of CustomRunnable etc... using this tutorial.
But it doesn't seems to work because I use a Network speed calculator app which shows peaks when I want it to be constant.
Is it possible to consume totally the bandwidth ? If yes, is my method ok?
Please ask if you need information.
Related
My app is growing very fast, and we have used Parse.com as the main database.
We want to create a web version of this to work together with the app for iOS and Android.
The only limitation that we know from Parse.com is that the queries max limit is 1000, so after it you need to create a function to do more queries.
So talking about a very large database, performance on server-side, Users doing queries using 3g network and scalability, is a good way move it to mysql?
Not considering time and cost.
Only talking about performance, scalability and queries to work with Android, iOS and web.
Thank you
In terms of scalability I guess you really need to worry about that if you are managing your own servers. Worse case, you go with a professional hosting service but use VPS.
Parse uses mongoDB which is entirely different than MySQL. The 1000 limit should really be an issue regardless of what database you use because you should be structuring your app that you don't grab anywhere near 1000 items at once. That is where lazy loading comes into play.
Parse is a REST API. This means you're using HTTP requests to get information. You will need to write an API or find an open source option to put on your server. You need to make sure that your code runs efficiently so you can get results fast and put as little strain as possible on your servers.
Another thing is to try and prevent having 1000 queries. If there's a way where you can download data that can be reused in the app instead of re-downloading it each time then do it. Less strain on servers, quick response, and little data going back and forth.
That's really all I have to offer.
Not sure if this would help you, but I'm moving stuff out as well, but you are comparing two different databases to each other. I'm moving my data to Cassandra or MongoDB, that's because the data is key value. As for mysql, I hope you keep in mind, a lot of companies use it for large scale problems and they run it fine. I hope this helps.
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'm seeking more an advice on where to go next, rather than how to do it.
I'm developing an augmented reality Android game as a student project, and I've stumbled upon a problem. Four phones have to know each other's position and show it on a map with time steps (it should not be really realtime, for the sake of the game). Besides that, the players should be notified when one of the phones/players gets to some location, or does something.
I wanted to do it with a PHP service, where each phone would check in a couple of seconds for the positions of the rest (all by JSON), send it's position and that's it. Quite simple, but I'm afraid that there will be a lot of desynchronisation and unconsitent data as the game progresses. Since the phones don't start at the same second as everyone signs in. Also, I'm not sure how to do the events this way (for example, one of the players can cloak and his position should not be updated anymore in the next x seconds), or get to a location, or what items are still on the map (players can "pick up" items). Someone will know earlier than the others.
This really calls for a push-like solution, but I'm not really familiar with C2DM, and it seems to me that using it is a real overhead in development, and I need a C#/Java or similar server as PHP certanly can't push to the cloud (or can it?). I know C# and Java, but it takes more time as I need to solve threading and so on. Can C2DM even be used for this?
Basically, I'm seeking thoughts of more experienced developers, what is the best solution here for sync? Is there any way to remedy the problems with PHP and periodic checking the server or should I continue with the cloud service and a more complicated server?
Sorry for the long explanation :) .
Sorry that this isn't simpler but I've encountered pretty much the exact same problem in my own app and there is no way to avoid this, you need;
a server with a REST API to manage and distribute data
a way to set up friends / groups
a way to push data
Google Cloud Messaging really isn't that much trouble.
Check out the Google IO 2012 code, they've made use of it there with not much code.
http://code.google.com/p/iosched/source/browse/
What you really need to build is a rest api with quite a few functions for being able to identify devices and set up these groups of friends. I would suggest using Facebook integration for establishing a friend network.
https://developers.facebook.com/
And there are infinite ways to set up the REST API, but the fastest I've seen was released this year at google IO and thats Google AppEngine EndPoints.
http://devthots.blogspot.com/2012/07/building-awesome-android-apps-with.html
Give Comet a try, it's all about http requests
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.
Im writing up a business plan and im having some trouble with the finance part. I put an estimate on the cost of developers, web designers and everything but server costs. Im not a programmer so I dont know all the details. But how much would you think servers are going to cost for a complex app. I cant get into too many details but it keeps track of user preferences, stores data about the user and there is quite alot of back-end to it.
As i said in my response to your comment to #mark; this is a tough question as we don't know enough to make good predictions. To help you make your own predictions
As its only a business plan (i.e. not set in stone) think of a number of users that you want to run on a given piece of hardware - for the data / web servers.
Be aggressive but in the real world as the developers will have to code to make this target and make that part of the spec for the software - 200 concurrent users on a web server for example and that 10 web servers needs a dual core xeon database server or whatever the app needs.
Then you can plot a graph of expansion as it goes; they tend not to be linear so have a lying weasel factor to handle that that rolls the graph off as you go.
Then don't forget about backup, load balancers, firewalls, content managers, caching proxies and all the other network kit you will need.
You will also need to budget for someone to run it all... If its a web app probably 3 to handle it in shifts. Either that or make sure your IT people are the most dedicated so that the servers get restarted in the night when it all goes wrong.
Finally ... Does the system need DR? if so that will need to be included.
It really depends upon the complexity of the app, how much traffic you expect and what platform you need. The real cost is in the time managing the thing.
I would consider amazon aws (http://aws.amazon.com/ec2/pricing/). There's even a free level to get started.
They have system images prebuilt, free and purchasable, that might have the configuration you'll need. You can use one to build an image of your own and deploy it to many servers quite easily if your app takes off.
This heavily depends on the numbers of users that concurrently use your service and of course how much traffic you will have. Without more details it is not possible to estimate any costs.
Edit:
Possibly it is the best if you sit down with a developer, explain her/him what you want to do. There is a good calculation program from amazon webservices (cloud).
You can find it here: http://calculator.s3.amazonaws.com/calc5.html
For example if you would need 5 Linux CPU medium instances for one year + Load Balancers (they will spread the load to the instances) + Traffic (50000GB out + 500GB in) (per user out 1GB/month + in 100MB/month)
This would be all together a One-Time payment $2275 and monthly $7101
http://calculator.s3.amazonaws.com/calc5.html?key=calc-DE0DC116-63C1-440E-BE15-213263DC4E2B
But this is a too complex question to rely only on guesses. The advantage of Amazon AWS is, that you can grow with the application. Perhaps it would be the best to start small and see what you will need.
Take a look at the Dell, IBM or HP sites, say, and see if they quote rough figures. Compare with the cost for services like Amazon's EC2, or Microsoft's Azure. It's impossible to tell you what you need, without knowing what you're actually doing.