I'm quite new at using Monotouch and I want to make an app that can connect to my personal MySQL server at home.
I know how to do it in VS2010, but is it possible in MonoTouch?
It will be really helpful if you have a example.
First, I am not sure if you can access a MySQL database directly from Monotouch or not.
However, even if you could, unless you are just using the database on your home network, it probably isn't a very good idea to expose your database to the internet.
I would suggest creating a web service using Visual Studio that performs all of the database interaction. You can then just expose the functionality that you need through the web service and use that web service interface from Monotouch.
Although there will be a bit of a learning curve to start with, this will definitely be a better long term solution.
My solution is to host an small server at Amazon Cloud, where i have both my web service and an SQL server running. An bonus to that it's quit cheap. From my iPhone App im using WCF communication.
Related
I'm working on a project and I need to connect to MS Access Database. The problem is that I'm using a pretty new platform , I'm using Visual Studio 2015 Xamarin and I'm developing to android with c# (thought this platform).
I already have a project with this Database using aspx and i need to connect the android application to this Database .
I could not find any answer for it , probably cause it's new .
Thanks for helping.
The problem is not related only to Xamarin or MS Access.
Everytime you want to use the same database in different applications (in your case a website and mobile apps), it is better to create a new layer (WCF Service or REST API) in order to access the same database on the server. This is more flexible and would be the right thing in your case.
Without moving the architecture to the next Level, you will always have such problems when mixing old and new technologies together.
If you just want to finish this quickly for school and use the database only on the device, then there is no way to use the MS Access database with xamarin. I recommend using SQL lite for this and there are lots of examples for that:
https://developer.xamarin.com/recipes/android/data/databases/sqlite/
It not clear if the database is to run “local” on the android, or you just wishing to connect to some web service that holds the database?
If you needing a local database to run 100% stand-alone on the Android device, then Access is not supported. Your best bet for a local database would thus be SQLite.
Perhaps you don’t need nor want a local data store. In this case if the Access database is on the server, then you would be forced to write some kind of web service to “interact” with your Android software and the web server (this would not be a "general" interface to the database, but a set of web services that you expose on the web site - this assumes you thus have control and are able to write software and implement a web service on the web site. So in this case some kind of “direct” connection to the Access database is not possible.
You could again certainly DIRECTLY connect to a server based database like SQL server – but this would assume the web hosting allows external ODBC connections to the database (often they don’t allow this, but some do).
So not clear is if you need a local database running on the Android that can THEN connect to some web or server based system, or you simply want the android to connect via the internet to some database hosted on some server and the Android device does not have a local database at all.
Regardless of the location of MSAccess, you cannot "connect" to a non server database like Access. So the question remains as to "where" you want this database to be used, and ALSO if you need a local data store on the Android device or not.
I'm pretty new in developing pc and mobile applications that need to work with the same database.
Maybe this isn't really a question but I would be happy to get some advice from you.
I have now a vs project written in C# with a Service-Based Database. I want to create a mobile app (can be only for android) and I want both the apps to use the same database.
What options do I have? Windows Azure isn't free and I can't spend any money on this so even a small trial (limitless) will work here.
I was thinking using Parse..
What do you recommend?
If I understand correctly I would suggest you create some backend service - web service or web api - that both application use which in turn uses the database.
This will allow you to re-use business logic across both applications, abstract the database away so that you can make database and logic changes without having to redeploy the applications and avoid the requirement to deploy database credentials with your applications (the backend service should employ some form of authentication)
A free-tier Azure mobile services can really help with the mobile device end but not necessarily on the PC (unless windows store app), but a free-tier Azure websites instance will happily host either web service or web api
I have a project assignment from the university and want to ask you if you can show me the right approach. I'm not asking for any code or to write me something. I just want some guidelines to follow.
Firstly, to explain a bit.. I have to design and implement an Info System in .NET. It should have a Desktop App (based on Windows Forms), a Mobile App (Windows Phone 7.1) and a database (MS SQL). The idea is to have a database, hosted on a remote machine. The desktop and mobile apps should be able to connect to that database and do some stuff with it (mobile app will be only for viewing data, not modifying). The system must be multi-client - the database should be able to be accessed from multiple desktop and mobile clients at a time.
I'm ready with the GUI and it's time to do some real work. What's the easiest way to get that communication done? I thought of a WCF Service Application, which will provide the clients' access to the DB. My idea is to have the database and the service on a machine with a public IP address. The apps (desktop and mobile) will connect to that machine and respectively to the SQL through the WCF.
I saw some tutorials around, but didn't find one that shows how to make that WCF Service work with both Windows Forms app and Windows Phone app. I'm not very familiar with WCF - should I have IIS to run the service? I'm also not sure what kind of techniques I have to use on the client side to do the connection...
Is this approach rght? Can this be done in the way I explained? What should I be aware of? I will appreciate every kind of advise and reproach.
The easiest (and in your case, most efficient) way would be to use Windows Azure. For the purpose of your project, you can always sign up for the free trial.
Specifically, you can leverage Windows Azure SQL Database. Or, if you are so inclined, you could use Mobile Services, which also relies on SQL databases but you will have a much better time setting it up in your Windows Phone app (doesn't matter whether you want to read or write data).
I want to build some sort of interface that will monitor our real time routing/switching system. I would like to give a lot of visual feedback to be able to monitor its status visually. Our system and clients are not co-located so they would need to connect via TCP/IP.
I would like to be able to service any number of monitoring clients (although this will probably only ever be about 4-6 clients). I thought of using SilverLight but there appears to be one or two tricks involved in getting SilverLight to connect back to an application running on a different port.
I have also thought of using HTML5 canvas and websockets. Another alternative is to just create the clients using normal Window Forms and perhaps WPF. But this means that to monitor the application the client will have to be downloaded before. I would prefer something that is as easily accessible as web app?
What are some of the more common application stacks to achieve this? What should I watch out for?
EDIT:
Just to add: This will be an internal tool only. But we have offices in a couple of locations.
any choice in this direction could be subjective and arguable, surely somebody could suggest any possible web framework or language...
I would consider, however because of your .NET and C# tags, ASP.NET MVC 3, so basically web based plugin-less ( NO Silverlight ) HTML 5 solution.
Consider that StackOverflow is done in same way (MVC, ASP.NET, SQL Server... ) and outperforms as we all know.
the way you grab the underlying events from TCP, so the way you capture and provide the data from TCP, it's another thing from the front end, I would probably write a Windows Service if the traffic is so high and you want to grab and store data anything regardless any active client connection.
There are plenty of real time charting controls out there also for MVC, MS Chart Control. DevExpress, ExtJS integrated ones...
"real time" and Browser is bothering me.
I would indeed go WPF or WinForms. Using the ClickOnce-Deployment you can make this a no-pain for the user and you can roll-out new versions just by redeploying them and having the user restart the application.
In my company this works really fine and we have no problems whatsoever. The only problem with this is, that the app.config is somewhat hard to find and keep current/valid (redeploy) but in your case this won't change per client (or so I guess).
I agree with #Davide - I would go for a WebService that will obtain all routing/switching data in realtime. You will have a web application and on the client side you will have JQuery/AJAX fetching realtime data from the WebService component.
I've seen cool demo's of Web Orb doing something similar to what you want. http://www.themidnightcoders.com/
If you are starting from scratch, it would be good to check out WCF (Windows Communication Foundation). It's great because it can expose your functionality in many ways, using nothing more than modifying a config file.
If you want a Windows client app, you can host it in a Windows Service, or simply include it as a side assembly. For web apps, you can choose between various formats (JSON, XML), channels (HTTP, TCP) and protocols (SOAP, ODP).
If I got it right, there will be a server-side application which will collect information from the devices and expose it to clients as a service. In that case, a WCF application might be hosted in a Windows Service or IIS on a server machine, and expose the data though one or more endpoints (HTTP, TCP).
I am not aware of problems in connecting a SilverLight app to a service, but I would rather go for a HTML5/JavaScript combo instead, for easier deploying and compatibility with a wider range of devices (no plugins needed). ASP.NET MVC should be the best choice for the web app.
I'm a desktop application developer who is temporarily working in the web. I'm working with a client that wants me to build an app for use by locations all over the state; however, these locations have very shaky connectivity.
They really want a centralized web app and are suggesting I build a "lean" web app. I don't know what a "lean web app" means: small HTTP requests but lots of them? or large HTTP requests with few of them? I tend to favor chunky vs chatty.. but I've never had to worry about connectivity before.
Do I suggest a desktop app that replicates data when connectivity exists? If not, what's the best way to approach a web app when connectivity is shaky?
EDIT:
I must qualify my question with further information. Assuming the web option, they've disallowed the use of browser runtime technologies and anything that requires installation. Thus, Silverlight is out, Flash is out, Gears is out - only asp.net and javascript is available to me. Having state this, part of my question was whether to use a desktop app; I suppose that can be extended to "thicker technologies".
EDIT #2: Network is homogeneous - every node is Windows. This won't be changing.
You should get a definition of what the client means by "lean" so that you don't have confusion surrounding it. Maybe present them with several options of lean that you think they might mean. One thing I've found is it's no good at all to guess about client requirements. Just get clarification before you waste a bunch of time.
Shaky connectivity definitely favors a desktop application. Web apps are great for users that have always-on Internet connections, and that might be using a variety of different browsers and operating systems.
Your client probably has locations that are all using Windows, so a desktop application is an appropriate choice. One other advantage of web applications is that they make the deployment issue easy to deal with. Auto-update technologies like ClickOnce make the deployment and update of desktop applications almost as easy.
And not to knock Google Gears, but it's relatively new and would have to be considered more risky than a tried-and-true desktop application.
Update: and if you're limited to just javascript on the client side, you definitely do not want to make this a web app. Your application simply will not be available whenever the Internet connection is down. There are ways to save stuff locally in javascript using cookies and user stores and whatnot, but you just don't want to do this.
If connectivity is so bad, I would suggest that you write a WinForm app that downloads information, locally edits it and then uploads it. This way, if your connection goes down, all you have to do is retry until it works.
They seem to be suggesting a plain vanilla web app that doesn't use AJAX or rely on .NET postbacks or do anything that might make it break down horribly if your connection goes away for a bit. Instead, it should be designed so that you can hit Refresh until it works. In other words, they seem to want the closest thing to a WinForm app, only uglier.
You may consider using a framework like Google Gears to help provide functionality during network down time. This allows users to connect to the web page once (with a functioning connection) and then be able to use the web app from then on, even without a connection.
When the network is restored, the framework can sync changes back with the central database.
There is even a tutorial for using Google Gears with the .Net Framework.
Gears with other languages
You mention that connectivity is shaky at these locations, but that the app needs to be centralized. One thing you might consider is using multiple decentralized read database servers and a single centralized write server. Mysql makes this possible and affordable if your app is small.
Have the main database server at the datacenter/central office. Put up small web/db servers at each location, with your app installed. You can even run them off a user computer if the remote location is not too big. Make the local database servers connect to the centralized database server as replication slaves. As changes come in to the centralized database, the slave servers will pull down the data and make it available locally. When the connection is unavailable, your app data is still at least available, if not up to date. When the connection is available, the database handles replicating all relevant data down.
Now all you have to do is make your app use two separate database handles: reading data it uses the local database, writing data it uses the central database.