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.
Related
I'm trying to create a chat application and I need a little bit of guidance. I have a login system in place which is working. The user logs in/registers and everything is stored in a mysql database on the server.I know how to handle post requests and send stuff back.I have a recyclerView that can display the messages, but my problem is as follows:
Let's say I have 2 android devices: Android1 and Android2. Android1 sends a message to Android2. The message gets stored to the server. How do I tell the server to direct that message to Android2, and how do I make Android2 receive the message.
What if Android2 was offline at that time.Do I create some sort of response from the phone to tell the server that the message wasn t delivered so it can be sent again? And now how do I program the server to send the message again?
The messages table should be something like- senderId, receiverId, message; or what's the best way of designing it?
I found out about that I can do it either by using GCM, PHP and MYSQL from here http://www.androidhive.info/2016/02/android-push-notifications-using-gcm-php-mysql-realtime-chat-app-part-1/ and also that I can use XMPP. Which approach is best? I prefer the first one because I understand it and it's easy to implement. I have no idea what's happening with XMPP. I created a windows server using firebase, but can I still use my php one somehow ? And also the connection confuses me. I have facebook login implemented. Are there any good tutorials on the xmpp+android out there. I found some, but they are unclear.
Edit: Why is this question getting down votes? What's so wrong with it?
I had to face exactly the same situation as this sometime ago. What I have found in my researches was:
Use Telegram API: telegram is a well consolidate open source app for chat messages, it handles all aspects of it, including security and all the UI stuff. Its license, although, oblies you to make your code open as well;
Use Google Cloud Message Service: GCM allows you to send push to many devices using either REST or XMPP. Even if you're using GCM you'll have to implement a lot by yourself. In my humble opinion this is the best solution;
Implement a socket to connect the clients with the app server: this will required a whole lot of work, from sync to managing the power that your app consume, I wouldn't recommend you to follow this;
Understand the basics...
Extensible Messaging and Presence Protocol (XMPP):
Is a communications protocol for message-oriented middleware based on
XML (Extensible Markup Language).1 It enables the near-real-time
exchange of structured yet extensible data between any two or more
network entities
REST:
Is an architectural style consisting of a coordinated set of
architectural constraints applied to components, connectors, and data
elements, within a distributed hypermedia system. REST ignores the
details of component implementation and protocol syntax in order to
focus on the roles of components, the constraints upon their
interaction with other components, and their interpretation of
significant data elements.4 Through the application of REST
architectural constraints certain architectural properties are
induced: Performance, Scalability, Simplicity, Modifiability,
Visibility, Portability, and Reliability.4
From above we can understand that REST and XMPP are nothing more than protocols that you might end up using in order to pass your data through the components of your architecture. XMPP is the most optimized protocol for instant message communication, however, it is a bit more complex to implement. Fortunatelly, GCM support both protocols.
A possible architecture...
An instant message app is like any other client-server App. What is crucial to them is the need to notify the clients of updates that happen in the server. To do so, you need a proper way to communicate two clients. Usually this is made through a common app server. If you decide to go with GCM approach (my suggestion), you would have the following components:
GCM App Server: Responsible to manage the token generation and forward the received message to their targets;
Custom App Server: back end of the system implemented by you;
Client: web, android or iOS device that will receive push notifications;
It all starts when client opens the app, it will then make a call directly to GCM to request a token. Once it possess a token, the device should synchronize it with Custom App Server - so it knows everybody connected to the system and how to get to them. Custom app server maintain the token information in DB. When a device wants to send a message to another one, it will send a request to the custom app server which will, by its turn, retrieve the token of the target and forward the request to GCM App Server. It will then make a push to the target.
A Real Example...
As I said, I had to do a simmilar solution as I described above. The result of my work can be found in the following repositories:
Instachat Android: contains the source code for an App that uses GCM - it looks a lot like Whats App;
Instachat Core: a back end implemented using Spring Boot;
Both apps above were tested for a single one-to-one conversation using GCM and REST protocols, however, I'm still working on that and many bugs are present but the code can be used as a reference in order to understand the proposed architecture.
Hope I could help.
You can use GCM for sending and receiving messages.
You just need to send your messages to the receiving device through GCM, it will take care of it even if the receiving device is offline.
I used socket service for chat. so, I recommend you to use socket for
that. As compare to other, it will get quick response and all that you
want.
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.
i was trying to build an app which takes the data from server database and use it in android app ( in may case for reading the gprs coordinates available on database).
after a lot of search, i came across RESTfull services for implementing this. but there is a simpler way also, that is accessing the server database directly from android app by using a driver (jtds) and running mysql on server side.
i am actually confused which one to use. Why restful service which is highly platform independent and have a wide range or directly accessing the mysql database from server. which is most extensively used and why? giving below examples of both scenarios.
through restful service - http://avilyne.com/?p=105 and directly by accessing sql server database- http://amitku.wordpress.com/2011/08/03/how-to-connect-and-access-sql-database-server-from-android-app/
please let me know which is better and mostly used and why?
I would strongly encourage using the REST approach, and although there are many reasons, two or three come immediately to mind:
1.) Security. By using a REST approach, any data on the server side can only be accessed by server-side code, which can provide a protective layer between the data and the outside world.
2.) Scalability. A direct connection, such as the example at your link, hooks into a particular instance of a database. If that database already has a large number of connections, there will be performance issues or worse.
3.) Server side flexibility. If the underlying database structure or technology needs to change, a REST approach will allow for that. All the client side cares about is posting or requesting to a server that will respond via REST protocol.
I would think that a REST approach is much more widely used than a direct client-server approach.
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'm planning on writing an android app that can view and update data on a local network Oracle DB.
I have already written a python script which checks the oracle db every couple of minutes and writes out XML files which I then plan to parse through my android app to display the data.
As I mentioned though this will only work if the android device is part of the same network (either connected locally or through a vpn), and the XML will be stored on a Unix server.
The question is how to access that Unix server with the android app? Can I use FTP via an android app, or should I be looking to change the python script to send the XML to an easily retrievable location?
EDIT To clarify what you mean, you have a web service running on something like tomcat, the client sends a request to get the data from the oracle db (can also use some form of authentication), the web service responds and sends the data in a format (XML, JSON etc.), the client then sends a request back to the web service to change some data on the oracle db, and in turn it does the clients bidding?
Normally you would create a web service to provide data to mobile clients. There are several reasons for this:
Web services are accessed via HTTP/HTTPS which is a standard protocol and is guaranteed to work on all networks. Corporate wifi networks are especially notorious for locking down protocols except for web and email.
Web services compared to static XML files have an advantage of creating response on the fly. Which means that data will be current.
Web services can take some input parameters and create response based on this parameters.
Authentication: it is a common approach to implement username/passord authentication in the web service, especially if you serve some private data.
Update:
REST is a very popular type of web service. Look at some implementations in Python: Recommendations of Python REST (web services) framework?
This book helped me a lot: http://oreilly.com/catalog/9780596529260
REST is a way of designing your web service. Folks much more intelligent than you and me have divined that all of the work needed for something to work on the net can be handled through a combination of HTTP status codes, HTTP verbs like POST, GET, DELETE, PUT etc. and a clear hierarchy of resources (nouns). It sounds very limiting but it's quite beautiful when it all works together.
Have a look at the Facebook Open Graph API (developers.facebook.com) to get an idea of what a proper REST service looks like.