Is it possible to push windows 8 app directly to some not development-devices (without direct access to device)? For example, if one wants to install demo version of our app during the exhibition on devices of someone who intersted on our product.
First of all, the application deployment bypassing the Windows Store is called sideloading.
One basically has two options to perform sideloading:
Windows 8 Pro and Windows Server 8, if they are joined to a domain, are directly ready for side-loading.
Windows 8 and Windows 8 RT, as well as the above-mentioned systems without domain, require the activation of a special Sideloading key, which can be purchased by enterprises only and usually available in 100 packs (priced at $3000 per pack, $30 per licence).
The installation of the app can be done either by using the application image and DISM or in runtime by add-appxpackage PowerShell CmdLet.
Here is a good explanation of the whole process (in German).
No, it would not be practical at an exhibition to provide direct loading of your application, bypassing the Windows Store. The Windows Store is there to provide a safe environment in which to download certified applications.
It would be a far better experience if users could download from the Windows Store a trial version directly -- maybe you could provide free a wifi/network connection, and a bit.ly link or QR code of some sort to quickly get to the download for your application. :)
While it is possible to do side-loading (walkthrough) in some circumstances, it was not intended to be used in this case. It's intended for Enterprise deployment and the walkthrough article has lots of details about the specific options and the costs associated if the destination machines/Windows isn't running Windows 8+ Enterprise edition.
One other option is that you can also deploy an application for testing purposes to another developer machine (which requires a Windows 8 developer license). It would be unusual for anyone but a Windows 8 application developer to have this activated (as you know, they expire after 30 days). This may be a violation of the licensing agreement though as it is expected that this is for development purposes only. It also involves powershell, so it would be a potentially awkward installation experience at an exhibition.
It is possible dude...
Just developer unlock ur phone and deploy apps directly from PC.
Related
Recently I began working in WinRT for Windows Store Apps (and the upcoming Windows 10 Universal Apps) using C#. After working in .NET for awhile previously, I was excited to work with .NET on mobile devices, only to find that WinRT did not feel like home at all.
Constantly I find myself having to search for alternatives to certain classes that I'm familiar with in .NET since often they're not the same or even implemented in WinRT. I figure that the lack of implementation derives from the fact that WinRT at its core is unmanaged, even though the CLR binds to it from managed code.
My question is: What is stopping Microsoft from allowing developers to import and use all of the familiar .NET classes from managed code, even with WinRT running from behind? I know it's not a limitation of the device because my Surface Pro can run desktop .NET apps just fine and the Mono project has succeeded in porting almost the entire .NET API to devices of every kind.
Thanks for your input!
This is a big topic but there are three basic reasons why you don't get the full .NET API from a Windows Store app.
The APIs don't fit on smaller devices like phones. Since the purpose of the Universal Windows Platform is to have apps that can run everywhere, it can't include APIs that are too resource-intensive (disk, memory, CPU, etc.) to run on smaller devices. (Note that even if the managed API appears to be small, it might have a dependency on a large underlying Win32 API).
The APIs aren't compatible with the Store app model. Many APIs that require permissions not granted to Store apps fall into this category, as do APIs that would enable apps to do "unwanted" things to your machine (the degree of "unwantedness" is subjective).
The APIs are deprecated or there are newer alternatives. This was the case with a lot of APIs in Windows 8, where things like file-system access and network sockets were blocked from Store apps because there were newer WinRT equivalents.
Note that Microsoft is always open to re-evaluating whether a specific API should be included or not. For example, Windows 10 brings back many APIs that were banned from Windows 8.1 (such as System.IO and System.Net.Sockets) and has expanded the capabilities granted to apps. You can file feedback via the Windows Feedback app or on UserVoice if you want additional APIs brought back (adding detailed justification never hurts).
I am trying to develop an application which will deal with the following hardware and perform the stuff mentioned. I want to know that would it be feasible .
1)
Wi-FI
Scan for wi-fi , provide option to turn it off and on or reboot it .
2)
Bluetooth
Turn it off /on , make it discoverable if its not discoverable.
Apps
Get list of all apps that are installed and provide an option to kill them if they are running or uninstall them. The provision should also list the user the apps which he has sideloaded(need to know which all are the sideloaded apps).
Internet Connectivity
If internet is connected , check whether data is flowing or not.
Battery Status
Find all those apps which are consuming too much battery.Provide the option to uninstall them and lower the screen brightness and decrease the screen lock time
All these have to be implemented in an application that I want to develop.
I would be needing links for answers so that I can provide it in my feasibility report.
thanks
You will need to write a desktop app for this. Most of what you're looking for is completely out for a Windows 8.1 Runtime app. Windows 10 adds functionality for several of the bullet points, but in both versions you'll need a desktop app to manipulate other applications.
Universal Windows apps (aka Windows Runtime apps) run isolated and cannot generally affect the system or other apps. They can make changes only within their own context.
1 and 2: Windows 10 adds the Windows.Devices.Radios.Radio class to address your radio bullets, but this functionality is not available in Windows 8.1 Runtime apps.
3: This cannot be done from a runtime app. A desktop app can enumerate a user's apps with the Windows.Management.Deployment.PackageManager class.
4: You can query connectivity with Windows.Networking.Connectivity.NetworkInformation.GetInternetConnectionProfile
5: This is not available in a Windows 8.1 Runtime app. In Windows 10 see Windows.Devices.Power.Battery
similar question was asked here on msdn
I recently started learning Windows Store Application development using c++/cx. I got a developer account(just singed in with my outlook account when visual studio asked for a developer account) and could test most of the application i created on my Windows 8.1 PC.
I am now creating a sample application for reading SkyDrive's content for the signed-in user and displaying it on the screen. To be able to login to a Microsoft account i need to associate my sample application with Windows Store which requires a paid developer account. I had tested a similar sample app in Android which didn't require any such registration. I am wondering if there is any workaround which wouldn't require me to buy a paid developer account as i don't intend to publish any application on the store but merely want to test the Live API.
Also, if not then Why would Microsoft want the developers to pay for just testing the Apps they create which they might or might not finally submit to the Windows Store?
The only way (I think) is to register App here and create not a Windows Store app, but classic Windows App. So, code base will be mostly the same. LiveSdk have no choice to set app Id or app secret in Windows Store version of Live Sdk. Alternatively, there is an ability to get free dev account via dreamspark or bizspark, but there some requirements.
I found an alternative.Just download one of Microsoft's Official Sample Apps for Windows 8.1(Samples are available in C++, C#, VB and JavaScript) and modify it. The Sample Apps are already associated with Windows Store and hence would let you login to a Microsoft Account using the built-in login mechanism.
I am a little confused with the two apps, Windows 8 (which run only on Windows 8 OS?) and Windows Phone Apps.
Based on the marketing I heard around windows 8, I assumed an app available on Windows 8 would automatically be available on windows phone?
I am assuming this is not the case after searching around, because I see a windows app store (which I assume only includes windows 8 apps), and the windows phone.
Assuming my assumptions are correct, do you need to buy a developer licence for both windows 8 app store and windows phone store?
Is it as simple as submitting your windows 8 app that was created through windows phone, or is there additional configuration or development that needs to be done? Assuming that you don't care about resolutions or functionality.
Thanks for any clarification.
*Additional question,
Where does Windows tablets running windows RT and or non RT fall into all this? Are they windows apps I'm assuming?
Hope it helps you. As the store licences are unified (WP8 and Windows 8), the development remains different http://blogs.windows.com/windows_phone/b/wpdev/archive/2013/11/06/unifying-developer-registration-windows-and-windows-phone.aspx
Yes you are correct Both the platforms need seperate Developer Accounts one for the Windows Store Apps and one For the Windows Phone Apps..and yes both the Apps are different you have to develop both the Apps Separately and submit them to the respective market separately only then would it be available in the respective markets.
Separate Developer Accounts for the Windows Store Apps and Phone are no longer required. If you have a App Store account, you should now see that you can register up to 3 phones without a separate registration process.
IF you have a developer account, VS2013, and a windows 8 phone plugged into USB, an easy way to be guided through the process is to create a new project and select a W8 Phone sample. Specify that you want to debug using a Device (as opposed to an emulator). You will get a Device is not registered for development dialog with a link to instructions.
As mentioned in other post, things have been streamlined so W8 and W8 phone mostly overlap APIs, and you can probably use the same source, but will need build separate outputs.
I'm porting a Windows Phone 7 app to work for Windows 8 (and take advantage of the new form factors available).
There appears to be a handy namespace map for a lot of the namespaces, and there are some that are explicitly called out as not avaialbe, but there appears to be no mention of LINQ-to-SQL - is this an omission in the documentation, or is it not available in metro style applications?
LINQ-to-SQL and LINQ-to-Entities are not available in Metro-style apps. Metro-style apps are meant to be lightweight apps which can retrieve data from web services (generally running in the cloud).
Thus, ADO.NET and the entire System.Data namespace is not supported.
Mention was made in the Windows Phone Summit on Wednesday that SQLLite would be available on WP8 and Win8, but no details as to the programming API's were shared yet. Currently the Metro subset of .Net for WinRT applications does not include a database API set. There are some independant efforts to port some of the no-sql based implementations, including RhynoDB and Sterling, so you may want to keep your ears open to further announcements.