I have a product live on a network operators portal at the moment, it is integrated with the operators SMS/MMS messaging and billing interfaces. I would like to build a version of this application to run on Windows Phone 7 devices.
I'd like the application to run for all users but for users that happen to be on the network operator I've integrated with I'd like to offer them a better experience (direct operator billing and sending through the operators MMSC).
An alternative would be to limit the availability of the app to users with handsets on the operator (like the Android marketplaces that exist for the major cell network operators like Verizon and Sprint).
Is any of this possible on the Zune Marketplace for apps and/or on Phone 7 devices?
Thanks
To accomplish this I would suggest liasing with your network operator contacts.
You'll need access to the APIs which they have access to (and the public does not through the 3rd party SDK).
You may also want to ship an app with phones they supply also.
Related
By Google Home Sample App for Matter, it seems nothing we can know about the device clusters from the device after commissioning.
// commission
Matter.getCommissioningClient(context)
.commissionDevice(commissionDeviceRequest)
After commissioning, it did the addDeviceState.
val newDeviceState =
DeviceState.newBuilder()
.setDeviceId(deviceId)
.setDateCaptured(getTimestampForNow())
.setOnline(isOnline)
.setOn(isOn)
.build()
But why it knows there is a setOn() for the device? How to know what clusters the device has?
I have read the Google Play service Matter API but there are only commission and share APIs. Are there Matter devices setting function list?
As mentioned in https://developers.home.google.com/samples/matter-app?hl=en
Note: The sample app currently only supports devices that have the On/Off server attribute, for example lights, smart plugs, and fans.
Due to this, the app always assumes that any Matter device that is commissioned via GHSAFM supports the on/off cluster.
When a user buys a subscription on CH Play, can I use the server to verify and then update the subscription on the iOS App side and vice versa?
However, Apple has a policy stating that: Guideline 3.1.1 - Business - Payments - In-App Purchase - Your app unlocks or enables additional functionality with mechanisms other than the App Store, which is not appropriate for the App Store.
That means the user has to buy again.
So How should I do mobile app cross platform payment?
Should I create a lot of offer codes?
Or refunding the user after buying twice is still a solution?
That means the user has to buy again.
No, you can buy subscription from Android or web and when you login into your account on iOS device you will find your subscription active. this is do not violate Apple's Guidelines (e.g. Spotify is doing this)
You should handle the subscription from server side to verify if the subscription paid on the original platform.
UPDATE:
3.1.3(b) Multiplatform Services: Apps that operate across multiple platforms may allow users to access content, subscriptions, or features they have acquired in your app on other platforms or your web site, including consumable items in multi-platform games, provided those items are also available as in-app purchases within the app.
I would like a Teams user to video call an other Teams user using external hardware (usb camera) and using mobile devices (android first).
What can Teams apps do?
...
Collaborate on items in external systems. One of the core scenarios
for a custom Teams app is to bring information or items into Teams
from some other place, and have a conversation around it. You can push
information into Teams, enable your users to search for and pull it on
demand, or make it available in an embedded web view.
Source
I guess I could develop a small web application and a server which could act as a bridge.
Android app streams a video to my webserver, teams web app loads video stream from my server. Could that work?
I've found some other people asking similar things, and they did not get an answer.
https://techcommunity.microsoft.com/t5/Microsoft-Teams/SDK-for-Microsoft-Teams/m-p/261008
The easiest would be, if teams had a real sdk, but it seems to me, that it only has support for very limited "plugins".
Currently This is not supported in Teams.
I want users to be able to buy tickets via Windows Phone application and do not want to use web browser for these purposes. The ticket price may be different.
Is it possible to process payments via Wallet app or integration with certain processing systems is required?
Also please suggest the best practices for purchasing process within Windows Phone app.
This isn't that accurate but, you can use a paypal address creator and a webbrowser component.
try to do this (needs another server :( - try a free one )
http://webdesign.about.com/od/ecommerce/a/create-a-paypal-shopping-cart.htm
I have a desktop application which uses flat files (some xml and small pictures) as data. I want this data to be available on other PCs which have the desktop application installed and usable by a smartphone client (WP7 at the moment) as well.
The user should have it very easy to synchronize this data. He should be able to use accounts he already possesses (Live-Login, Googlemail, Facebook,...).
I thought about using Azure Blob Storage to save the data in Azure, the Sync Framework to perform the actual synchronization and the Access Control Service to handle authentication.
I have not used any of this technologies before so any advice would be great but I'm searching foremost for errors or shortcomings in this strategy I don't see yet. Is this approach viable at all?
Windows Azure is basically a virtualized datacentre. It is elaborate and complicated and is pitched at corporations who don't want to own their server infrastructure or hardware.
If I understand correctly, what you want is a cloud fileserver, not a whole LAN. Windows SkyDrive fulfils this requirement nicely and offers 25GB of storage per member with no charge for membership.
About Hotmail and Windows Live People often confuse Hotmail and
Windows Live, because when you set up a Hotmail account it uses
Windows Live for authentication and therefore you end up with a
Windows Live account and all the associated facilities, including
SkyDrive. However, it is entirely possible to set up a Windows Live
account using any email address as the username.
If you do this, it is important to be aware that the Windows Live
password associated with a given email address is completely
independent of the password required by the mail server that hosts
mail for the account. This can cause a great deal of user confusion.
For Hotmail (or any other mail server that uses Windows Live for
authentication) they are guaranteed to be the same password.
There is no official Microsoft framework support for SkyDrive. There is an open source project called SkyDriveApiClient, but it only works with the full .NET framework. I tried porting it but the author was a bit of an architecture astronaut, and it is absolutely riddled with [Serializable] which is not available on WP7x.
The WP7 guys have said that the WP7 framework will probably include support for SkyDrive but not in Mango (WP7.1) and given that Microsoft's typical release cycle is 18 months and Mango has yet to hit the streets, I'd say it will be two years before you can count on intrinsic cloud file services for WP7.
Roll-your-own wouldn't be hard, WCF services are dead easy to use from WP7. But that's not really cloud since you have to provide and maintain the server infrastructure yourself. For this reason and given the MS timetable, I have put a great deal of effort into producing my own SkyDrive client for WP7. Core functionality is complete and I am now refactoring, improving robustness and adding performance enhancements like local cacheing of tokens (cookies, essentially). I don't intend to release it; I have a number of apps planned that depend on this functionality and it suits me fine that there is a substantial barrier to competition.
I didn't tell you that to tease you. My point is that I'm so sure SkyDrive is the right answer that I put a lot of work into making it happen.
Cloud file storage is a perfect fit for mobile devices.
Azure is not a good answer for the sort of phone apps individuals want because the data store isn't shared in a way that required indexing or supports high levels of concurrency
I can certainly think of corporate phone apps that would benefit from using SQL Server as storage
Azure can do file services but it represents an ongoing expense. Nobody's going to put up with that when Google and Microsoft both give away web based cloud storage.
I can personally attest that if you're determined, it is possible to use SkyDrive from WP7.
Cloud storage is the only way you're going to get programmatically accessible storage that's shared by your user's mobile device and his computer. One of the things I intend to do that depends on shared storage is write a Silverlight app that lets you prepare map routes with multiple waypoints on a desktop computer and a companion app that uses them on WP7.
The Windows Live team has released what they call support for WP7. They supply a sample project showing you how to instantiate a browser object and load their login pages and manipulate them to log in and use their javascript API to manipulate SkyDrive.
This has one big advantage: browser cookies and cached credentials. The disadvantages are obvious; technical shortcomings notwithstanding the Windows Live team seems to think the only thing people want to do with a phone is tag their photos and fiddle with social media.
I have finished my own libraries. They do not support most of the social media twaddle. I have treated SkyDrive as no more or less than a cloud file system, providing
Authenticate(username, password)
CreateFolder(folderpath[, blocking=false])
Delete(fileOrFolderPath[, blocking=false])
SaveString(filepath, value[, blocking=false])
LoadString(filepath)
I could handle binaries but Convert.ToBase64 makes this unnecessary and strings are convenient for XML. CreateFolder, Delete and SaveString are optionally blocking. LoadString is always blocking because it's a function that returns the loaded string. CreateFolder is recursive so you can create an entire path in one call (eg /folder1/folder2/folder3). Calling CreateFolder on a pre-existing path has no effect, and SaveString uses CreateFolder to ensure the path is valid, making it unnecessary to create a filepath in advance. Authenticate loads the file system (except file content) into memory eliminating server chatter. This is asynchronous and a FileSystemReady event announces when the file system is completely loaded. The model is maintained as you add and remove files and folders.
This was a lot of work and no one reponded to my attempt to make it an open source project so I'm not inclined to give the fruits of my labour away, but provided your plans don't compete with mine I could be persuaded to come to an arrangement.