I've been talking with someone about the possibility of a iPhone development contract gig. All I really know at this point is that there is a company that wants to make an iPhone app that will hit their internal database. I'm not sure what the database type is( Oracle, MySQL, etc...).
I've wanted to know if the database type was Oracle or MySQL if there is a big learning curve for connecting to one of these across the internet?
If it's a real pain I may do more research before accepting the conract.
I would advise against directly accessing the database from the iPhone application.
Usually, you would create a web service which accesses the database, and then you consume that web service from the iPhone application.
Create a web service. This allows you to make the iphone app more of a thin client. Let the application push commands to the web service for processing and interaction with the database returning only the data needed by the app.
This option is better for the app, the database, and the customer's security.
You can easily perform the connection over the internet, the same way you would locally, but you are opening the database up to attacks if it will accept communication from any remote IP address. Typically you will just connect via a socket open to the server's remote IP address over the open port, MySQL's default port is 3306.
I would recommend against this sort of system in general unless there is some critical reason they want their internal database exposed to the world's hacker community.
What I am doing is creating a web service using Sinatra to access the online database.
Those answers from 2009 are mostly obsolete now.
http://ODBCrouter.com/ipad (new) has XCode client-side ODBC libraries, header files and multi-threaded Objective C objects that let your apps send SQL to server-side ODBC drivers and get back binary results! This reduces the need to stop and separately maintain SOAP/REST servers that can get pretty frightening anyway after a while maintaining it.
The XML schemes were okay for transferring static configurations to mobile devices "every once in a while", but XML was meant for infrequent inter-company type transfers in a "server environment" (with power cords, wired networks and air conditioning) and is definitely not efficient for frequent database queries coming in from n-copies of a mobile app. There are third-party JSON libraries that help things, but even with JSON, everything has to be encoded (and decoded) from the binary representation in the database to text representation on the server (only fine if it's going to be shown to the user in a web browser anyway, but not fine if the mobile app is going to translate it right back into binary so that it can perform calculations "behind the scenes" to what is going on with the user). Aside from the higher network overhead and battery power the mobile CPU will draw with XML and JSON, it will also make you buy more RAM and CPU power on the back-end server faster than just using an ODBC connection to the database.
Related
Need to understand something related to Citrix XenApp and XenDesktop.
If I install a software (e.g. Paint.NET) on Citrix Server and publish it via XenApp and XenDesktop to set of users. My understanding is below,
Users who are accessing published application as XenApp; is a thin client application.
users who are accessing using XenDesktop; is a thick client application.
Is my understanding is correct? I googled a lot but still couldn't get a proper answer. I am very new to this Citrix world.
Can someone please explain me in laymen language?
I'm not sure these categories can really be cleanly applied to Citrix. Let me just explain in a nutshell how it works and you can be the judge yourself which of the (if either) it should be.
I have a farm of Citrix servers that I deploy WPF to. The servers are basically just Windows machines, so I can browse for files, upload, interact with the local file system in any way. The app itself to the Citrix server just like it was a personal computer. Citrix technology basically just transmits a picture of whatever apps each user has open on the server(s). It does this by the user installing a client (web browser plug-in), and all that comes across the wire is the compressed graphics info. There is no discernible lag, so it's basically just like I'm working directly from the server. I can't copy objects directly to my laptop from these web servers, because the OS I'm on there isn't really the same OS (although can browse through the network to my laptop and copy it that way very quickly).
That is Xenapp. I assume XenDesktop is the same as what we call 'Remote Desktop, but double-check me on that. This is what I use to log into a computer in the office from my home and control it. It works very much like the above except that, instead of logging into a server , it's used to log into a desktop PC.
Both technologies just transmit a (compressed) image, and both allow you to send keystrokes and mouse movements so that it's like you're working directly on that machine. As I understand it, Citrix is one of the few games in town with this kind of technology, and last I heard, even MS licensed it from them.
The typical usage is to install fat client apps on a Citrix farm so that they then become web/browser accessible from outside the work place. The apps are published on a gateway web site with links to the individual apps (although you can also browse through the file system and open that way). The only thing the user needs to have installed to do this is the Citrix client to decipher the visual stream. The client is free and lightweight.
So basically, I would say Citrix technology allows for fat clients to be installed on the Citrix server and then accessed like thin clients.
There are a few key differences between Citrix deployment and the way typical web app works. One is that the user has to actually close the app out, not just their local web browser , otherwise the app stays running on the Citrix server. By default that doesn't typically happen because from the Portal, a particular app will be published, so that only that particular app pops up on click of the link (not a desktop or Windows Explorer). So when the close the 'picture' of it running in the browser, they do so by closing the 'X' on the app. But if they're crafty, they're can disconnect the client from the server and leave it running. That can be handy if ones need to some work that shutting downt the laptop would otherwise close out (long-running datawarehouse pulls, etc). Another difference is that speed and performance are pretty much the same no matter the location of the user(at least with XenaPP). Normally, if you have a Wide Area Network, and you say, deploy an ASP.NET web page on web server in City A, the user in City B 1000 miles away may have a bit of a lag, since the web app may have to query a database server, then spit out some Javascript, that then gets consumed and ran on the client. With Citrix Xenapp, everything is occurring on the server in City A. In Citry B, the user is just getting a compressed picture stream. For this reason, it's better to avoid too fancy graphics, because they waste bandwidth and usually get autocompressed to look weird anyhow. But assuming that is done and the farm doesn't suck, performance will be appreciably the same in India or the Philipines or the United States for the same app. Another difference is that the data is inherently Sandboxed, and there are is no URL unless you decide to put the app on a web server and then have users access it through Citrix (which I've seen done in companies with sensitive data using offshore vendors because of the Sandboxing and speed benefits). But if you do that, you have to open the web app from within the Citrix portal and then you can run the browser on that server (you can't just put a link to that web app from the web). Finally--and maybe this is just where I work--but the load balancing seems to work a little differently than with web servers. Users tend to get thrown on the same server if they already have another app open. That can be handy for copying files, etc, but also means less balance in the load for particular servers at times, so that you typically don't want the overall average load to go high (need more servers).
Hopefully that helps explain it and give you an idea. Citrix just sends a picture of the wire that you can use to remote-control a machine. I would say it's kind of "both" on the thick or thin client question. Typically it is used to deploy Winforms, WPF or other 'fat client' technologies, and is largely unnecessary for technologies that already allow for thin clients (web apps). But sometimes web apps are pushed through there also, for various reasons.
I'm developing an application for Windows Mobile 6.5 that needs to get and send data from a Postgres database within the network of the app.
I've googled it and read every page on the matter but haven't been able to find a solution.
The npgsql driver doesn't work on this sdk.
Much like for Android or iOS, I'd recommend that you build an intermediary web service that's provided by a server on the Internet that the phones talk to instead of talking directly to the database. The web service would accept REST+JSON, REST+XML, XML-RPC, SOAP, or whatever your preferred web service procotol is from the phone clients. It'd act on the requests from the phones, doing whatever is needed in the database to satisfy the request, and return any result via the web service protocol.
This means your individual phones don't need connections direct to PostgreSQL - a good thing, since phone network connections are flakey and the retry/re-establish logic can be hard to get right. You'd land up with lots of dangling connections to the Pg server. You're much better off with a stateless protocol like HTTP to talk to a web service that then does the real work.
Choose whatever web service protocol is easiest to work with on Windows Phone 6.5 and implement it using your preferred back-end server. In your case I imagine that's likely to be .NET on IIS.
Depending on the app, you might already have a web service protocol. If you have a modern web page version then it's fairly likely to use JavaScript with REST+JSON to call server endpoints, in which case you may just be able to extend and re-use those for the phone app.
My app reads data from two sources, a local sqlite file and a remote server which is a clone of the local db but with lots of pictures. I do not write to the server database, but I do need multiple simultaneous fetch operations.
What DBMS should I use for storing information on the server?
It needs to be very easily used from an iPhone app, be reliable, etc.
Talking to a remote server should not be tied to any platform like iOS. If you have control over the remote db server, the best bet IMO is crafting a RESTful API which you express your queries in, the server processes it and sends you the pictures/records using proper content type. If you do NOT have such control over the remote db, you'll have to stick to the API the db hoster provides. There are plenty such "on the cloud" db hosters (including NoSQL solutions) that give you a web-services interface to your db. MongoLabs is one such provider for MongoDB(which is a NOSQL db - meaning no schemas, no bounds on the structure of a "table"). You can continue to stick to SQLite on the client side.
You seem to have two sources of data local storage and a remote server.
This question on SO might help you to decide approaches of storing data on the server.
Once you have downloaded data using something like NSURLConnection class the images could be stored in the filesystem using writeToFile or the likes.
- (BOOL)writeToFile:(NSString *)path atomically:(BOOL)flag method.
You might like to save the rest of the data in sqlite. We used sqlite and the CoreData framework to save data for one of our applications and it worked fine for us. CoreData allowed us to interact with the database without actual SQL queries.
The iPhone client resides on the phone while on the server side we might have a database and a webservice interacting with the db. Webservice itself might be implemented in python or php like scripting language. The client interacts with the webservice that might return data in formats like XML or JSON. Thus there is no direct communication between the client and db. However, the client does implement network communication code to communicate with the webservice.
This page shows how to consume an XML based web service.
I am trying to make the sync data application in which user have some value into the data base .And he have to send this data on to the server .With help http request how can i do that .
I need the
I am not using the php web server .
I am using the Normal HTTP web page .
ANd i have the some data in my iphone application and i want to Synchronization that data to server .
I it must check the Internet is available or not .If the Internet is ON than only he will Synchronization the data .that's my question .
Nothing else .You got my point or not .
I thing people will reply me soon please
Thanks
You have got to have some kind of server backend for synchronization of the local database. You can't do that using just the static HTML pages.
Your application and server have to have a way to talk to each other using a web service protocol, like SOAP or JSON/REST. Then your application has to translate the data from the database into such web service data objects.
Both your local database and the server (in case of more than one client) will have keep the records of at least the times of last synchronizations so both know what should be sent over the air in order to become in sync.
Also, in the usual case of more than one client, you have to solve the problem of conflicts resolution.
Web service versioning is important as well, as there will be very likely a need to improve the communication channel, maybe there will be changes in the database model to be synchronized.
As you can see, the idea of synchronizing local database to a server is not that simple, and if you think you can do it in a simple way, in time you'll realise that you're gradually reimplementing the aforementioned ideas.
Do a research on web service technologies, writing web services-aware apps, on synchronization with web services and on Reachability, for starters.
To check internet availability, check out the Reachability class from Apple. See this article.
To send data to a simple HTTP form via POST use NSURLConnection like in this article.
Cheers,
S
How do I go about doing this?
You shouldn't.
Instead, you should make a web service that securely exposes the data you need.
(Do not write an ExecuteSQL method!)
If you really want to connect directly to SQL Server from an iPhone, you'll need to write a TDS client; it will involve a lot of work.
By exposing the data through a web service, you add a layer of abstraction between the database and the client app, allowing you to change the database without breaking the app.
Also, exposing SQL Server directly to the internet is never a good idea.
Finally, remember that port 1433 might be blocked at a firewall.