This is not really a problem, more like a general X vs. Y question.
So I'm experimenting with c2dm on android using a server written in google app engine. At the moment I'm using the "App Engine Connected Android Project" as a template with some added code myself. So the generated code use RequestFactory for a bunch of stuff, like registering/unregistering devices, sending messages, etc.
My previous experiences with backend communication has existed of setting up a connection to a servlet, writing to it (json) and reading the response (json).
So here's the question:
What are the benefits (if any) with using the RequestFactory for communication with the app engine instead of just writing/reading from an URLConnection's input/outputstreams?
Or is it really just a matter of taste?
One disadvantage of request factory is that it is very slow in retrieving objects.. A custom servlet and http request are MUCH faster(10x-20x faster!).
Check out this post for more details RequestFactory slow on Android
I haven't used it myself yet, but the main benefit, as I understand it, is that it makes it really easy to authenticate against the App Engine app with your Android credentials. Doing that by hand is a bit of a pain.
Related
I'm developing an android app where I would like to fetch some data (mostly text) from the internet but not necesseraly from a website! I would like to have a server that allows clients to fetch some text data. What kind of server fits my goals the best? Http or maybe simply tcp? I don't know much about http so I don't know if it matches my goals and/or if it handles well a kind of text "database".
Edit:
A use case could be: people could write comments and send them to the server. Then clients could refresh their app by fetching new comments from the server. Therefore I'M asking what kind of server could best handle services and kind offre database if needed.
I like using NodeJS in combination with ExpressJS for such purposes. This combination allows you to easily work with HTTP/HTTTPS which is allowed by practically every firewall or proxy server. As of the latter reason I recommend you to use HTTP instead of an own protocol. Furhtermore, Java offers the HTTPURLConnection client which is very easy to use. Moreover, securing traffic with TLS (SSL) is very simple. In addition, NodeJS is resource efficient, runs on Windows, Linux and even on OS X.
For getting the text you can use HTTP GET request handled by the get() method of the Express instance.
This compact tutorial helped me to get familiar with Express on NodeJS.
Without knowing what your use-case is it's difficult to make a good recommendation.
With that said you may find something like https://parse.com/ suitable.
They provide an Android sdk and the 'getting started' tutorials will have you up and running in no time at all.
For a chat app, with extended features (not related to chat but realtime data) with support for Websocket and SocketIO based server, do I really need to integrate or consider XMPP. Isn't XMPP overkill for a simple file sharing (S3 storage), chat and other data communication (server status etc).
In my application, custom data is fetched from different storage, need to push to Message Queue in some event, and store uploaded file in S3. All these are not XMPP supported, So anyhow I will have to customize XMPP server implementations a lot if I choose it as backend.
Do you think I would be better off implementing all these by my own, compleletly skipping XMPP.
Or, is there anything in XMPP which I may have missed for considering it.
Support required in app:
Websocket
Long polling ajax
S3 storage
Redis / Aerospike DB
REST call to other services hosted on different machines
Android Client
iOS client
Windows client based on Qt
XMPP, formerly Jabber, is based on XML. I'm an old hand with XML, yet even I can see that it was chatty and redundant in creating open and close element tags, and also required a heck of a lot of open and close quotes.
What seems to be far more popular these days, especially in the NoSQL arena, are syntactically terser codifications of data such as JSON, or BSON (Binary JSON).
JSON: http://www.json.org/
Binary JSON: http://bsonspec.org/
Is there something specific in the schema, syntax, parsing or web-baed reification of XML which is a reason you want to use XMPP? Otherwise, you might find JSON an easier and more efficient way to encode data.
Also let me know if this answer was useful.
I've been reading some info about Web Services for Android using SOAP or REST but I've never created a web service so I have many questions about this.
I'm developing an Android App where the users answer some questions and for each user an XML file is generated and saved in the device.
Here are my queries:
What I would like to do is to send these XML files from the devices to the Web Service and also sometimes to retrieve all the files to any
device.
Do I need to convert these files into Byte or just send the XML?
Are these actions possible with the Web Service or will you use Java Sockets? In case you prefer the Web Service, what would you use:
REST, SOAP.
I would appreciate some links to tutorials and piece of advise.
Use SQL Server to manage the data on your desktop and create a web-service in .NET on Visual Studio.
Then connect to the web-service in your application and set/get data from the DB, using web-services. You can use either XML or JSON to transfer your data between the phone and the server.
There is no need for the use of Java Socket API for this.
Links which might be useful :
How to make a web-service in .NET (does not include the implementation in Android) : http://srikanthtechnologies.com/blog/dotnet/wsdaljava.aspx
How to connect your service with Android :
http://seesharpgears.blogspot.in/2010/11/basic-ksoap-android-tutorial.html
http://www.codeproject.com/Articles/304302/Calling-Asp-Net-Webservice-ASMX-From-an-Android-Ap
http://adrianandroid.blogspot.in/2012/05/access-c-net-web-service-in.html
Note: I have never worked on RESTful services. My work has always been on SOAP and hence it remains my preference.
Your final choice of how, exactly, to architect your app, is going to be based on all sorts of things that you haven't included in your questions: your experience, the experience of the other developers in the project, so on and so on.
I will say this, however. REST is deep in the heart of Android. If you decide to go with REST and, possibly, JSON instead of XML (there is, almost certainly, no reason to use byte arrays), you will find that Android's architecture supports you. SOAP and such and you are on your own.
The current solution that I have to adopt uses JDBC and stores the user/password of the database inside the android app. That's as far as I'm concerned not a good solution. I would like to implement a mapping layer on the webserver in the middle.
Is there any best practice or recommended strategy for this? Should I use SOAP or JSON or something completely different (because they're well implemented and/or easy to use in Java)?
Are there any mapping tools for postgresql <-> SOAP/JSON/whatever in PHP or will I need to write these scripts by myself?
Any pointers will be greatly appreciated.
Quick version:
Use a web service midlayer running on a public host you control (possibly but not necessarily the database host). Expose public web service methods to do the limited work you want to permit and nothing else.
Related questions:
Driver JDBC PostgreSQL with Android
How to connect to a PostgreSQL server via JDBC in Android?
Implementation options
Personally I'd use a Java application server like Apache Tomcat or JBoss AS 7 and I'd write my web service methods using JAX-RS to produce a nice REST-style API for my app to use. That's what I'm familiar with and it works well, but you have lots of options including implementations of:
REST-like APIs (Java's JAX-RS impls Jersey and RESTEasy, various other langs tools) that use HTTP requests and produce JSON or XML replies.
SOAP with WSDL, the classic "web service" layer. In Java done with JAX-WS among other options. Most languages have tools for SOAP+WSDL but it's kind of crappy to work with especially on intermittently connected devices like mobiles.
XML-RPC if you like pain
There are some JAX-RS quickstarts on the JBoss AS 7 quickstarts list; just search for "JAX-RS". The "kitchen sink" quickstart is useful, though perhaps not ideal if you're not familiar with the basics of JBoss AS 7 and Jave EE 6. Fort the JAX-RS specifics you're better off with a Jersey or RESTEasy tutorial like this or this.
Important considerations
Use HTTPs if possible, and if access isn't to be public use a suitable HTTP authentication scheme like HTTP Basic auth over HTTPs. Any decent web services implementation will offer authentication options or support those of the platform on which it runs. Avoid the temptation to implement your own authentication and user management at the web services layer, you will screw it up; use the auth at the HTTP layer that's already written and tested. This may require the use of something like Apache's mod_auth_pgsql, JBoss AS 7's JDBC security realms, etc. The only case I'd consider not doing proper per-user HTTP auth is where I don't need to separate my users for security reasons, I only care that it's my app accessing the server, ie if my security requirements are quite weak. In this case I'd use a fixed username/password for the whole app and possibly an X.509 client certificate if Android supports them.
Remember that no matter how you secure things, all credentials are either known to the user or can be extracted trivially from a .apk so you still have to assume anybody could access your web service methods, not just your app. Write them accordingly.
Do not just send SQL from your app over a web service call to the server and return the results as JSON. This is horrifyingly insecure, as well as ugly and clunky. Write a web service method for each individual task you want the app to be able to perform and keep the SQL in the server. Remember to use parameterised queries and be careful of other SQL injection risks. These web service methods may use one or more queries to produce a single reply - for example, you might collect a "Customer" record and all associated "Address" and "Contact" records then return the result in a nice JSON object the Android device can consume, saving numerous slow and unreliable network round trips.
No matter what you use, make sure to do your web service calls in a background worker thread and not to block the user interface. Be prepared for timeouts and errors, and for the need for retries. Test your app by simulating intermittent connection loss, high latency, and high rates of packet loss and make sure it remains usable.
Is there a best practise:
It depends on the person. All have their strength and weakness.
I prefer, and I think many but not all will agree on JSON cause it is really easy to use in Android. It's also lightweight and very easy to use in php. Php has methods to convert an array/object to json and back.
It is indeed not recommended to save your postgres data on an android device.
My strategy is usually:
PHP server side with a POSTGRESQL database, using PDO to communicate between my models and the database.
If you are not familiar with PDO(php data objects), I recommend you make yourself familiar with it.
php.net PDO
Android as client, using JSON as method of transfering data from and to.
There are many examples that can help you.
Android has standard libraries to handle json parsing.
See this answer for an example:
example
I am looking for reading resources or sample applications that can help me hammer out the following application workflow:
The client application establishes a connection to our server
The client application scans for updates on a regular interval
If an administrator has posted a new message, the new message is displayed in a widget.
I currently have 2 concerns:
I want to ensure that the monitoring service is not a major battery drain.
What is the most secure and simple method to establish the connection to retrieve data?
....There are a lot of suggestions out there... I need to know what method I should be researching over all others. Currently, all options are on the table because I have yet configure our server.
There are a lot of questions here, I'll try to give a succinct answer.
For the infrastructure I would go with HTTP REST calls to retrieve JSON data reprsenting your messages. Here is a decent link about writing an HTTP REST client for android, there are many others online.
For security, I would definitely start with SSL, but if you need to authenticate the requests I would also look at OAuth to secure you remote API.
As far as A, Have you considered using C2DM (aka "push") to trigger the updates? Then there's no client bandwidth beyond what is being used anyways for the Market/GMail/Talk connection. If you need to support Android versions below 2.2 it's not really an option at the moment, though.
Otherwise there's a few good examples of being a good citizen when polling from a widget; Jeff Sharkey's android-sky is probably the oldest, best, and most authoritative.
For B, unless I'm misunderstanding your need it's pretty hard to beat HTTPS; rolling your own "secure" transport over vanilla HTTP or anything lower-level is just asking for a disaster.