My company is looking to move from Android to Windows 8.1 phones but one of the obstacles we are seeing is that there are no Pager apps. We are looking into building our own but it looks like the Windows.Devices.Sms type methods are not available in Windows Phone 8.1. Is there a reference I can use to get the same functionality?
There is no way an app can access the text messages. Only in special cases, for example, Truecaller app alone has special permissions to intercept caller ID's. Since you say that you belong to an organization, you can approach Microsoft directly. They may give you special API's for that purpose.
Related
Folks,I am planning to build an app to count the number of sms's sent by an user over a period of time.But I am not sure if WP OS SDK gives access to the depth of writing such an app.I am still very new to mobile development,and as Microsoft has limited the access to some API's (ex:language) in the windows phone OS,I was not sure if I can do so.
On the contrary the application I want to build is kind of a basic feature that is in built in many basic phones.I need to get a start for app building,and may also come in handy on my personal phone! ;)Anyone who has come across working on any related feature might help me with his experience.Thank you for your time.
The Windows Phone SDK does not allow developers to access the content of SMS messsages for privacy reasons (or count of those, for that matter).
Your best (and only) bet at the moment is let the user use SmsComposeTask and count the number of messages potentially sent from your app.
In "old" times I created simple tool for Windows users, which tracks what they were doing in the front of computer (where simple activity monitor). I was using Win32 api and functions like GetForegroundWindow, GetWindowThreadProcessId, etc.
Yesterday I installed new Windows 8 and tired to run my program. I got 50% success: for "classic" desktop it works like always:).
For Metro UI I just got one application: WWAHost :( without any details.
So my question is: is there a any way for tracking active application in Metro UI?
Thanks for help
UPDATE:
I'm trying to access Metro UI app from Win32, I know that accessing Metro app from another Metro app is impossible
You see, in WinRT, your application is the top-most application. And when your app is not the top-most application then your threads are suspended and the kernel will not schedule any more operations for your app. End of story.
This means what you are wanting to accomplish cannot be done in WinRT. You are thinking more like a resident app or a service with access to the desktop. Those apps have two advantages. 1) they are always running. And, 2) they have the API to do what you are wanting.
WinRT intentionally puts apps in a sandbox so that the user's experience, performance and battery life are protected. Your scenario and scores more like yours underscore the continuing need for desktop apps. (as long as there is a continuing need for those types of apps ;)).
Sorry, if this is bad news.
As for enumerating other apps. This is also not possible. You cannot know if another app is installed or if it is running. You can call out to another app through protocol activation or file activation or (in a sense) through the share contract. But you are unaware if they get the message and if the user has it installed in the first place. And this is by design.
It is worth mentioning that you can pinvoke to Win32 APIs in your WinRT application. It causes lots of problems and can create a headache to get certified into the store. But even then, not all APIs are open to you. And you will find this particular use case is a non-starter.
I am sure this will not be possible. With Windows 8 'Metro' only a single application is active. All other applications will be in a suspended state whilst the topmost application is running. This makes it impossible to write an application that monitors other applications which are currently executing.
See the numerous articles on the Windows 8 app lifecycle.
With the advent of the new marketplaces, Microsoft disallows certain language and content in certain marketplaces.
For example, the Chinese, Indonesia and Malasya markets do not allow references to alcohol - any references to alcohol.
One of my apps has a single string that contains the word "alcohol" in it and is thus disallowed. I was wondering if there's a progammatic way of discovering what marketplace a phone is attached to and thus remove the string in those cases.
I can of course submit 2 different XAPs to the marketplace, but I would hate the hassle of doing that.
There is no API to guarantee to return which marketplace the LiveID of the currently logged in user is associated with. Even if there was there would be no way to test this on the emulator, as it doesn't allow you to log in so you'd need multiple accounts, each with different marketplaces and to avoid the need to repeatedly hard reset your device you'd probably want multiple devices too. (THis may or may not be an issue for you.)
For your situation you'll need to submit multiple XAP files or remove the alcohol reference from all versions. The verification for this requirement is not done with devices associated with each marketplace but typically just done on a single device and so attempts to get around your situation in the way you've described wouldn't work.
Alternatively, you could localize the app appropriately and just not have that section in the localized versions for those countries. I'm not sure if that would be enough to meet the marketplace requirement though as users in those countries could still set their devices to another region/locale.
As a general guide, you could attempt to infer the marketplace the user is most likley to be connected to based on their location or regional settings but this wouldn't be guaranteed. Asking (to confirm) would be the best bet, but not in your scenario.
I'd interested in sending data from one WP7 to another WP7 phone so I could create 2 player games. If I understand correctly most WP7 will support bluetooth, but its not in the minimum spec, is this correct? What API's can I use to access the bluetooth, any good examples of this out there?
Unfortunately Microsoft don't provide any access to the bluetooth stack via any documented APIs in this version of the Dev tools.
They don't seem to have any sense of urgency about fixing this (or any of the many other missing features), so I wouldn't expect the situation to change any time soon.
I have an application for Windows Phone 7 that I need to bundle up and send to several doctors for a content review. Ideas on how this might be done? I can't expect the docs to install the full SDK, but if I could bundle the emulator with it that might work, or if there's an easy way to convert the app to a Windows EXE that would as well. All suggestions welcomed!
While the theory is that since it's SIlverlight it should just run on the desktop. Years of Compact Framework development have taught me that this theory is almost never correct and getting it to work is often a real chore.
Microsoft has not yet delivered a stand-along WinPhone emulator (no idea if they will, but they did for WinMo) so for now that option is off the table. Getting your end user to install the stand-alone emulator is a fair bit of work anyway.
To be honest, my experience has been that just doing a Camtasia capture of the developer screen while you step through the app is one of the easiest ways to get ideas across to these types of groups. No, the end result isn't interactive, so they can't clock on buttons themselves, but if you walk through the feature they want to see, you can usually answer 95% of the questions this way.
When you need to address that other 5%, my experience has been that it's easiest to just send them a physical device with the app installed.
If they are (or have ready access to someone who is) fairly tech-savvy, shipping a Virtual PC image of a PC with the emulator installed and the app installed on it sometimes works.
Dot NET code using MS libraries is partially upwards compatible and most runtime classes present on a mobile device are also available on desktop Windows (see MSDN docs for details). So create a copy of your source code, ask visual studio to create a desktop .exe from it, it'll tell you it can't for several reasons, and you will need to recode some sections of it, resize the frame window etc. to make it work.
If one is careful about what methods one uses, I have managed to actually use the exact same .EXE file on the desktop without problems!
You simply cannot present the application without the SDK, since Windows Phone 7 applications rely on a completely different subset of .NET Framework and require an emulator to run XAP packages. Although you might say that it's the same Silverlight, don't forget about Microsoft.Phone and derivatives - you need the SDK in order for those libraries to be properly handled.
Also, you cannot convert a WP7 application to a Windows executable due to difference in platform architectures.
What you could do is simply allow the doctors to test your application through TeamViewer or similar products.
i think a "killer app" for winphone7+silverlight would be a desktop browser based emulator. want to try the app? just have the store run the emulator in the browser. (yeah, lots of technical hurdles, limited multitouch etc, but it would be pretty slick!)