On your WP Store search, did your app show up at all in the search results? Or just not at the top of the list?
Unfortunately, an issue recently surfaced around app indexing in the WP Store, and a number of apps just aren't showing up in search results (at all). The Store team is actively working with the search service folks to get it resolved...hopefully very soon.
Hi, as part of Windows Phone 8.1, it is possible for some apps can register to receive system events, including incoming SMS messages, and then act upon them.
It’s important to note that these APIs and events are intended for use by device manufacturers primarily. In order for the APIs to be used in your Windows Phone Store app, your Windows Phone Store publisher account needs to be provided with permission to use these device capabilities (open up a Dev Center support ticket with your request).
For more information…
Using SMS events: Check out the Build 2014 session (http://channel9.msdn.com/Events/Build/2014/2-518) or MSDN docs on background tasks (http://msdn.microsoft.com/en-us/library/windowsphone/develop/hh977056.aspx)
Hi folks, weighing in on this thread a bit with some color commentary. Engineering has been looking at this for some time, and the API was added for mobile operators and hardware manufacturers for obvious reasons.
And while third party app-directed SMS scenarios are nice to have for obvious reasons, they also bump into a few issues: (a) they can run into customer billing issues for sending SMS silently and (b) obvious potential privacy issues for receiving SMS. And while the capability is available on Android (but I don't believe Android operates under the caveat emptor model), it isn't available on iOS.
Digging into this a bit further, app devs tend to want the capability to receive messages on specific “filters” exclusively (only the app gets the message rather than it being broadcast to every application). However, this type of exclusive delivery would require assignment/gating of “filters” at the OS level that runs into all sorts of problems (who gets to register for a filter first? is registration static or dynamic? how are collisions handled? how are revocations handled? what about non-store or side-loaded apps? etc.).
As a result, the team doesn't have plans to provide this capability at this time to the broad developer ecosystem, but please feel free to chime in with additional thoughts on the topic.
Side note that the same issue happens with en-us and en (international English), which has bit me a couple times.
Have you tried contacting support? (within Dev Center)
We rolled this capability out over the course of the year per Bernardo’s blog post (http://blogs.windows.com/windows/b/buildingapps/archive/2014/04/17/respond-to-app-reviews-a-phased-rollout.aspx) – this roll-out was completed over the past year, and is generally available in all markets at this point.
@Harald - the respond feature will be available to developers via the Dev Center portal - and will handle the response via email. So no worries on 7.1 v 8.0 v 8.1.
With Windows Phone 8.1, Cortana provides consumers with the ability to search for content across their personal device. For more information, see the Windows Phone consumer site at http://www.windowsphone.com/en-us/features#Cortana
@Xav, a couple points to your comment:
- Cortana is an app UI over top of the Bing services, don't view this as an all-or-nothing. My understanding is that the search capability is available from the standard search screen on a 8.1 device, regardless of if you have a happy circle or not.
- You don't have to talk to Cortana. If you use voice, Cortana audibly responds. You can also use text, and she responds silently. Allowing you to use voice in proper contexts and for proper content.
With the Windows Phone 8.1 release, the WP Store now provides the ability to provide release notes for the most recent app updates.
We highly encourage developers to take advantage of this new capability. :)
@Jandieg - Hopefully the new 8.1 Store experience (that auto updates apps) will help with this.
@Bill - I've been experimenting with this on my app, and what I've started doing is keeping the major/minor app version (x.x) history in my app description and the 'changes since the last major/minor update' (x.x.x). I've brought up the desire for a retained version history with the team, but I definitely don't know where that lies on their consideration set.
The Windows Phone 8.1 release provides significant advances to the Bluetooth stack, and I believe most of this suggestions needs haveincluding the addition of BTLE,
For more information on the capabilities delivered in 8,1, please refer to the following resources:
- Windows.Devices.Bluetooth namespace docs (http://msdn.microsoft.com/en-us/library/windowsphone/develop/windows.devices.bluetooth.aspx)
- Build 2014 session on Bluetooth (LE) apps (http://channel9.msdn.com/Events/Build/2014/2-519)
Hi, chiming in on the Nokia angle here.
Bluetooth LE is now supported in the base Windows Phone 8.1 Bluetooth stack. With Nokia, the implemented a custom BTLE implementation at the firmware/driver level, which prevents the OS BTLE drivers from getting access to the BTLE radios. As such, Windows Phone can't get to BTLE devices with the 8.1 APIs until Nokia updates their drivers to not own that channel.
This should all be fixed when the Lumia firmware updates for 8.1 come out, but it will be problematic for folks in the WP Preview Program in the interim.
I am anxious as you are to see news or at least timing of when news will come. Unfortunately, I don't have anything that I can share with folks at this time.
Thank you for the suggestion. We hope that recent updates have improved your experience.
However, this suggestion has not generated enough interest and after being posted here for over a year has not collected more than 5 votes. Declining this idea to give you back your developer / application platform votes.
If I may ask, what is the error you're running into? Are you making use of the App ID or other items that get updated upon ingestion? Are you losing capabilities post-ingestion (e.g., trying to get user/device info or stuff like accessing photos/music libraries) that is causing the failure?
Thanks folks for the suggestion and the on-going commentary. We’re marking this as ‘under review’ to acknowledge that the team is aware of this request. This is a very complicated/hard item for implementation, and there is a general feel that the new accelerated certification process alleviates much of the need (as an update can be published, for most folks, in less than an hour – rather than in 4 days).
That being said, continue to weigh in on the comments section.
A couple questions for those on this suggestion to add clarity.
1 - Is having the ability to only move back one release sufficient? This would mean that a developer could only ever move (n-1) releases back, and that that the Store would not keep any additional 'backups'/'undos'.
2 - And is there an expectation that users could also move downgrade once the developer rolls-back the version (and therefore the phone/Store app would need to support 'down level upgrades'), or that the roll-back would only stop additional users from picking up the 'bad' version of the app?
Is this a request for the developer to be able to see the reviews from all countries (via dev portal / dashboard)? Or for the consumer (via the Store experience(s))?
You can open up a support ticket and ask for an app to be moved today. The app will lose all of the reviews associated with it, but it will be moved between publisher accounts and will retain rank/users.
Which version of Visual Studio are you using? Which OS? And do you have the Windows Phone SDK installed?
Semi-random/clarifying question - if you don't have a Windows Phone, then what kind of app are you building using App Studio?
8 votes2 comments · Dev Platform » Consumer - use windowsphone.uservoice.com · Flag idea as inappropriate… · Admin →
I hope you don't mind, but I cleaned up the suggestion to help make it more actionable for the team and for others to add their voice to.
Last of the suggestions for today based on dev conversations this week
I appreciate the frustration here, and we're working to improve this on several fronts. In the meantime, please feel free to distribute your votes/concern on a few actionable items:
- WP8 development on Windows 7 (http://wpdev.uservoice.com/suggestions/3551757) - This one is very unlikely to see change - the work effort would be huge. When we adopted the same kernel and tooling for WP8 that Windows 8 uses, we required items from the Win8 OS for development, as well as for testing (the Hyper-V chief among them)
- Dev Unlock not tied to publisher registration (http://wpdev.uservoice.com/suggestions/1935045) - We've tried a couple routes of enabling this without opening up the door to wide-spread piracy - for example, working with the Chevron WP Labs folks a couple years ago. Enabling homebrew + true hobbyist developers is a critical item for me personally, but it's hard to do in a targeted fashion. It's still an active item that we're chasing down, though. I absolutely agree that separating the publication state from development/testing state in the workflow needs to happen.
- Able to run the emulator in a virtual environment (I don't know of a thread on this) - I also don't see this one as possible to happen in a VMware type of setup. The Hyper-V system that the tools team took a requirement on requires access to SLAT, and therefore physical access to the hardware. While it was technically possible to run the old WP7 XDE in a virtual environment (it was based on the Virtual PC architecture), it didn't run XNA or anything that needed the GPU. What I am trying to work on here is finding a way to allow the emulator to run remotely (so that you could run it in another VM on the same host, or on another server, or in the cloud...imagine that ;-) )...it would likely solve much of the issues folk have, but in a better way because the emulator could still have access to the SLAT/physical hardware. The issues standing in the way of making this happen is mostly how the debugger connects to the emulator, and getting things set up to do this over TCP/IP and potentially taking a hit on communication performance. I don't think it's a short-term thing as there are other things the team needs to tackle first, but it would be a lovely suggestion that you could create here.
I know this comment doesn't address your pain head-on, but please know that there we are trying to make life easier for the dev - it's a complicated workflow that crosses a number of streams. To give credit where it's due, it has gotten better over the last few years...but, as you point out, we still have a distance to go until morning.
Another one added after developer conversations this week
Added this after a developer conversation this week
Thanks for the suggestion; I’m marking this as under review for implementation in a future release of the Store.
I added this after having 2 conversations on the topic this week :)