I am using Direct2D to develop my app's UI, both the desktop and Window Store versions, but I just became a little concerned when I couldn't find concrete information about Windows Store Apps supporting Direct2D.
I looked under the APIs for Desktop Apps and it shows Direct2D, however I can't find it under Window Store Apps APIs.
The Direct2D APIs are available for use in Windows Store Apps.
From your question, it's not clear which specific APIs are of interest, but MSDN has a quickstart showing how to draw to a Windows::UI::Core::CoreWindow via Direct2D.
Related
I've been researching if it's possible to integrate Android, iOS and Windows Phone 8 in a buildscript for Jenkins. The main goal is if there is a release in a specified branch in the given VCS, that it'll publish them to their responsible store. At the moment I've a way to publish Android and iOS, but it seems that there is nothing for Windows Phone 8.
The question is:
Is there a command-line based application that is able to publish Windows Phone 8 apps to the Windows Store?
If there is a way to integrate with a API or simply by doing some POST/GET requests, I would like to know as well. At the moment I'm researching that part.
The part of building and signing the APK's, APPX's and IPA's is already taken care off.
For iOS I'm able to use FastLane(Deliver) or
Nomadcli(Shenzhen);
For Android I'm able to use a Jenkins plugin(Google Play Publisher) or integrating with the API (there are various command-line based applications out there);
I would really appriciate if you can leave a answer! Thanks in advance!
There is no API for the Windows Store available (yet) that would allow you to do this.
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'm evaluating Intel XDK as a possible solution for developing cross platform mobile apps. I can see from the documentation that you can do in app ads and in app purchases in XDK via Cordova plugins, however there is no mention of whether the apps themselves can be offered on the various app stores as paid for apps or whether they need to be free.
Its not clear from the build and deploy documentation how to build a paid app. I would expect that either XDK or the app store would require pricing information. However for example, the docs show how to generate an app certificate for the Apple app store, but these instructions don't seem to mention pricing either.
I'm guessing from what i've read so far that only free apps are possible and then you need to make money from within the app. Can anyone tell me what the answer is. The free model does not suit the particular app I'm investigating.
Intel XDK will just build the apps for you, you can sell it in App Stores or make it free, its up to you. You have to set the price while submitting the apps to the various App stores on the apple or google website, not in XDK.
As the developer of the application, it's your decision in regards to defining your app as Free or Paid with a particular price per country location. The app stores have a dashboard/portal for configuring this attribute of your application. (Android-Google Play Developer Console; iOS - iTunes Connect; Windows Phone - Windows Phone Dev Center)
Need to understand what are the basic technical differences between chrome and firefox packages apps & other html5 apps in blackberry,tizen.
All of them support apps in Html,Css,Js but where and how are they technically different
1.Can One app created for one platform be used for another without changes
2.If they cannot be used across then how easily can they be migrated
3.Are the differences only in manifest and main browser/os specific
I don't think there is an easy answer for this one. You'd have to probably study each platform's api layer and then do a comparison. Start with chrome.* and then research all the other platforms. If you do end up doing this, please publish your results as I'm sure many future HTML5 app developers would love to read your findings!
There are 2 type of web apps.
Hosted Apps : It can be publicly accessible Web server, just like any other website.
Packaged Apps : It can be packaged sucg as a zip,wgt and so on, instead of hosting it on a web server. The apps file extension is depends on the plaform. (chrome, firefox, bbx, tizen...)
Both kinds of Web Apps are support all of HTML, CSS, JavaScript, and so on.
One difference from a hosted app is that, a packaged app must specify a platform dependant metadata such as mainfest file. And there are different device apis. For example, firefox os provides their own web api for firefox app. Tizen also provides their own web device api for tizen application.
If one application is only standard API (HTML5), then all web platform supports it (Pacakaing may be differnet.). But if application also use non-standard api(like device api which is mentioned above), it couldn't reuse.
This question is not directly related with programming or software development but since this is the official Google Drive SDK support platform I'm placing it on SO.
I am the publisher of an Android application that is distributed in the usual Free/Pro format (where the Pro version provides many more features than the Free version).
At this moment I'm planning to integrate the application with Google Drive but only in the Pro version. The Free version will still show the buttons and the Google Drive branding, but as the user tries to interact it will show a message stating that the feature is only available in Pro version with the respective link to the Pro application version.
Now the question itself:
Is it legal (or allowed) for the Free application version to show the Google Drive branding, since its just advertising and not in fact integrating? If not, how should I advertise the Google Drive integration (from the Free version) that is included in the Pro version? The fancy Google Drive branding is essential to capture user attention at this point.
It is legal, but please make sure to check the branding guidelines and terms of service.
As far as I know if it is free to develop the application using the google resources/access there won't be any copyright issue it is just that application will have extra functionality provided by pro version which gonna work with google drive. From a user point of view I would just say that it looks like dragging money out of people by charging them extra for little effort that is putted for extra functionality