Future of Windows Phone support?

[mikko.nu...@gmail.com]

Hi,

what is the outlook of Windows Phone platform support? After iOS and Android versions I managed to create an installing version for Windows Phone. This required code changes that identified the running device's platform as WP and thus using my own classes (in some points) instead of Java's (like SimpleDateFormat) because of NotYetImplementedExceptions. I also had to change some UI-component arrangements because events were not always launched. The running application is graphically blurry and lagging, and the previous form seems to haunt in the background. Customer stated that the app is simply not applicable.

I understand that the WP is globally fading platform and Android & iOS are your priorities (would be mine too). But I would like to know for customer's sake is there going to be fixes / or optimizations to issues such as I mentioned? My customer's devices are sadly ~50% Nokia / Windows phones but the number is naturally counting. We still need the support for WP and I need to know should we use Codename One to do it or "do it by hand"?

[Shai Almog]

Hi,
we are having this discussion internally too. Up until now we were waiting for the Android compatibility on Windows Phone that Microsoft promised.
Last week they suddenly canceled it demonstrating their lack of commitment to the developer community in general and exactly why we had issues with the moving target that is Windows Phone.

There is great community work from Fabricio https://github.com/Pmovil/CN1WindowsPort which we might adopt but it will only solve half the problem. The other half is the VM.
We do have our own VM so we should be able to port it to Windows universal app generation and initially when we designed it this was within the goals.

The effort involved in doing this work is pretty big and we still don't have a single enterprise customer asking for this, I tried to appeal to several developers who complained in the past to help with the effort (by signing up to annual enterprise subscriptions) and not a single one was willing to show any commitment here.

Right now we have 3 options for Windows targets:
1. Existing port + work from Fabricio - this is flawed but can be made to work with some effort.
2. Desktop builds - Very few people care about windows phone, they mostly want surface tablet support and this works for the surface (not the dead end RT though).
3. JavaScript builds - these work for all devices and should work for Windows Phone devices.

[mikko.nu...@gmail.com]

Hello,

thank you for your comprehensive and instant answer. I will pass on the information you provided.

[mcw]

I realize you have to make money but this focus on what enterprise customers want has bugged me for a long time. I have been a pro customer since the early days, but I simply cannot afford an enterprise subscription. Does that mean my needs don't count?

Windows Phone support has been an issue for me for a long time as you know. I need Windows Phone support, Desktop builds won't cut it, JavaScript builds wont cut it as long as this is an enterprise only feature.

I think CodenameOne needs a Windows Phone solution to be taken seriously.

[Shai Almog]

We just spent several updates and risked regressions in deployment for a relatively niche request you made to support 5.x which is apparently a bit painful.
We appreciate our pro subscribers especially the long time subscribers and we do value you more than a guy that just signed up for an enterprise subscription yesterday.

This isn't about making money!
"Proper" Windows Phone support requires a new VM since the problems there exceed the existing XMLVM support which is very broken. Unfortunately there are no easy answers here. Its possible that a shortcut has arisen since our old investigation here but currently we estimate the effort of porting the new VM and then adapting the existing C# port to work with it as about 18 months worth of work.

We can divide it between several developers but if I take pretty much our entire development team off rotation this will hurt everything else we do!

Unfortunately as a startup our revenue can't possibly cover hiring additional people "just to do this". 2 enterprise developers won't make enough of a dent to hire an additional team member but at least it would indicate commitment and if community members are willing to spend we'll spend on our side. If you do a back of a napkin calculation on the cost of the developer and what we are asking you would understand that this has nothing to do with "making more money" and everything to do with commitment.

This was something we thought we could skip thanks to Microsofts Android support, unfortunately with their usual flipflopping we ended up back where we started.

But put yourself in our shoes, would you want to start spending that much money and then MS will flip back and release Android compatibility rendering our efforts worthless?

I totally understand the inability to spend on an Enterprise license and it is in no way our intention to pressure developers to upgrade to plans that they can't afford.

[sidiabale]

Hi Shai,

Does any of the three options for Windows Phone support you mention above provide native code / native interface support? If not, then in reality there's not quite a full Windows Phone solution...

[Shai Almog]

Hi,
yes. The community port supports that and the desktop port supports writing JavaSE "native" code in Java which provides you access to almost anything.

I'd like to be perfectly clear here: we want a native windows 10 port of Codename One.

The problem here is one of scheduling vs. a moving target. MS changes strategies in midair.

We already made 3 attempts to chase that target (which took a lot of resources, this is by far the hardest platform port we had to deal with!).

Our desire for enterprise backing correlates to the speed and risk we are willing to take to chase this moving target, not whether we'll *eventually* get there.