This is kind of a cross-disciplinary question. My technology choices are Python / Django and Android or iOS. If you can address these specifically great, but it's more a question of technique.
I want to return a number of small images (say, 10 at 10k each) over HTTP as a result of an API query. This will be consumed by a mobile app. I could just get return a list of IDs and get the mobile client to fetch each image individually, but I think the numbers are sufficient to warrant thinking about making this more efficient.
So option 1 is just get the client to pull each image individually. This would involve a separate network connection each time and is probably the simplest but worst way of doing it.
Option 1.1 might be to try and get the mobile client to make multiple HTTP requests on the same connection. I'm a bit hazy about that.
Option 2 might be to somehow return a multi-part response. This might be tricky to write a server and client for. Is there pre-existing Python server? How about Android and iOS client libraries?
Option 3 might be to zip the content. Having used the Python zip library myself, this wouldn't be my first choice (IIRC it only operates on 'real' files not file-like objects).
What's the best way to go?
Option 1 seems to be the best from a reliability standpoint. Especially since the amount of data you are sending over is very large (images).
Send 1 --> verify --> respond that it has succeeded/failed --> send second image.
repeat...
Also it is the easiest. Keep it simple!
Related
I want to create an Android/iOS tablet app that will visualize data from a number of desktop apps that have the same function (facilitating orienteering events) but may be very different in their construction. The idea I have is that when anything changes in the desktop server database, the change is communicated to my tablet app.
Now, I don't know what would be a good form of communication between the server and the app (JSON?), but I think that before anyone would want to consider modifying their desktop app to be able to share data with mine, my app needs to actually work.
So I'm looking to write my first line of code, but I think before I do that, I need to decide on a database. In the tablet app, the user would only be performing read operations. The data itself would be small (short strings and some ints/longs) and structured and work well with a relational DB. Assuming the server communicates all updates immediately, there could be an update on average every 5 seconds for a normal event.
Considering how you described the problem, the data doesn't seem too complex or big; This is more of a "what do you prefer to work with" instead of "what do you need".
JSON in this case is a good format for your data, and if you like working with it, then that's a good solution.
If you want to use JSON format, MongoDB might be the best choice. Easy to learn, big community, pretty advanced and complete.
First, please let me know if I should separate this question into one for iOS and one for Android. But I am working on both and was curious about this in a bigger picture sense, so thought I would ask this way. Here's the question:
Unlike on desktop, normally on mobile apps we try to minimize the number of network requests, and in my case I've been only making a single network request per view until now. But I have started wondering how performant it would be to make multiple concurrent network requests to different API endpoints simultaneously and then use those.
The reason I've started thinking about this approach is because I'm fetching a lot of data for the app, and wanted to split them up so that they can be maintained separately. I know web browsers do it (since that's how browsers work), but I was curious if anyone has experience building mobile apps this way.
Basically, whenever a view loads I would like to make multiple requests to different API endpoints (between 2 to 4) and use the combined result as I receive the result back from all of them, instead of a single huge result from a single endpoint.
Would this be performant enough? I'm using AFNetworking on iOS and OKHTTP on Android, if this helps.
It depends.
Suppose the overhead in bytes of each HTTP request is 100 bytes. This is a rough approximation; in practice the overhead varies with the HTTP headers (including cookies or authentication credentials), the URL (long query strings and paths aren’t free), the HTTP version (HTTP/2 has compressed headers) and other factors.
If you split a 1 MiB response into four 256 KiB responses, the 100-bytes-per-response overhead is completely negligible. It’s 0.03% more data.
But if you split a 100 byte response into four 25 byte responses, the per-overhead impact is dramatic. You’ll be transmitting 150% more data.
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 need to synchonize some data accross different phones. For example I want to enable "friends" to (automatically) share notes...
I'm now wondering what would be the best approch to reach this.
At the moment i think I'll have to write my own webservise to reach this goal.
As I started to think about a SOAP webservice I found lots of people saying that they would prpose a REST approach.
What would be the "better" solution in my case or are there any other approches for synchonizing data on different Android phones?
Maybe I should start by mentioning that REST is not a protocol and as such hard to compare to SOAP which is.
The main disadvantages with using SOAP for mobile applications are that it normally uses XML and thereby more data than most other protocols and that it's fairly complex both to set up and to maintain. On the other hand, if one party writes the server and one the client, SOAP gives you good ways to see to that changes are communicated clearly (ie WSDL). SOAP is generally not very well supported in mobile phones and may require third party libraries to make it work.
REST is often (mis)used as a name for HTTP based communication using JSON, which is a pretty easy way to communicate with mobile devices and has low overhead. If you have control over both server and client, it's not the wrong way to go (but not the only one either) JSON is generally very easy to get to work on all mobile platforms, and HTTP is well supported by the phones themselves.
It's better to use REST than SOAP because SOAP is very verbose and will increase the network data size.
Besides, if you use SOAP, you have to include external librairies (like kSOAP) to consume the response. With REST, a standard HTTP client is OK.
About data format: think about JSON that is less verbose than XML.
Concerning synchronization, I don't know if Android SDK provides classes to perform this work.
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.