We are currently planning to develop a suite of Windows Store Apps. They are independent and fully work alone, but they are related and act in concert. If a user has several of them, they should share some of their settings (and data), so that the user does not have to manually change these settings in every single one of them.
Is such a scenario even intented?
And how to implement it?
Registry: Does not work. Apps cannot access the registry.
ApplicationData (LocalFolder, LocalSettings etc.): Does not work. Apps cannot access the data of other apps.
Cloud services: Kind of works, but only when the machine is online. Our apps should work offline, too. And we would need to create/rent such a cloud service, which would cause additional costs.
KnownFolder.DocumentsLibrary: This –currently– looks like the only solution to me. The apps are already saving and sharing data there, so let's just save our settings there, too. But the name of the shared folder is one of the settings! And Windows Store Apps cannot create hidden files, so the user can see the settings file. This makes this solution a bit... "rough".
Any other ideas or additional information I have missed?
If you want them to sync with each other instantly, even when the device is offline, then that's your only option. Windows 8 Apps are not intended to share settings.
So much want of sharing.
Roaming API will only share with the SAME app, the SAME user, ANY W8 device.
SkyDrive will only share across ANY app, the SAME user, ANY device.
Using Azure (or any web service) will share across ANY app, ANY user, ANY device.
Don't do this
Don't use the register, the API is not supported
Don't use the file system, the boundaries cause your app to be brittle
Don't use ApplicationData.AnyFolder, this is restricted to a single app GUID
You had might as well get "instant" out of your language, man. That just doesn't happen. But you can have fast (let's call it near instant); you can use Sockets or SignalR to connect your client to some service out there with nearly instant responses. A less sophisticated approach would be to poll from your client, too. It has served developers for decades.
Related
I'm new to web development and just built my first website with .Net Core. It's primarily HTML, CSS, and JavaScript with a little C# for a contact form.
Without recommending any service providers (question will be taken down), how do I go about deploying the website? The more details the better as I have no idea what I'm doing haha.
Edit: I am definitely going to go with a service provider, however the business I am building the website for doesn't have a large budget so I want to find the best provider at the lowest cost.
Daniel,
As you suspect, this is a bit of a loaded question as there are so many approaches. One approach is to use App Services within Microsoft Azure. You can create a free trial Azure account to start that includes a 200.00 credit, which is more than enough to do all of this for free. Then, using the Azure Management Portal, create an App Service (also free) on an App Service Plan in a region that makes sense for you (i.e. US West). Once you do that, you can download what is called a Publish Profile from within the App Service's Management Portal in Azure.
If you're using Visual Studio, for example, you can then right click your project and "Publish" it (deploy to the cloud, or the App Service you just created). One option in that process is to import an Azure Publish Profile, which you can do with the one you just downloaded. This makes it really simple. The Publish Profile is really just connection information to your Azure App Service (open it in Notepad to see). It will chug for a bit and then publish and load the app for you. You can also get to the hosted version of your app by clicking the Url of the app in the App Service management portal on the main page.
This may be oversimplifying what you need to do, but this is a valid direction to take. AWS and others have similar approaches.
Again, tons of ways to do this, but this is a free approach. :-) I don't consider Azure a Service Provider in the sense that you asked us not to. Instead, I wanted to outline one turn-key approach with specific details on how to get there.
You can find specific steps in a lot of places, such as this link:
https://www.geeksforgeeks.org/deploying-your-web-app-using-azure-app-service/
DanielG's answer is useful, but you mentioned you don't want use any services from service provider.
Usually, there are only three ways to deploy the program,
first one is the app service provided by the service provider mentioned by DanielG,
**Benefits of using service provider products:**
1. Very friendly to newbies, follow the documentation to deploy the application in a few minutes.
2. It offers a very stable, scalable service that monitors the health of our website.
3. We can get their technical support.
**Shortcoming**
It is a paid service, and although Azure's service has a free quota, it will run out.
**Suggestion**
It is recommended that websites that are officially launched use the services of service providers.
second one is to use fixed IP for access (it seems that fixed iPv4 IP is not provided in network operations),
**Benefits of using fixed IP:**
If there is a fixed IP address, or if the carrier supports iPv6, we can deploy our website, and the public network can access it. And if you have domain, it also can support https.
**Shortcoming**
1. There are cybersecurity risks and are vulnerable to attack.
2. Without perfect website health monitoring, all problems need to be checked by yourself, and it is very troublesome to achieve elastic expansion.
**Suggestion**
It is generally not recommended because there is no fixed IP under normal circumstances. Broadband operators used to offer it, but now it doesn't.
If you are interested, you can try ipv6 to test.
the last one is to use tools such as ngrok or frp for intranet penetration.
**Benefits of using intranet penetration:**
Free intranet penetration services such as ngrok, the URL generated by each run is not fixed, and there are some limitations, such as a new URL will be generated after a certain period of time, which is enough for testing.
Of course you can purchase the service of this tool, which provides fixed URLs and supports https.
**Shortcoming (same as the second one)**
**Suggestion**
The functional implementation is the same as the second suggestion, and the physical devices used by the website are all their own. The intranet penetration tool (ngrok, or frp) solves the problem of not having a fixed IP, providing a URL that you can access.
There are few users and the demand for web services is not high, so it is recommended that individual users or small business users use ngrok and frp in this scenario. Generally suitable for OA use in small businesses.
I am building a UWP app that targets both x86, x64 and ARM platforms. I want to replace the current implementation that uses Azure for the backed (an App Service and an SQL Server) because of the high price and because my Pay-As-You-Go subscription does not allow me to set a spending limit.
I thought about using a local database but I don't know if that could be a solution since I want the user to be able to have his data synced on both PC and phone for example. I am also ok with renouncing the idea of a structured database in favor of structured files (like xml) if I can find a way to keep them somewhere in the cloud (and then I can read/write them from the client app - no need for App Service).
Are there any free, non-trial alternatives to Azure? Or should I look more into the file storage implementation? Thanks in advance.
Instead of Azure you could use another web hosting solution to publish you API. Azure also offers small free plans that might be sufficient.
An alternative would be to request access and store/sync data to user's OneDrive. Each logged in user with Microsoft Account should have OneDrive storage available so this is a good middle-ground, which is still free for you. A nice introduction to this can be found in this article.
UWP also offers RoamingFolder where you can store small files that are synced across the devices that you use. Unfortunately this is less reliable because you are not able to control when the sync happens and cannot resolve conflicts.
I have successfully migrated to another cloud platform: Heroku. In my opinion, at least for small apps, Heroku offers the best solution both technology-wise and price-wise.
I am now able to have a webservice hosted for free in the cloud, without worring about traffic and number of requests. Of course you can scale up if you want better performance, but you can start with a free plan. Also, I have a postgressql db hosted also in the cloud, also for free (up until 10 000 records, and it will be just 9$/month if I want to upgrade to 10 milion). One can never found an offer like this free on Azure.
I had to learn a bit of Node.js (there are a lot of languages Heroku supports for backend services, but .Net is not one of them) but it was totally worth it!
Another option that is now starting to gain more and more popularity is FireBase. I will certantly also check that out for my future apps.
I am curious about relaying messages from one app on one machine to another machine. I have a shared network storage readily available to me. My thought is that I want to run an app on a single machine that runs intranet uploads. I cannot control anything about the domain or the shared network storage other than creating files/folders.
I want this app on its own machine to be able to report somehow to a completely different application installed on completely different user machines (so in case of errors lets say, users could intervene) and at some point, across platforms (vb.net/Access/etc).
The first thing that hit me was to stream write the upload app's status to a text file, and then have a timer on my users end app that monitors the file that the upload app writes to.
However, before implementing, I am wondering if I am reinventing the wheel, and theres a better way to do this. I am seeking simple solutions, and eventually I would like to integrate this into VBA/Access. What does SO think fits the bill? What is the downside to streaming a "log"?
You're reinventing the wheel. This is Message Queuing. There are many existing solutions to do this, including MSMQ (built into Windows) and RabbitMQ. There are also cloud based services like Azure AppFabric and Amazon Simple Queue Service.
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!
As far as I understand, Microsoft wants to allow "having both desktop and modern ui GUIs" only available for web browsers (am I mistaken here ?).
Does that mean common apps will be developped twice ? With e.g Skype being available both as pure desktop app and pure modern ui app ? And if a user installs both, these both instances will share no data ?
I can't imagine them doing a shift towards gesture friendly uis/hybrid ui, and leaving full blown desktop apps (not toy/phone-like/game apps, that can live in one space only) with no integration/entry points inside modern ui. Or maybe they want to participate in that "kill full-blown desktop apps" movement ?
So is there a model for a desktop app developped in whatever GUI toolkit, that wants to have some minimal integration with a small HTML/CSS/JS frontend in modern ui, like for e.g providing a dashboard of favorite or recently accessed files, contacts, etc ?
Your first statement of "only in a browser" is not correct. Desktop applications don't change their current design paradigms. You can have browser-based apps on the desktop, of course. But full clients are still supported and still viable as a real solution to problems.
Your takeaway from that comment should be that desktop applications are not deprecated as people assert. The reality is, desktop applications are still the only solutions to many problems.
Your second question of shared data is not correct. Skype shares lots of data with its app companion. Not because of shared local storage, however; it is because of the services that it shares. My account and contacts are on the server. So, they share a lot.
Your takeaway from that comment should be that Windows 8 apps should not highly leverage local storage but should be built as service-oriented clients. To that end, your desktop applications should have already started to leverage this architecture, too.
Your third question (which is very cryptic) seems to be asking if a desktop application and a companion Windows 8 app can share or integrate with each other. The answer is yes. Not only can they share the same service, but file associates, custom protocols, and some of the non-Store manifest capabilities allow for this explicitly. Line of business applications should have a companion app, if you ask me. The integration points are many - though not every. But there is no other way to leverage the new capabilities of Windows 8 without introducing a companion app - even if that app does very little.
Your takeaway from that comment should be that Windows desktop applications and companion Windows apps are the preferred and anticipated development approach.
Best of luck, thanks for the question.