I need to accept in-app purchases from within my desktop application and was wondering if the new Windows 8 API allows thein-app purchasing to be used with Desktop apps aswell as Modern UI apps? (http://msdn.microsoft.com/en-us/library/windows/apps/hh465433.aspx). I have read the docs and it doesn't say that you can't use it in Desktop apps, but there is also no documentation for it for desktop apps and all I have seen online are questions about whether it can be used in desktop apps but no real definitive answers.
This isn't purely a purchasing option. It's more about how I would need to implement this for a Desktop application if it can even be done to begin with.
Aside from that: Are there any in-app purchasing frameworks/SDK's that you could recommend if the one from Microsoft is not an option?
Update:
An article here will outline how you can submit a desktop application to the store. Unfortunately how this works is when the user downloads a Desktop Application from the store, it will load a Metro style portion and then navigate them away from the store to download. The Store will handle said transaction and compensate you accordingly based on the acquisition.
As part of the submission process, you must supply a purchase page URL
for your app. This URL is a link that sends the user directly to the
page where a customer can acquire your app with the fewest clicks
possible. This is a great feature for customers; if you provide them
with a clean and easy way to acquire your app, you’re already making a
great impression by giving them a simple and clear acquisition
experience.
When you submit a desktop app, you must supply a purchase URL for
32-bit and 64-bit systems. This URL can be the same for both.
During the app submission process, we request that you supply a URL
for users who need the x86 version of an app and one for those who
need the x64 version. For Release Preview, both URL fields are
required, and should correspond to the version of Windows that a user
is running. If the acquisition page is the same for both, we recommend
that you use the same URL in both fields. The Windows Store detects
whether a user is running the x86 or x64 version of Windows, and users
can only see apps that correspond to this version.
Essentially Microsoft will only be handling the commerce of your application; all other aspects will be handled outside of the store. The only aspect that Microsoft will directly handle is the initial commerce, with In-App purchases you might be able to have the commerce portion handled, but you'll still need to provide the information to be handled outside of the store.
Also, the current outline for a said feature in desktop applications really hasn't been covered any the documentation, perhaps as 8.1 approaches more details will be announced.
Related
How can I tell using c# or winjs when your app that the user downloaded is being uninstalled?
Can you call home, or try to save the client by giving/redirecting them to a site with an exit poll?
Not supported. A key goal with the Windows Store is to make it seamless and painless for consumers to try apps. One result of this is that Store apps don't have any control over or hooks into install/uninstall processes. Bottom line is that the act of uninstall is not a time to try to exercise user engagement strategies. :)
Is there an equivalent to Windows' group policies on Windows Mobile?
My goal is to prevent users from being able to change the date or time on a Windows mobile device and instead ideally allow an application to change it instead.
The only tool that may allow to manage such settings is SCMDM (System Center Mobile Device Management: http://en.wikipedia.org/wiki/System_Center_Mobile_Device_Manager).
But you can use a blacklist (http://community.intermec.com/t5/Device-Management/Tips-collection-thread/m-p/2941#M375)
REGEDIT4
;Enable blacklist of applications that should not run
[HKEY_LOCAL_MACHINE\Security\Policies\Shell]
"DisallowRun"=dword:1
;Add entries to blacklist of applications that should not run
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\DisallowRun]
"1"="clock.exe"
You can also disallow access to certain control panel settings using ReDirect="" key
[HKEY_LOCAL_MACHINE\ControlPanel\Clock]
"Redirect"=""
But all this can not replace a good locked down kisok mode application.
I have written several posts about kiosk mode: http://www.hjgode.de/wp/2012/05/29/windows-mobile-kiosk-mode-series-part-2/
I do not know of one. That does not mean it doesn't exist, though.
Our solution here has been to set the device's time every time a database connection to our server is made by forcing all applications to use a global "get open connection" method that first calls SELECT GetDate(); on our SQL Server and sets the Device's date before returning the open connection to the calling method.
Is there an equivalent to Windows' group policies on Windows Mobile?
Windows Mobile is pretty much dead except for the medical community. OT: platform certification is expensive and time consuming (its the FDA equivalent of FIPS 140), so many medical devices still use the older Windows CE core. It could be popular elsewhere, such as Automotive (I don't work with the industry, so I don't know).
Windows Mobile devices do take group policies, so there is no need for an equivalent. Information is still available online and in MSDN. For example, Managing MDM Devices and Configuring Device Group Policy Settings.
Jeff
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
we have an APP, that uses many local resources, such as windows printing API, windows registry, some Active X to connect to POS devices(to pay money & get receipt, the price is sent from APP), Barcode printer to print labels, RFID devices to read & write some data. The application is written with .Net framework 3.5, and uses some new features of .Net framework (e.g.: WCF). The forms in app are very heavy forms(7 of them are essential), in each form, there are over 100 Textboxes, combos, radio buttons, panels & many other controls, that according to need of user are shown or hidden, disabled or enabled, filled & cleared, many many times.
After the user does the work, prints most be sent to previously selected printer automatically, labels most be printed by barcode printer, RFID & POS devices are called if neede.
The problem is that now we need a web base version of this. the reason is that there are an administration department who needs to be aware of any transactions online (there is a dashboard software). In the WIN APP version, we use WCF to send & receive new data (something like replication happens).
According to my searches, there are 3(even 4), way to accomplish this goal, as below.
Using WPF technology
Using Clickonce
Using Pure html + Active X(meaning asp.net, very heavy javascript & Write Active X)
Hosting windows forms controls in IE
WPF’s XBAP is good, but:
It needs to download all dll’s to local machine & then start the application. This also happens every time a new version is uploaded to server. The sizes of dll’s are about 5meg.
Also there is a risk that a user can disassemble the dll’s. Also we need to sign the assemblies in order to be able to use win API’s, and the user need to add the site to its secure site.
The main disadvantage is that WPF is not actually in Web architecture, I mean, dll’s do calculations on client side & the server is only responsible for saving entities (& does some validations).
refer to https://stackoverflow.com/tags/web-applications/info
Clickonce:
No idea at all, we can deploy App(the WPF version or windows forms version) as a clickonce app, but the server is only responsible for updating new versions of software.
Pure web & HTML + Active X:
This is the time consuming work, everything seems to be ok, but actually we need to be JQuery & AJAX masters & I think most of time is spent on debugging javascript. Also only IE can run the App # all, because of Active X controls in page.
Winform in IE:
Not a good choice at all, but we can do this, the output is works only in IE, also the rendered UI, is in very bad style.
There is also another way, may be a hack, when we develop with pure web, we can write some WCF services to do the hardware part(commiunicating with hardware, local resources & other things) & install them on clients(run for example with cassini). So when we need for example to work with hardware & local resources(POS, RFID, Registry & others), we can call them from our site with the web service call(that points to local host).
Which of these are good choice & what?
Is there any other solution?
any idea can help.
many thanks.
Cleanest solution may be to go WPF for the presentation tier (silverlight will require an additional step to access the local machine) and click-once (just because you are considering click-once doesnt mean your server is now just a distribution mechanism, also correct me if im wrong but you can also include the .Net runtime as part of the click-once distribution package)
Also just because its WPF doesnt mean all your business logic needs to be downloaded with the client, id collect your business logic server side, at least the sensitive stuff and call it via wcf -with security of your choice-.
EDIT
Some useful links
Learning WPF with BabySmash -Manually Managing ClickOnce and some more Designer Goodness
Deploying a WPF Application (WPF)
Silverlight, Wpf Web App (xbap) or Click Once? Pros and Cons
I'm not sure I understand all of your requirements correctly. It looks to me that all you need is a service component that tracks the transactions. Rather than rewriting everything as WPF/SL, why not modify your current application (you didn't mention the technology used nor if you can modify it) to log any transaction to a service endpoint.
The service endpoint records the transactions in a database (e.g., WCF over https, storing data in SQL Server). From there you can either expose the information as part of the dashboard software you mentioned, or you can create your own reporting application using something like ASP.NET MVC.
We are moveing our old Access VBA / SQL 2005 application to new technologys and have 2 options do we build a Windows Form Application with Microsoft One Click Deploy or a ASP.Net Website?
The application is a work force mangement system booking jobs dynamic scheduling gantt chart components. It will be used by 400 + Users over 20 Locations.
Can you give me some feedback on these options.
If you want the application to be maintained in one central location and accessed by the users over the web...go with a web application. If your team is more familiar with Windows Form applications, there's going to be a learning curve involved with this option (maintaining state, dynamic controls, page events, the DOM, etc.) so the time investment is going to be greater.
If you want the clients to have a rich interface installed on the desktops that you can manage easily from a central location...go with Windows Forms (or WPF to provide a nicer user experience). Using ClickOnce for deployment will make sure that the client applictions stay up to date. It sounds like this would be the more familiar option for your team and produce the best product in the shortest amount of time.
If your users are all inside your corporate network, either option can use a central SQL Server database (or shared Access/SQL Server Compact Edition/SQLLite database).
Don't get caught up in the hype. Web appilcations aren't always the best option.
I would create a web application. This will provide the benefits of a central location to manage. With 400+ users and 20 locations a windows app will take more time and headaches for updates and maintenance.
Provided all your users have good bandwidth to the hosting site (10mb at least) then the port route to a Click-once app is probably the easiest, and should give your users the shortest learning curve.
Have you looked at silverlight as an option? This will give you the benefits of a web application but will allow you to create a richer UI.
I have deployed a ClickOnce app to over 110 locations with 500-600 users, and ClickOnce does a nice job handling deployment, maintenance and updates. A couple of things to keep in mind:
ClickOnce apps still are software running on users' machines rather than in a browser, so even though in most cases it is just as easy to support as a Web app, there will be occasional maintenance problems you won't normally have to support with a Web app (corrupt registry, local machine security snafus, hard drive issues, etc.). You also have to maintain certificates for the ClickOnce assembly permissions, which is an additional area of administration/support.
With the advent and gradual maturing of Silverlight and better AJAX tooling, the UI gap between Windows and Web is getting smaller and smaller
The bigger your app gets, downloading of updates can take some time, particularly at remote locations that may not have the fastest network access speeds.
You will need to weigh the benefits of deploying a Windows solution over a new Web one; in our case, the application we were replacing was a Windows app, and we wanted to reproduce a lot of the screens and workflow to look/act the same as the older version for productivity and training purposes, so we picked ClickOnce. I don't have any regrets, ClickOnce worked well for us.