I am trying to develop a system that involves a:
server with a database that will handle the system's logic and manipulate data
an android app that will interact with that server (pull and push data into the server)
a website that will do the same as the android app, but from a website with slightly different data.
What I thought of is to use SQLite with Apache Tomcat installed on the server and deploy a Grails war file on it. That will take care of the 'website' side of the system. But what about the android app? Can it communicate with Tomcat as well?
Tomcat will suit your needs. I would look at hosting options though. Are you hosting your own server, or do you have a hosting provider? Do you have experience hosting a tomcat server etc. Do you have experience with java web applications, or other web frameworks? All of the above, and probably more should lead you to your decision on what type of framework/language to use on the server. This in turn will lead you to your options for hosting, and web-container to use.
Once that is determined all major web frameworks will allow you to publish web-services Rest, Soap, etc. that can be consumed by an android application.
Also, if you are planning on providing a web interface and service at the server level, my guess is you are going to be storing a fair amount of data, I would look into a more robust and scalable database such as mysql or postgres. This post contains some insights into this.
If you have an API that is web accessible, an Android can access it.
Android shouldn't have any problems communicating with Tomcat.
Look at http://grails.org/doc/latest/guide/13.%20Web%20Services.html for more information.
A RESTful web service is most likely what you'll need. Android can consume SOAP web services but it requires more work for less overall functionality.
Related
I am new to Android and taking the risk of doing a final year project of building an Android app. I would like to know whether I can create Client-server architecture application in Android. I'd like the front end to be the mobile app. Also, where do you store data (I don't know where to store data exactly) at back end.
Use Restful web Services with json(Ex: WCF in the backend with Sql Server)
For Mobile App, These are useful tutorials http://developer.android.com/training/index.html,
http://www.vogella.com/tutorials/android.html.
Very many, if not most, existing Android apps retrieve data over the Internet and display it (e.g. the StackExchange, Yelp, or Facebook apps). They are clients requesting data from servers and therefore fit into the definition of being “client/server”. I'm hard-pressed to think of an app on my phone that isn't a client to some kind of web service.
If, as your question suggests, you are using HTTP for client/server communication, there is no reason why the client platform (Android) should have any impact whatsoever on the server-side implementation. In the wild, Android clients are served by servers implemented with every conceivable combination of OS, language, and database. Therefore “where do you store data?” is an unanswerable question, as the answer depends entirely on implementation choices that you make on the server side.
I'm going to build application for web (asp.net mvc) and mobile (iOS and Android). And all three of them must communicate (share data, user authorization etc.) . What is best way to this ? Using asp.net web api or azure mobile services ?
EDIT
I was also wondering what was best practice for scenario like this: I have data base and business logic in one project which needs to communicate whit web and mobile using service. So which technology is best to develop this service Azure or web api or smth. else ?
Your question is very general.
ASP.NET Web API is just a framework to build RESTful web services which you can host everywhere. It does not help you with your task to "communicate (share data, user authorization etc.)".
Azure Mobile Services is an Azure hosted PaaS that actually provides everything you need and even more. It also provides you with ready-to-go RESTful web services that you might implement using ASP.NET Web API as well, but in addition to that it also provides support for federated identities, data sharing etc.
So, I would say since you seem to be somewhat new to this area, you should try Mobile Service, for they are very well documented and there is plenty of nice tutorials suitable for beginners, here is my favorite one.
You can also download a project template for Android and iOS after you have set up your own mobile service and just extend it. This is really a great help for beginners and hobby developers.
UPDATE:
Let's approach your question with some fictional scenarios for different solutions offered by Azure:
Azure Mobile Services cover the scenarios where you have multiple (mobile) devices running occasionally connected applications that need to synchronize their content through the cloud.
AMS provides you with the possibility to implement the custom processing logic for data requests and updates; it hides the burden of implementing and hosting a web service.
About 90% of the logic is set or written directly in the management portal, the rest is just the client logic.
The main purpose of this service is data sync (this is the core functionality), all other services (authentication, logging, scheduler) are just auxiliary.
The language used for development is JavaScript, the whole development is similar to server-side development using frameworks like Node.js.
Azure Web Sites is the way to host your code within IIS, that usually would be a web page, but nothing hinders you on hosting your web services (Web API based or even full-fledged WCF) here as well. Azure Web Sites are easy to deploy and this is a rather cheap solution for hosting web services, provided you allow other IIS applications (from other users) to run here as well (shared instance), but you can also prioritize your application by going for a reserved IIS instance (and pay more). Sure, you can reuse most (virtually all) of your existing business logic here (unless you need something exotic like interop or shell access that can't be hosted in IIS natively). The disadvantage of this solution is that your logic will run within the context of your web service and for long running processing this might be a non-optimal solution.
Azure Cloud Services allow you to defer the processing of logic rules and to decouple the logic from the service input. In this scenario you can have two kinds of roles, typically called web role and worker role. Web role provides endpoints for your services and queues the requests, the worker roles reads the queue and does processing. This allows you to fine tune your load balancing and capacity planning, increasing the number of parallel instances with web roles and worker roles.
I have a website and i need to make an app on android and iphone and the app has to communicate with the server,similar to facebook app.Do i need web services like SOAP for this.I read their documentation but how necessary are they and what is their main purpose? Can I do the same without using web services? my website is in codeigniter
If you need to implement web services for your app, I recommend taking a look at CodeIgniter Rest Server. This provides an easy way to implement REST web services, which are lighter weight, easier to work with, and more flexibile than SOAP.
Benefits of using a Web Service:
1 - Usability: You can develop Android and iOS apps, and both of them can use the same Web Service. Other smart phone platforms can also be developed later and use the same Web Service.
2 - Flexibility: For instance, you need to have a mechanism to talk with the database. You can implement the database transaction in your Web Service. (I have experience in using hibernate) You do not have to create a database configuration in every smart phone app. If you decide to change your database, then you just need to modify your database configuration in the Web Service - nothing changes on the client sides.
3 - Security: It is not a good mechanism to connect directly from a Mobile app to your database server. You need to have some kind of Authentication mechanism that can be provided by a Web Service.
Which kind of Web Service is better? I agree with #Justin that REST is a good approach since it is lighter, simpler to implement and more flexible.
SOAP can be a better approach when Security is the most important thing, for instance in certain enterprise scenarios. REST vs. SOAP
Are webservices necessary? Well the correct answer to your question is it depends on the app. Most apps that connect to a server to get some information use web services. However, no you don't need to write your own web services. Increasingly people are using platforms like agigee
http://apigee.com/about/products/usergrid/
So no you would not need to write your own api if you used usergrid, but you might want to if you wanted to keep the data all within your own infrastructure.
I intend to write a multi platform smartphone app (currently only I-phone and android).
Which has to send and recieve information from a web server I intend to create.
The web server will do all the algorithms, and handles also DB connection.
My question, is how is this best accomplished, which kind of web-server technology fit best the scenario, and supports connections from various devices.
Basically, I thought about implementing a simple TCP/IP protocol, making the app (on the phone) the client, and server on the web on the other side. however, I want to deploy the application to an application server (maybe google app, JBOSS, etc.) and I don't want to be stopped by various firewalls.
does anyone has an idea ?
edit: few things are certain, the application server will be written in java, and db will be mysql.
This is a very broad question and any suggestion about which backend technology to use will depend on your language preferences, your other requirements, etc.
For starters, I'd suggest JSON over HTTP as a transport mechanism: it's easy to parse on both client and server-side, and it's directly usable in Javascript should the need arise. XML is another choice, but it can be annoying to parse.
JSON-over-HTTP (or XML) will be completely device agnostic and won't have the firewall/proxy problems you'll run into trying to do a custom-implemented TCP-based protocol.
For the backend, may folks use MySQL or Postgres for their database, and connect to it from Java, C#, Ruby, PHP, or other server-side languages. Use what you're comfortable with or what you want to learn next.
Why not write the server-side as a regular web application - in whatever technology you like (php, asp.net, java)? This way you can deploy the app on any web server and your client apps on the phones would simply establish a connection to an HTTP server. Normally, firewalls would not be a problem in such situation.
I have used this setup for my apps (both android and iphone) - connecting to a web server app written in php with postgres back-end.
I'm planning on constructing a large application. It will have a browser based interface along with a mobile application interface (iOS, Android, blackberry).
I would like to be able to push data from the server onto these interfaces, and there will be a lot of data being sent from the mobile apps back to the server. So my question is what kind of server am I looking to build.
I'm a PHP developer mainly, though I can write in Java and have dabbled in others. I'm fine with learning a new language. My thoughts as a PHP developer is that I could just build a PHP application and use it's API to power the other interfaces.
However there will be a lot of data moving around and I don't feel like PHP would be the best base for this really. So I'm exploring alternatives. Any thoughts on where to start with this?
you can use a framework like Rhomobile's Rhodes that generates your browser based clients and they also offer a server component: http://rhomobile.com/products/rhosync/
Common practice would be to separate out the backend functionality between different servers.
Server 1: serve up your static content
Server 2: serve up your dynamically generated content (things based on queries that require IO such as DB interaction
Server 3: dedicated realtime infrastructure for the realtime push functionality
Server 1 & 2 could probably be the same server for now but I'd recommend having a dedicated realtime server. Communication between servers is normally done with some sort of message queue although web service calls are also an option.
My area of interest is realtime push so here's a bit more information on that. If you want to stick with PHP there's the phpwebsocket project. If you want to look at Java then there's [WaterSpout}(http://www.spoutserver.com/), jwebsocket and Jetty which has been around for a while and is (or was the last time I checked) used by the Twitter Streaming API.
There are more options for the realtime component of your solution on this Realtime technologies guide which I'm maintaining.