I want to transfer data between a smart phone app and a website. What are the conventional and not-so-conventional ways of doing it?
Here's what I have thought of so far:
Simple HTTP GET/POST with data being represented as JSON array string, variations of this being encrypted/compressed string as parameter.
Webservice calls ( I am not sure if this is even possible, just a guess)
Two step communication : Smartphone to/fro Desktop App to/fro Website) (Cumbersome to develop/use)
Also, what do I need to consider to avoid spamming/snooping?
If your goals is convince, security and ease of development. I'd have the client (phone) make requests to the server over HTTPS using POST. The data sent should be what ever library is available for your target system. Good choices are URL Encoded parameters, XML and JSON. Avoid Binary protocols.
The downside of this approach is using network connectivity from a device to the web service may not be available or expensive, with the plan the user has. (this is becoming less so with the current wave of smart phones (iPhone/gPhone/Blackberry etc))
This is also a polling interface, so pushing data from the server to the handset is tricky and dependent on the User initiating some action.
Depending on the phone platform, you could also use SMS, for bi-directional communication. The limitation here is privacy, bandwidth and cost. SMS's are more expensive to send the ip data depending on user plan. (and sometimes to receive) The bi-directional trick is performed by registering a SMS hook in the phone application. Thus the application can be automatically started and notified when a certain SMS is received.
Please post additional information, like target platforms and I can discuss further options.
I think the first two are pretty much the same thing. What you want to do is an HTTP Post if you are sending a lot of data, or a GET with a query string if theres a smaller amount of data. It's all going to be unencrypted transmission, so keep that in mind when using HTTP.
If you're using the .NET Compact Framework and developing for Windows Mobile, the easiest approach is to use web services. However, .NET web services serialize everything as verbose XML, which makes the size of the data sent back and forth larger than it has to be. Using JSON is a good way of cutting down on the size of your data, even when using .NET web services (the trick is to send an entire JSON document as a single parameter). Minimizing the size of your transferred data is especially important for Smartphone applications, since your data transfer will probably be done over a cellular network.
Related
I am currently studying how to make cross-platform mobile apps (with xamarin forms), and I have heard that the "correct" way to connect to a database in a non-locale server (in my case located in Azure) is by using Rest Services (or rest APIs, or however is called), instead of connecting directly to the database with the server explorer option of VS like you would do in windows forms for example(using the SQL connection, dataset, etc. Which I think they are not necessary in the first case, I am not sure).
The only answer that I have received about this is that in mobile apps "They are not permanent connections. It connects, gives you data and disconnects. They are Asynchronous connections.", and that this is done "For optimization of connection resources. The mobile is suspended or the user passes the App to the background.".
But I still don't know if this is the actual reason, and if it is I don't understand how it optimizes the connection resources. So if someone has time to explain this I would appreciate it.
Thank you for your time, I hope I have explained myself correctly, and that you all have a great day.
As Jason said,the Security issues，with proper authorization having mediator is definitely much more secure than giving a user direct access to the database, because you restrict him to the end points which run only the queries you want to.And from the platform independence and maintenance,if the apps are developed in different languages and on different platforms,it may have benefit to create a common REST interface to allow sharing of data model, caching etc.For performance and scalability，that HTTP layer of your REST API provides another valuable caching mechanism. Your servers for your REST API can put caching headers on their responses, and these responses can be cached at the network layer, which scales exceptionally well.
you could read this link Why do people do REST API's instead of DBAL's?,I think the answers are pretty good
Say that I have to build a geolocalized app. What will happen is that:
thousands users will be using it at the same time
while the user will move around the city, will send his geo-location to the app. Then, based on that location, the app will send back an array of informations, update the screen and even, probably, a (google) map
So say, if there are 10000 users connected at the same time, all moving around, there will be really a lot of requests to the app, every second.
I'm doing a little research about the best tecnologies to implement, and I found that maybe using websockets would be a good choice. Is that true?
They say that websockets are good for:
Multiplayer online games
Chat applications
Live sports ticker
Realtime updating social streams
Are they ALSO good for the type of app I'd like to build?
WebSockets is only transport protocol and does not really solves the challenges you will face in development of your application.
First of all you need to decide if you are building Web app or Native app.
Then you need to consider scalability of your infrastructure in terms of concurrent connections as well as preparing responses - based on nearby locations (for example).
Few major questions you need to answer first:
How often geo-data will be sent.
How often updates of other locations should be updated on client-side
How you going to prevent cheating: If I send geo-location of airport while am in totally different place (as example).
On server side, how you are going to store locations data (mongodb has 2d indexing out of the box).
How you going to find nearest points, identify them and send to client?
Searching of nearby places - is expensive task, and requires a lot of optimizations like clustering of space, 2d indexing, etc.
Hello all I need your advice on this please.
Implementing an image database as a service vs giving access to the database directly in a client-server architecture.
Which one is the best taking security, performance and other factors into consideration.
Images and audio clips are better to be stored in a file system rather than a database. How do I make a call.
client---->web service---->database---->file system(which has images and audio)
Is above description a good way to make a call, or can any one suggest a better way.
Don't give clients direct access to your database. Provide a web service. This gives you increased flexibility to change your DB schema later, and improved control over your security.
I would store all of your resource information (file name, mime type, meta data, etc.) in the database and then build a web service that returns files when requested. This is a common way of doing things.
In addition, there is no need for the clients to know the file names or structures on your server. The clients can make a request to your web service, and the web service can return the file data directly.
Architecture :
database on a central server which contains a complex hierarchical database structure.
The clients should be able to insert data into tables through the API, The data would be inserted into multiple tables in the database at the same time, and not only into one table.
The clients should be able to retrieve data by using a complex search query.
The clients can upload/download files to the server which could have a size of multiple GBs
would SOAP be better for this job than REST ? can you please explain why ?
Almost all the things you mention are equally achievable using either SOAP or REST, though perhaps a little easier with SOAP. Certainly it's easier to create client APIs for SOAP interfaces; client tooling support is significantly more advanced on the majority of languages.
However, you say that you're wanting to deal with multi-gigabyte upload and download. That's a crucial point as REST is able to handle that sort of thing far more easily. SOAP is almost always tooled in terms of DOM processing, and that means building full messages in memory; you don't ever want to do that with a multi-GB payload.
So go with REST. That's definitely your best option for achieving all your listed objectives.
I am an Android developer. I haven't developed J2ME applications before. I have a requirement in which the client needs a J2ME application which requires me to store around 10,000 (Each record would have around 60-150 KB of data) records on the mobile phone. The mobile app will also be tied up with a backend server using a REST based web service.
The client wants the app to run on a specific mobile - Nokia 5233.
I need the correct options to proceed. Currently I am using the RMS and LWUIT. I chose them because:
RMS - I am using the CLDC profile. I am not aware of any DB that can be used with this configuration. Apache Derby is supported only in CDC.
LWUIT - There are many cases in the application where the TextField requires event listeners, the StringItem in LCDUI doesn't seem to have any event listeners.
Please enlighten me. I'm not sure whether I am taking the right direction.
RMS is probably your only decent option for on-device data persistence in J2ME (unless you go for direct file access using JSR-75, however if you aren't signed, the user will see all sorts of intrusive error popups when using this API). 10,000 records at 60KB per record, i.e. 614MB minimum? I've never heard of a MIDlet storing this size of data, RMS is intended really for a meg or two at most.
Why do you need to use J2ME? The 5233 is a Symbian^1 device, maybe try a native technology such as Qt? Probably far more reliable for that size of data, and easier to get a nice UI too.
(By the way, what events would you expect StringItem to give? It's a display-only widget.)