Im am trying to connect a local mysql database which runs on xampp with a Universal Windows Platform (UWP) Application. I couldn't find any examples or tutorials on how to archieve this. In one article i have read that this isn't even possible and only sqlite is supported. Is this true?
I have to do a work for school and one criteria is, that it must have a relational database and another is to support multi-user functionality.
I dont know if it is not possible or am I just to blind to find Informations? Sometimes it seems really hard to get to informations to windows app development.
Did someone make experiences with connecting relational databases to UWP-Apps?
UWP app can connect to any server based database behind a web service. Per my experience, Windows Store app can directly connect to MySQL. Check this. I didn't have a chance to try it on win 10 UWP.
Sqlite is the database if you want to deploy a database to the device along with your UWP app.
I am building a windows 8 app which requires me to get data from a remotely hosted server. Which API can I use to get the required data? I am using c# and xaml. I basically want to communicate with Microsoft SQL Server Analysis Services. ADOMD.NET cannot be used as windows 8 store apps donot support it.
In a Windows 8 app, we can specify for example a connection string to read out data stored in a server-side database. Not only would this be a huge security risk (imagine your connection string being on the thousands of devices where your app is downloaded!), it would also be pretty useless to have it there. WinRT has no knowledge of talking with a (remote) database. This means no ADO.NET or LINQ-To-SQL classes are in the API.
windows 8 style apps dont have out of the box functionality to contact to a database. so you need webservices to conect at a remote database.
If you have a database on a web server for which you can write an OData service, then that's an option. You can use the OData Libraries
I hope http://blogs.msdn.com/b/phaniraj/archive/2012/04/26/developing-windows-8-metro-style-applications-that-consume-odata.aspx will help you.
In a situation where you have the UI frontend built using the new Metro style of apps for windows 8, and would like it to communicate with a .NET application running on the desktop on the same local machine (e.g. a windows service app).
What forms of interprocess communication are available between the metro app and the desktop app?
Thanks to Pavel Minaev of the Visual Studio team, who has provided some initial info here in a comment, quoted:
According to Martyn Lovell, there isn't any deliberate mechanism for
that, and some that could be used for it are intentionally restricted.
Named pipes aren't there, for example, nor are memory mapped files.
There are sockets (including server sockets), but when connecting to
localhost, you can only connect to the same app. You could use normal
files in one of the shared "known folders" (Documents, Pictures etc),
but that is a fairly crude hack that necessitates polling and is
visible to the user. -- Pavel Minaev commenting on this issue
So failing normal approaches I was thinking of using web services or reading/writing to a database in order to get some form of communication happening, both of which seem like overkill when the processes are running on the same machine.
Is what I'm attempting here making sense? I can see a need for a metro app to be the frontend UI for an existing service which is running on the desktop. Or is it better to just use WPF for the frontend UI running on the desktop (i.e. a non-metro app).
I'm porting my existing project to Win8 right now. It consists of windows service and tray application which are talking to each other via NamedPipes WCF. As you may already know Metro doesn't support named pipes. I ended up using TcpBinding for full duplex connection.
This post describes what functionality is supported.
Sample of my WCF server that Metro client can consume is here.
Also keep in mind that you can't use synchronous WCF in Metro. You'll have to use Task-based wrapper which is only asynchronous.
And thank you for you question. I was good starting point for me :)
There were a number of questions like this at the end of a //build/ session I attended. Aleš Holeček, the exec who did one of the big picture sessions, came up out of the audience to handle them. Even if you're not a C++ developer, download that session and watch the Q & A. http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-789C
Metro apps can't count on desktop apps or services being installed on the machine. And desktop apps can't count on Metro apps running since they can be suspended any time. You need to start thinking differently. Listen to Aleš on this one.
Take note that with Windows 8.1 Update, communication between Windows Store apps and desktop components written in C# for .NET 4.5+ is now officially supported for side-loaded applications in Enterprise scenarios:
Brokered Windows Runtime Components for side-loaded Windows Store apps
To quote:
Recognizing that critical business functions and rules are embodied in existing software assets and that enterprises have a wide variety of scenarios for which the new application style will be highly productive, the Windows 8.1 Update includes a new feature called Brokered Windows Runtime Components for side-loaded applications. We use the term IPC (inter-process communication) to describe the ability to run existing desktop software assets in one process (desktop component) while interacting with this code in a Windows Store app. This is a familiar model to enterprise developers as data base applications and applications utilizing NT Services in Windows share a similar multi-process architecture.
Although implementing this approach is a bit on the complicated side initially, it allows for deep integration across Windows Store and desktop components. Just keep in mind that for the time being, it won't pass public Windows Store certification.
There is an article on InfoQ about how to build loosely coupled Metro apps with protocol handlers. This is something which has been supported by Windows for a long time and one could foresee an desktop application register itself as a protocol handler and maybe the metro application can communicate through this mechanism.
I have no idea if this is possible, but it might be interesting to check out.
Christophe Nasarre has blogged about a rather hacky way to do it using local files. The result is communication between desktop app/windows store app (referred to as DA/WSA in the blog), without having to switch between the UI of the two apps. He also blogged about another less hacky technique involving protocol handlers.
Note that having a WSA which communicates with a DA is explicitly forbidden by the store App certification requirements
Windows Store apps must not communicate with local desktop applications or services via local mechanisms, including via files and registry keys.
... but it restricts "local mechanisms" only. So I guess one can build a web service for routing the communications.
If you think that you can make an additional manual cmd operation,
you can try :
X:/> CheckNetIsolation.exe LoopbackExempt –a –n=<packageID>;
CheckNetIsolation.exe is included in winRT install, so there is nothing extra to be installed.
I tried it: it works, even after package updating.
As shown on: http://msdn.microsoft.com/en-us/library/windows/apps/Hh780593.aspx
Here it is explained how to find out the packageID for your app: http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/82bad7d4-d52b-4731-a396-13ab9004c1cc/how-to-get-the-appid-of-a-metro-style-app-
It is possible to communicate on the same machine from Metro app to desktop app using local service.
I've implemented some time ago simple "proof of concept", how to bypass the WinRT sandbox using local service. It still needs some kind of "social engineering" or direct guide for installing the service, but anyway, it is possible.
I'm not sure though about the certification rules about "local service" communication when adding such app to Windows Store.
Sample here
By design Metro application cannot access underlying PC directly, only using WinRT API and available capabilities. But when you create back-end service for accessing the PC and all data there, it's basically no longer running in sandbox.
The only "problem" is that user must manually install this back-end service, but that won't be a problem using some "social engineering":
User downloads "PC browser" Metro app, user can browse all pictures, music and videos, using WinRT API, but the app also shows message at the bottom:
"Download our PC browser powerpack and browse your entire PC, for FREE"
User is redirected to web page, from where user can download classic desktop installer containing "PC browser" back-end service for accessing files on users entire PC. Once this desktop service is installed, the Metro app can detect it and use it for browsing the entire PC. User is happy, but the WinRT sandbox is compromised.
Of course this won't work on Windows 8 ARM tablets. Using this workaround it could be even possible to build Metro app clients for classic desktop apps like antiviruses, torrent/P2P clients, etc.
Maybe I missed the point but when activating the Private networks capability I can connect to a local running (http) server using the local IP address (not localhost). This enables my scenario where a winrt app communicates with a wpf desktop app
I'm looking for some input on my current project architecture. There are three components: Server, Desktop, and Mobile Device.
I have 2 goals:
1) Send data (Approx. no more than 100 KB of text) from the Desktop (multi platform client application running on windows XP/Vista/7, and Mac OS X) to a server (Windows Server 2008, IIS 7, WCF RESTful service) to save in a database (Sql Server). The services need to be scalable because the number of desktop devices and frequency they send data is unknown.
2) A service to retrieve data from the database (Sql Server) and send to a mobile device(Iphone and Android application. Message size no more than 100 KB of text). Service needs to be scalable because number of mobile devices and frequency they connect is unknown.
My proposed solution:
Server Side (Sql Server and Windows Server 2008):
I'm looking at a WCF RESTful JSON services to communicate with Desktop App(s) and Mobile App(s). I like WCF because I am most proficient in C#, have some experience implementing WCF, after doing some research it appears all technologies used for the platforms(Windows XP/Vista/7 and Mac OS X) can easily communicate with the WCF RESTful service.
Any high level fundamental issues with the WCF service in this scenario?
I have only implemented WCF on a Windows Server 2003 machine with ~800 devices connecting every 15 minutes. The server was a physical in house server running on a private network. I need this solution to be hosted and scalable. Any recommendations for hosting a Windows Server 2008? Is there a better technology to host the service? (I'm not very familiar with how the cloud stuff works)
The services will be saving and retrieving data from a SQL server. I would like to use LINQ to SQL as my data access layer. It's my understanding there are large licensing fees tied to SQL server so I may need to go with SQL Server Express for now.
I'd prefer to keep the WCF services and database hosted separately (2 diff machines). Any recommendations for hosting sql server(or express)? Is there a hosting service that can scale better for my database? Does it make sense to keep these on 2 diff machines?
Desktop (Client Side)
I am required to develop for Windows XP/Vista/7 and Mac OS X. I plan to write a .net application to run on the windows machine(s). I"m still up in the air if i'm going to write (and learn :P) XCode or try mono. Any cross-platform ideas?
Should I expect to have any fundamental problems getting the desktop applications to talk to my WCF RESTful services?
Mobile Applicaitons
I am required to developer for the IPhone and Android. There are many examples of making WCF RESTful service calls using Objective C and the Android SDK. I'm considering trying a cross platform (ie. Appcelerator). From a high level it appears these mobile cross platforms have built a Java script layer that works with both IPhone and Android!
Any thoughts on using the cross platform technology to write ONE mobile app to run on IPhone and Android?
Any fundamental issues calling the WCF RESTful service in javascript?
Sorry for the somewhat long post. I have never designed a solution of this size. All feedback is appreciated.
Thank you!
As you are clearly wanting to use Microsoft technologies - the suggestions about Mono probably make sense to you and will certainly make things easier.
However I think you may find that you compromise elements of the user experience for Mac and iPhone users which is not ideal as these users tend to have the highest expectations for great user experiences.
I understand that we don't live in an ideal world but if we did you would develop a separate client for each platform - optimised to the needs of each platform. Unless you application is doing a lot of data manipulation the data layer is now abstracted to the server viw your JSON interface so you will not gain much from sharing the data objects across implementations.
As it seems you are implementing the project in a small team (yourself?) then I would suggest that you look at implementing a web solution with the HTML javascript communicating with the server over JSON.
The other option is that you use a flex/air client on windows and mac and flash on the android and Adobe's solution to compile flex/air into iPhone code.
Good luck though.
For your client side you may consider using Appclerator because it will run on all of the platforms that you need with little to no extra code, and it is designed to be used for web app type applications
You should consider MonoTouch for the iphone. You'll be able to share much of the desktop code. I would use Mono on the Mac for the same reason. Android is the odd man out. Eventually someone might create something like MonoTouch for Android but not soon enough to help you out.
I'm in the initial phase of designing an application that will have a backend implemented in C# that will provide data for other platforms using WCF web services hosted on IIS. One of the platforms will the the iPhone.
Since it's a personal project, I want to use it to learn MongoDB. I already know that there are community developed drivers for MongoDB and C#, so I could handle the persistence on the server side using MongoDB.
Without even knowing the replications models offered by MongoDB, I was thinking about some kind of simple synchronization model to keep data local if the iPhone is not connected or has a poor connection.
Here's the question: Can MongoDB be used in the iPhone using the MongoDB C drivers? Has anybody already tried that?
The typical iPhone architecture is to have your application call out to a web service. Even if it is possible to use a MongoDB driver directly from a mobile client I would not recommend it. For a few reasons.
You are basically talking about doing client server architecture where your client application talks directly to the datastore (MongoDB.) What about security? When any authenticated client talks directly to the datastore all sorts of bad things can happen.
Tightly coupling your client application directly to any given data access technology is dangerous in that it would require you to rewrite your client if for some reason you needed to change your data access solution.
It is more common these days to have your client applications go through a data access tier and when the Internet is involved this tier often involves a web service of some sort unless you want to get elbows deep writing server code.
Think about writing a RESTful api exposing your datastore to your iPhone client. I've heard good things about Open Rasta (C# REST library)
Edit - More about hosting MongoDB on the iPhone
Sorry I didn't understand that you wish to run MongoDB locally on iPhone. MongoDB is a server. I do not believe that it is embeddable as an in-process datastore. And it is not possible to run more than one process on the iPhone.
If you are familiar with C# you might want to check out MonoTouch. It allows you to run C# applications on iPhone. There is a nice library for using SqlLite which is supported by iPhone.