Is there a way for apps running on WinRT to send information between them? I know about WinRT's sandboxing and the reasons behind it, but is there some mechanism for two apps created by the same author to pass data between each other?
This was announced for Windows 10 only. You can see the MSDN documentation for this already.
If you mean running 2 apps at the same time by split-screen, you could consider using socket to communicate between these 2 apps. But you need to ensure the port is not occupied.
The classes you need to use:
StreamSocketListener class
StreamSocket class
Article to reference: How to connect with a stream socket (XAML)
This is not possible in windows 8.1 applications because these are sandbox applications
Related
I need to integrate Skype deep into one of my Windows 8 Store application for Windows 8 Pro. We need to show the online status of the user and trace if the call was placed successfully.
We have tried to use Skype4COM but apparently, Win8 Store Apps can only access limited set of COM components.
I am not open to use to use Skype URIs as i would require to trace the status of the call also.
Any pointers or any help would be awesome!!!
At this time, the Skype API is not a Windows Runtime Component so it can't be used in a Windows Store app. Even though COM objects are similar, they don't work in Windows Store apps because they have a different interface, security model, etc.
Right now, Skype URIs are your only option for a Windows Store app. You can find more information on Skype URIs and Windows Store apps # http://dev.skype.com/skype-uri/skype-uri-tutorial-win8.
We are developing a desktop Windows 8 application, that work with WCF-service. We want enable work with Azure WCF-service and with WCF-service in local network(choosingly). Application will be publish in Windows Store.
What the best practise deploy WCF-service on local server of company?
I understand what you want. Let's pretend the Azure part is not an option. How can a Windows Store App use a local service (WCF or not)? That's the fundamental question.
Here's the answer(s):
First, a Windows Store App cannot access intranet services unless it has private network access declared in its manifest. It looks like this:
Second, in order to use private networks in your manifest and get accepted into the Windows Store, you must be a company publisher and not an individual. More on this is discussed in this SO question: Which features are allowed for company store accounts and not individual?
Third, a local service cannot be mistakenly thought of as localhost. To this end, localhost is not available to Windows Store Apps, unless they are side-loaded (which means they are manually installed and not delivered through the Windows Store at all). To access localhost, you can enable loopback, but, as I stated, this disqualifies you from the Windows Store. There's more on this here: How does Windows 8 Loop Back work?
Forth, because you are talking about a service, you might want to authenticate the user. This is accomplished using enterprise authentication (just like in number 1) only a few checkboxes higher. And it has the same restrictions as private networks.
Fifth, you are not asking this, but to be clear, local access does not mean you can speak to a local SQL server. The reason for this is because the SQL namespace is not part of WinRT or .Net for WinRT. Windows Store Apps are intended to be service-based apps.
And, that's about it. I think you are good if you follow that.
It doesn't sound like you are talking about a pure enterprise-play, but it might be interesting to you to read through some of the strategies for enterprise developers: http://blog.jerrynixon.com/2012/08/windows-8-apps-whats-enterprise-to-do.html
As for deploying WCF, there's nothing special just because a Windows Store App is accessing it. So for deployment, just use vanilla techniques you are already using. :) That's it.
Best of luck!
I planned to create a Windows 8 Store App but reluctantly had to switch to desktop application. I found that Windows 8 Store Apps fail to detect second screen, which is necessary for me.
The intention still is to mimic the behaviour of Windows Store App as much as possible. Partly to educate myself but also to use a modern nice design.
I use WPF with very similar design (App bars, Navigation bar, snappy await-async pattern, etc)
Now I come to the point where I need to store settings!
I would really like to use the very convenient central storage available through Microsoft Live login. Is that possible even if I don't have Windows Store App?
Clients might be Windows 7 or Windows 8.
Can I make the user login to Microsoft Live and use these facilities?
Many WinRT APIs are available from desktop applications, in addition to Windows Store applications. Windows.Storage.ApplicationData appears to support desktop apps. Look under the "Requirements" section in the documentation:
Minimum supported client: Windows 8 [Windows Store apps, desktop apps]
Someone at Intel posted on how to use WinRT APIs from desktop apps. The post is from September, 2012, and the screenshots appear to be for an older version of the MSDN documentation. Just keep that in mind.
Dave Bennett of Microsoft has a useful blog post which will introduce you to roaming your app data.
I may have misunderstood you, but I think what I mention above is what you want instead of using the Live Connect APIs.
I have a traditional Win32 program which gets some data using WMI (and it cannot be fetched using API available to Metro apps). Now I want to make a tile with part of this information. As I've understood, it's impossible to simply send this data from Win32 program to the Metro application. What's the preferred way to do such thing?
There is no direct app to app communication method. What you want to do can be accomplished in several ways, however. Your Win32 app could write data to a location on the file system that a Metro style has access to. Also, you could synchronize your Win32 app with your Metro style app using the cloud. You need to be careful, however, as this might violate some of the app certification requirements.
If you are simply writing something for yourself (not concerned with publish your app), you might consider taking the functionality that currently have within your desktop app and encapsulating it within a wcf service running on localhost. Metro apps can call wcf services.
One option would be to have your Win32 program create the tile XML and deposit in Windows Azure storage (or really anything accessible via a URI) and then your Windows 8 Store application could subscribe to that tile via a Periodic Notification.
There are some constraints here which may or may not be relevant to your application - like the refresh rate of the tile (discrete periods from 30 minutes to 1 day) and the machine must be connected to the network when the poll from the URL is made.
You might be able to incorporate a background task to do something similar.
I have the following scenario:
We develop a silverlight 4 app for our customers, that will be used as an out-of-browser app. The app is working offline, i.e. app and database are on the users local machine. The app is using WCF-RIA-services to connect to the local database. The database will be an SQL Server Express, SQL Server CE or MySQL. We are using MVVMLight and MEF.
An external webserver is only used for updating the app from time to time or adding new modules to the app. To achieve this we do something similar as shown in Jeremy Likness blog (http://www.wintellect.com/CS/blogs/jlikness/archive/2010/05/25/silverlight-out-of-browser-dynamic-modules-in-offline-mode.aspx )
The reasons why we are doing such a scenario are complex. But to keep a long story short it is mainly for compatibility reasons for a later online version and we don't want to use WPF. So we need to get this working with Silverlight and WCF-RIA services.
Ok, that's the scenario and here's the question:
Do we need a local webserver in this scenario? The app is programmatically installed as out-of-browser, the database is local and connected via WCF-RIA.
If yes, which webserver would be sufficient? It should be installed and configured via an initial setup that is executed by the customer. The customer should not have to do anything with configuring the webserver.
Any other ideas or comments on this scenario? Any other possible solutions for this?
Thanks for your help
Dirk
silverlight wasn't meant to be used this way I think. So it would be like when you are developing app in visual studio and use Cassini to see result - everything runs locally - but you still need a web server. Maybe more info here - http://www.infoq.com/news/2010/06/WPF-vs-Silverlight
I´m not able to provide with a full answer to your problem, as we are currently facing the same problem. (WPF not being cross-platform, Very specific hardware on some clients)
But I may share some of our thoughts on our type of Thick-Silverlight-Client:
To keep deployment etc. simple we use a self-hosting process (installed as background process)
We may not use RIA as the background process has to run using Mono VM (but for MS-only solution see Can WCF RIA Services be self hosted? )
Architectural thoughts on standalone "Clients":
Depending on your requirements implementing a server for each client communicating with the "main"-server by messages (NServiceBus) may be overkill. But if you want to use a client database if offline and silverlight for ui you should consider using an event-driven-architecture.
There is a slideshow on combining "Event-Driven-Architecture" & "CQRS" with Silverlight. But i would not use it as a blueprint more like an inspiration.
http://www.slideshare.net/dennisdoomen/cqrs-and-event-sourcing-an-alternative-architecture-for-ddd