I am developing a game using cocos2d-x and I want to port it to Windows phone 8 as well as Android.
I plan to make the game free with in app purchases. But I do not yet know how to do that in windows phone 8 with cocos2d-x.
Has anyone else tried to do it before and succeeded with WP8?
Currently working on a project that will do that Cocos-2d-x running on Win8 and WinRT. Haven't gotten to the in-app purchase part yet, so don't take this as gospel, but my initial research indicates that it'll need to go through the XAML layer.
The trick isn't the In-App Purchase itself, as Microsoft seem to have the API for that fairly well covered; the trick is getting your Cocos2d-x modules communicating with the XAML layer. Unfortunately, currently nobody has made a good interface between the two, so you'll have to make your own. I'm not looking forward to that myself either.
I assume you need something now. What I can do is point you toward some resources that will help.
In-App Purchase in a Native C++ App: Windows Phone Dev Center
Trial App and In-App Purchase Sample (Windows 8.1)
Related
Windows Phone got my attention recently with making iOS and Android apps convertible to Windows Phone apps using Windows Bridge. I am eager to know if libgdx support translation to windows phone apps with Bridge tools? Has anyone any experience with it?
Well, the bridge is under construction still so you're not likely to get much feedback here. LIBGDX hasn't concentrated on Window's phone, but I think they've created an x86 DLL for some of their unmanaged code a while back. Not sure on the status of that.
I used a similar bridge technology for Blackberry in the past. The process was simple and only required installing plugins and executing a conversion tool on my Android APK. No code changes.
However the site for the Window's phone bridge says minimal code changes may be required. I'd speculate the process will be extremely simple so as to encourage releases of popular apps onto their platform. If Microsoft makes the process complicated, developers aren't going to bother.
We are planing to develop new app .It has VoIP feature and app is similar to whatsapp.
Since the app has Voip feature we have to go with WP8 silver light. Winrt for WP is not supporting VOIP api.
Can we guess almost all the WP8 devices are upgraded to WP8.1 ? If there are large user base still remains in WP8 we will develop the app using WP8 api's (Using VS2012). Otherwise we will go with WP8.1 api's (using VS2013).I heard there are few performance improvements and controls are available in WP8.1
Any suggestions on this ?
Thanks in advance
All Lumia phones can be updated to WP8.1 and a huge part of users so did.
Just an article for reference: http://www.engadget.com/2014/04/02/nokia-lumia-windows-phone-8-1-update/
On my apps I use analytics to track users and I hardly see few users stuck with WP8.
Update - market share
http://www.gsmarena.com/adduplex_wp81_market_share_surpasses_wp80-news-10062.php
This article is from last October, WP8.1 has been out for about 5 months and it had already surpassed WP8. I let you think the actual quota...
Should you go with WinRT? It depends on your needs. Of course you should use at least WP8.1 Silveright (not WP8). But if your application does not require specific functions only available in WinRT, you might go with WP8.1 Silverlight, since WinRT has still many little performance issues.
There are a lot of new available APIs and features either for WP 8.1 Silverlight or WinRT. I would definitely target 8.1. Users still using WP 8.0 probably don't care that much about apps anyway.
I have to implement "in-app purchase" both for Windows 8.1 and Windows Phone 8 app. The API looks the same for both platforms, besides one method: "CurrentApp.ReportProductFulfillment" (only WP has it). However, both platforms have "CurrentApp.ReportConsumableFulfillmentAsync".
My preference is to write fully reusable code (same code) for both platforms, if possible. MSDN documentation is not clear enough, so I want to understand:
Can I use ReportConsumableFulfillmentAsync on WP instead of ReportProductFulfillment? Are they have the same functionality? (maybe they left ReportProductFulfillment for backward compatibility).
Do I have to call ReportConsumableFulfillmentAsync after buying consumable only, or after every store purchase?
Thanks!
According to MSDN ReportConsumableFulfillmentAsync is Windows Phone 8.1 API, so you cannot use it when creating Windows Phone 8 apps. Stick with ReportProductFulfillment and Windows Phone 8 apps for now, it will take some time for Windows Phone 8.1 to get on the market
Only for consumables
If your are looking or a nice in-app wrapper, take a look at this https://github.com/igorkulman/Kulman.WP8/blob/master/Kulman.WP8/Services/WindowsPhoneStoreService.cs
So, our Windows Phone developer left recently, and I primarily do Android development.
We had a question from a client about the possibility of installing our Windows Phone 8 app on a Surface Tablet. Namely, is it possible to do? As it stands, our WP8 app was not written with tablets in mind, so my question is:
Is there anything I need to do to the WP8 app to get it to install on a tablet, (should it work as-is (like Android apps do), is there some sort of flag I have to enable and then rebuild, etc.?)
As #AMR mentions, the biggest challenge will be the UI; however, depending on the device functionality being used, the "backend" may or may not be a challenge as well.
There is great guidance on the Windows Phone Dev Center about practices and techniques for building for both platforms, so depending on when the phone app was built and your former developer's awareness of the overlapping platforms, you could be in great shape or just so-so shape.
Additionally, the following resources may be of help in mapping from what you have already coded in Windows Phone 8 to what you'd do in Windows 8:
XAML controls comparison between Windows Phone 8 and Windows 8
(much will be relevant to Windows Phone 7 too)
Windows Phone 8 and Windows 8 platform comparison (shows common
APIs, storage, networking, etc.)
Lastly, the Windows Phone Runtime API documentation gives a listing
of APIs only on Phone 8 vs. APIs adopted from Windows 8.
Okay well first off yes, there will be a few things that change but nothing to serious.
HOPFULLY you have a good MVVM model. If this is the case then you should be able to just copy and paste 99.999% of your backend code right into your tablet app. There are a few things that are different but its just namespace stuff. Nothing too serious.
The Major change is going to be your UI layout and UI controls. Depending on what libs you are using you will probably have a lot of conflicts.
Your best bet is to just copy and paste your backend code in and then creating a new UI. I have tried to merge phone UIs in the paste into the tablet and its rediculous at times. I found it takes less time to just recreate it.
If you need any help you can hit me up at www.AnthonyRussell.info Maybe I can help with your transfer. Just make sure to leave your contact info.
I recently started doing some development in the Windows Phone 8 OS I'm pretty new on this. I was doing some searching about the fact to create an app who play any audio for some specific events/actions.
I was reading the Windows Phone API reference from Windows Phone Dev Center http://msdn.microsoft.com/en-us/library/windowsphone/develop/ff626516%28v=vs.105%29.aspx#BKMK_Win32andCOMAPIforWindowsPhone
But it seems a little confusing to me at first glance and I have the doubt of which one of the following should I use to accomplish my task.
The .Net API for Windows Phone
Win 32 and COM API
... or the Windows Phone Runtime API
Any help would be very appreciate
It really depends what you're trying to do. If you're writing a native application or are interested in cross-compatability with Windows 8 then XAudio2 or the WinRT APIs are definitely the way to go. If you just want to play some infrequent sounds (say, when you pop up a warning dialog) from within a XAML app then I have seen a number of approaches, teh easiest of which is probably just having a MediaElement in your XAML that you use to play the audio.