I am starting first project for Windows Phone and it should work on at least Windows Phone 7.5. My question is if should I write app on Windows Phone 7.5 or should I write two app versions - once for Windows Phone 7.5 and another for Windows Phone 8?
I know that app which works on WP7.5 will also work on WP8 but what would you recommend? What would you do?
If you think that writing two apps for both versions is a better idea then should I write app on WP8 first and at the end remove special WP8 features to downgrade it for WP7.5 or maybe I should write WP7.5 app and then add some WP8 features to upgrade it to WP8?
I am asking because I want to learn WP developement and I have two tutorials: "WP7 jumpstart" and "WP8 jumpstart" tutorials (from MSDN) and I am wondering If I can skip WP7 and start directly with WP8?
Standard way will be to create a Windows Phone Class Library that will contain all the code except Page, View or Windows 8 specific code and than create Windows Phone App and set dependency to above created Library project. Now as Rowland Shaw as suggested you can target the Windows Phone app to 7.5 so that it will work for Windows 8 as well and if you want to use any Windows 8 specific API you can create separate application with same Library reference so that all the common code will not be duplicated.
Referr MSDN Link for the same.
If you wish to normally support all screen sizes, you should create 2 apps. Because WP7.x supported only 1 screen resolution, and running on WP8.x with larger screen the app will remain small size.
You would have to use WP7.5 if you are not going to impelement any feature which is present in only WP8
Related
I am new to windows 8 app development I just want to know that it is possible to make one app package which will run both on windows tab and windows 8 phone [For example in case of iOS same ipa can be installed on iPhone as well as iPad]?
I know win 8 phone and win 8 tab/desktop have different sdks and and coding sharing can be possible. But can I make one common package to run it on both platform.
No it's not possible. WP8 app packages are .XAP files & Windows 8 apps are .APPX/.APPXUPLOAD files. You can use various code sharing techniques like MVVM, PCL, etc, but you can't create a single file which acts as installer for both.
Maximize code reuse between Windows Phone 8 and Windows 8
As Xyroid explained they have different file name for apps. And since you compared to iOS, let me tell you that iPhone and iPad is basically the same device, with same architecture and same OS, with different screen resolution(if you ignore the calling function), so one IPA which works on iPhone, can work on iPad too.
While Windows 8 and Windows Phone 8 are two different OS, based on some common code and runtime, but they do actually have different app handling layers. They even have some different UI component. You can make a library (dll) which can work for both if it's just fetching data from a particular server or provides some low level functionality. But for creating single package which can run on both is a different thing. Even if they'd be using same file name, the internal codes and runtime can't be changed.
PS: WinRT apps can work on Windows 8 too, since WinRT is a stripped down version of Windows 8(without desktop app).
Now that the 7.8 update is coming to WP7.x devices, how can I handle the multiple tile sizes an app can offer?
What changes do I need to do in the AppManifest?
The SDK can be downloaded from here. Please help as I am not able to find a good resource till now.
Have a look at this blog post, it describes the changes, and references a MSDN article on how to set that up.
Another option is to use a CodePlex project called MangoPollo.
Mangopollo will allow you to easily take advantage of new windows phone tiles (cyclic, flip, iconic) if your application is run from a Windows Phone 7.8 or 8 as well as new launchers if your application is run from a Windows Phone 8 while remaining compatible with windows phone 7.
very straight forward question. My company has developed a windows phone 7 app and have been testing it on a windows phone 7 device. Can we safely assume that the same app will be backwards compatible and work seamlessly on a windows phone 8 device such as a Nokia Lumia 920?
Thanks in advance!
Yes it will work. But it won't take advantage of all the WP8 features like a real WP8 app would. I'd suggest that you create a copy of the project and update it to WP8 for a better performence. Also replace any listboxes with LongListSelectors for example.
In most scenarios it should just work, but you should check this list of known breaking changes and you should also test your app on new devices thoroughly, just in case.
For example FMRadio class is no longer working on WP8 and there are other similar issues:
App platform compatibility for Windows Phone
I am iphone and android developer.I know how to use phone gap for iphone app and android app development.But I am new for windows phone 7 app development using phonegap.I dont know how to start windows phone 7 application development using phone gap.
Please give me advice for this query.
Thanks in advance.
Looks like PhoneGap doesn't support Windows Phone yet.
This post seems to suggest its close though and there is an alpha/beta you can start developing
http://programmersgoodies.com/phonegap-for-windows-phone-7
PhoneGap support for Windows Phone 7 is still in a "pre-alpha" state.
From a practical stand it's not realistic to start developing with it. Some people have started (and apparently submitted apps based on it) but there is no guarantee of future compatibility with what they've done.
When available, it will also only support phones running Mango.
How can I launch a Windows Phone 7 app programmatically?
I want to launch a custom app built by me from another app built by me.. and hopefully be able to pass parameters.
I don't believe you can. As far as I'm aware, the interaction between applications is limited to the Microsoft.Phone.Tasks namespace.
I would personally expect this to be one of the aspects of Windows Phone 7 development to be improved pretty soon.