Windows support #254

Open
valentinstoychev opened this Issue Jun 1, 2015 · 106 comments

Projects

None yet
@valentinstoychev
Contributor

This is a work in progress at the moment, but having your feedback and comments can increase its priority. We are planning Windows10+ support at the moment.

At a high level the tasks are as:

1.7

Not planned

  • Implement the cross-platform layer on top of the runtimes to support the Windows UI.
  • Implement support in CLI

If you are interested in this feature please add comments below with specific requirements and vote for this feature in our ideas portal.

@valentinstoychev valentinstoychev changed the title from Windows WinRT mobile support to Windows support Jun 3, 2015
@nemephx
Contributor
nemephx commented Jun 3, 2015

Not sure if Win10 will support Silverlight dev for mobile, but I'd say focus only on the universal APIs.

@fealebenpae fealebenpae self-assigned this Jun 4, 2015
@Klors
Klors commented Jun 11, 2015

This would be very useful as it would allow us to attempt to use NativeScript (with our existing web development knowledge) as our corporate cross platform mobile development solution.

+1

@alejonext

+1 i dont have windows...

@karundeepyadav
  • from my side. Looking for windows this support..
@enchev
Contributor
enchev commented Aug 11, 2015

You can run now Android applications on Windows Phone 10 including {N} apps: https://twitter.com/ligaz/status/630996030864142336

@RonaldV
RonaldV commented Aug 12, 2015

+1 for native Universal Windows app support.

@calebeaires

+1

Focus on Windows Universal APIs

@maury91
maury91 commented Sep 4, 2015

+1

@danicomas

+1

@phiphamuet

+1

@phulst
phulst commented Sep 15, 2015

+1

@divyan
divyan commented Sep 16, 2015

+1

@rui-cruz

+1

@kaurag007ph

+1

@johnmurphy01

+1

@MarkEwer

For the consumer market, Android and iOS support is all you really need. But, I work in the corporate market so Windows support is a must. BTW, support for Mac desktop apps in addition to Windows Universal would round this out into the only platform I would need.

@DenisBazhan

+1

@thuffamatwork

+1 and (I suspect off topic) support to compile/translate into a true web project.. that would rock.

@sandorfr
sandorfr commented Oct 5, 2015

I think this should be a top priority. There are already plenty of xplat frameworks without decent windows support. This would make a huge difference.

@burnsting

With Windows 10 and its new Universal App Platform already running on over 110 million desktops worldwide, I'd say this is a must. Coming holiday season a lot of laptops, 2-in-1's, etc will be sold, and most of them will be running Windows 10. No matter how you look at it, Android dominates mobile (with iOS taking a sizable chunk as well), but Windows dominates the desktop. And I'd love to bring the apps I'm developing to these people sitting behind a computer every day.

I think the Microsoft people have been pretty helpful with Phonegap, and getting every type of developer being able to develop apps for their platform. They're even working on support for Java, Objective C for native apps. So maybe the Telerik people should get in touch with them. I think they'd be happy to help. Just a thought..

@mtringuyen

nativescript should be available for windows mobile asap :)

@RenaudParis

+1

@sidewinder

+1

@Debugreality

Looking for windows/ios app that supports pen devices and NativeScript is looking very promising (with this feature).

@TryingToImprove

Is anyone working on this?

@gabbered

👍 Need Windows 10 support

@alexrainman

+1 for WUP

@valentinstoychev
Contributor

@TryingToImprove We (the core team) have an internal POC app working on Windows, but for the moment Windows is not the focus of our priorities, so the release of Windows 10 is not scheduled.

Right now the team is focused on polishing the existing iOS and Android support and after that we will focus our energy on the Windows 10 support.

If you have a project that is dependent on Windows 10 please reach out to me and we will discuss in detail (valentin.stoychev@telerik.com). The team here have a solid Windows Universal knowledge and we are eager to work on supporting it, but first we should make sure the current bits are top notch and then move to Windows. If there are developers that would like to help us in the Windows 10 support please reach out to me as well.

@pjc2007
pjc2007 commented Nov 11, 2015

Certainly interested in W10 support. More likely for tablets than the phones.

@amjd
amjd commented Nov 14, 2015

Is there any ETA on when Windows support is going to be added?

@corbinu
corbinu commented Nov 16, 2015

I am curious has anybody looked into using: https://github.com/Microsoft/WinObjC/ I know it is not feature complete yet, but seems like once it is that it might be a good shortcut.

@mrpatiwi

+1

@preco21
preco21 commented Dec 18, 2015

+1

@falkoni
falkoni commented Dec 22, 2015

+1

@jordanhart

+1
ETA please on windows universal support.

@NathanaelA
Contributor

@valentinstoychev not sure if you saw this but: https://github.com/Microsoft/ChakraCore was released...

@triniwiz
Contributor

+1

@milesxu
milesxu commented Jan 18, 2016

+1

@napsio
napsio commented Jan 25, 2016

+1

@Happy-Ferret

+1

The one feature that definitely needs to be supported though are tile notifications.
I use them fairly recently, to inform the users of all sorts of news, updates and general progress.

@valentinstoychev valentinstoychev added this to the 1.7.0 (Under Review) milestone Feb 8, 2016
@fealebenpae fealebenpae removed their assignment Feb 9, 2016
@JeroenOnstuimig

+1
Thanks for putting it back on the roadmap.
We need this for a client who uses Windows Phones internally. Our app requires basic UI and the push notification plugin.

@jmoleiro

+1

@geminiyellow

+1 need Win 10 Support

@valentinstoychev
Contributor

Hey everyone - I want to talk with as many people interested in the Windows Universal story as possible to hear the specific scenarios you are after. This will help the team execute on this task with optimal force. Please contact me over email so we can start a discussion - valentin.stoychev@telerik.com. I will love to hear from you!

@gfalves
gfalves commented Feb 21, 2016

+1

@romanejaquez

+1

@icode
icode commented Mar 14, 2016

+1

@icode
icode commented Mar 14, 2016

It have not yet begun? 😭

@valentinstoychev
Contributor

The first step is done for Windows support!
https://www.nativescript.org/blog/nativescript-runtime-preview-for-windows-10

@RenaudParis

Congratulations to all who worked on this!!

Le jeu. 17 mars 2016 16:11, Valentin Stoychev notifications@github.com a
écrit :

The first step is done for Windows support!

https://www.nativescript.org/blog/nativescript-runtime-preview-for-windows-10


You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#254 (comment)

@enchev enchev removed this from the 1.7.0 milestone Mar 22, 2016
@valeriob

Nice !

@DomResc
DomResc commented Apr 27, 2016

good to see that work goes on!

@mcler
mcler commented May 5, 2016

+1

@tonystar
tonystar commented May 7, 2016

+1

@namnv609

+1️⃣

@denkomanceski
denkomanceski commented Jun 2, 2016 edited

+1

@sjcostaneto

+1

@jiafuzhang

+1

@manuelro

+1 - I'm currently working on a project for which I need to generate three executables: iOS, Android, and Windows Phone. iOS and Android are covered by NativeScript, but it stills lacking Windows Phone support. Any advice would be really appreciated.

@napcat
napcat commented Jun 28, 2016

+1 for uwp apps! whats the current development state?

We are developing many apps for android, ios and windows 10 with push notifications integration, google maps services, etc. We are thinking on change our development from cordova to nativescript, but the lack of windows 10 support is holding us from that change.

@sdmarshall

+1 I manage several cross platform Cordova based apps and would love to migrate all over to NativeScript as soon as Windows support is available

@kwong93
kwong93 commented Jul 7, 2016

+1

@ducktype

Corporate market requires windows PHONE/MOBILE support very often, please add support asap!

@NCC1701M

+1

@silentHoo

+1

@manitra
manitra commented Jul 17, 2016

+1 as previously mentioned, even if the windows phone ecosystem is dead, the windows ecosystem is not (windows desktop, xbox, surface ..)

@jimjones26

+1

@simi2525

+1 it would highly increase the usefulness of the platform

@manojdcoder

+1

@Element-Dong

+1

@cloudcrypt

+1

@leonletto

Related I believe. https://www.infoq.com/news/2016/07/chakracore-linux-mac If NativeScript uses ChakraCore as the gateway to Windows Universal apps, it looks like they may also get Linux and MacOS support in the bargain 👍

@enchev enchev added the T:Feature label Aug 8, 2016
@eramella

+1

@jvitor83

+1

@dpossidonio

+1

@batorskik
batorskik commented Sep 8, 2016 edited

Definitely +1 for scheduling this as soon as possible.

@jasssonpet jasssonpet referenced this issue in NativeScript/windows-runtime Oct 3, 2016
Open

Metadata #3

67 of 71 tasks complete
@harangue
harangue commented Oct 28, 2016 edited

Even if Windows 10 Mobile fades to complete irrelevancy (and personally I think it's going to be stubborn and stick around for quite a bit longer), targeting UWP is really important for other form factors as well if NativeScript gains support for them.

@nazrdogan

+1

@joshcomley

+1 - is there any update on whether Windows Phone support is coming? The GitHub repo hasn't been touched since May, but the nativescript.org site still refers to it as "Coming soon". Would be amazing.

@triniwiz
Contributor

@joshcomley if you check out NativeScript/windows-runtime#3 you will see work is currently being done the meta is almost done 😄

@phanikiranwtc

+1

@elmawardy

+1 want to be universal 🚀

@Steviey
Steviey commented Jan 10, 2017 edited

Comming soon + Latest commit 2181741 on Mar 16, 2016...
...I'm confused.

There are a lot of misleading infos out there...

"Build native iOS, Android and (soon) Windows apps from a single code base
using The NativeScript Framework"
"Windows Phone support will join hands in version 1.0 which is scheduled to release in Jan 2015"

Would be nice to have a decent statement.
+1
Image of Yaktocat

@valentinstoychev
Contributor
valentinstoychev commented Jan 12, 2017 edited

Hello @Steviey, we tried several approaches to get the Windows support land in NativeScript unfortunately currently there is no "efficient" way to achieve it without a significant effort from the core team.

In the windows runtime repo you can see that we tried using JavaScriptCore. We also tried using the Chakra and also the ClearScript framework. The ClearScript framework was a very good solution but it allowed us to build only desktop apps (not windows universal). The option with Chakra engine is possible, but if we choose that way we will need to implement again all the plumbing we have done for iOS and Android which is a pretty significant effort. This means new debugging, profiling, packaging tools. Not to mention the cross-platform abstractions. This also adds to the maintenance cost of the project a lot.

So in short, there is no easy way for us to enable Windows as a first class citizen in NativeScript at the moment. We have several options to implement this, but the effort required for this task is setting a lower priority that the other tasks we have. We still have several big initiatives to polish around the iOS and Android story.

At the moment it will be hard to give a proper ETA for Windows support. Our wish is to start working on the Windows repo sometime in the summer, but this is the only ballpark estimate we can give.

If someone from the community is interested to work on this and expedite the work we are committed to help.

At the end, I'm sure that the time to support Windows will come, but before that I want to make sure that our performance and tooling around iOS and Andriod is top notch. Once we pass this milestone we can work to enable Windows and MacOS desktop targets.

@harangue

@valentinstoychev Obviously the ideal is to have an embedded JS engine running in a Windows Phone app, but I think I speak for most developers when I say that a web view, while far less performant, would be an appropriate alternative in the mean time. Have you considered that as a possibility?

@alexrainman

@harangue this sounds interesting. A webview that will only run javascript but wont show on UI?

@NathanaelA
Contributor
NathanaelA commented Jan 12, 2017 edited

@harangue - the only issue with going that direction is that you loose what really makes NativeScript special -- its ability to talk to the native layer from JS. This is some of the plumbing that Valio makes reference to; they need to build the code that would allow the JS engine to talk to the native api. Without that plumbing; that would eliminate the UI, or then the UI would have to be changed to use browser based elements, and it would then be cordova/phonegap; and not NativeScript. :-)

I should say good job thinking outside the box; sometimes those solutions are great!

@alexrainman

Can that plumbing be done from webview? In cordova apps you can talk to native from JS. I this case the webview will run only JS but not UI elements. I am just writing the first things that come to my mind :)

@harangue

@NathanaelA I think I understand what you're saying, but my suggestion was more in reference to using the JS context running inside a WebView as a substitute for JavaScriptCore, seeing as it appears that cannot be embedded in a Windows Phone application. Using a WP WebView, one could use Script Notify as a messaging protocol to call Native APIs. It wouldn't be direct, per say, but the biggest problem with Cordova is that drawing UIs in a web view is not as performant as drawing them natively - I don't think having an intermediary WebView would be as detrimental to performance as one might think.

I'm not intimately familiar with the intricate details of NativeScript, but if the Metadata work is nearly done as this issue leads me to believe, a WebView IMO would be an effective stopgap.

@NathanaelA
Contributor

@harangue - The idea itself isn't bad; but the technical ability to do so is the biggest issue. You can't make the JS engine understand new windows API keywords by default in the browser. So to do so you literally have to have the win api converted to a full class structure that mimics the look/feel of the win-api. This framework would be massive if you think about how many namespaces, values and functions are in the windows api. They could make a external program that created an entire JS winapi framework in JS which marshalls everything over the single standard JS callback functions, but first this would be a lot of work and two the amount of code the JS engine would have to load on startup would be massive (meaning a very slow boot). You literally have to have a class/function for every single api that can be called. This isn't even counting the work you have to do on the other side of the bridge to track any winapi native variables and syncing them up to the JS side.

In addition when running it would be a lot slower. The effort has a lot of pitfalls and plenty of broken corner cases. Even Microsoft abandoned this type of idea on phonegap that they had started because it is just fraught with a lot of issues that are difficult to solve, and they were only covering a small chunk of code.

Where in NS->Android I can just type com.mastertech.somename.dosomething() and it will automatically use the plugin that I added to my app (or a native OS api) . The Android runtimes have added code built into the v8 engine that catch any invalid names and then attempt to look them up against the native apis and then run them against the actual native framework. This allows NativeScript to automatically run on Android 8, 9 , 10, etc when those OS's come out without any additional changes. The same process happens on iOS, when I type var x = new NSString() it actually creates a NSString from the iOS framework and passes me back a reference to it. From JS it appears I'm using a real NSString because of the marshaling that is going on. This part of the plumbing needs to be done in either a browser based version or a controlled JS engine.

This part of the framework to make this all work automatically; the best solution is to control the JS engine (rather than using a browser engine). What Valio is referring to in plumbing is right now they use JavaScriptCore on iOS so they have all the code for marshaling on iOS in it. on Android they use the v8 engine, so they have all this same type of code. To add a third platform (Chakra) they have to make the same type of plumbing in the Chakra engine to be able to pass JS to native and vise versa. This is a fairly large effort to make work on a new platform. Even if they wanted to try and take a (theoretical) shortcut and use a browser based engine all the marshaling plumbing on the native side is still a LOT of work. In addition all the debugging, and other related tools that goes along with it is even more work.

This is why this effort has been stalled for the most part; the core team is not huge. They are attempting to get the iOS and Android to a really awesome place; then I suspect they are going to not be doing much with iOS and Android why they work on the Windows codebase for a couple sprints. They know how to do it; it just is a lot of work.

@Steviey
Steviey commented Jan 12, 2017 edited

Thank you for the clear statement @valentinstoychev!

So now my conclusion is, since JavaScript is already on every OS available, we still have to choose different platform vendors to reach them all.

The art then lies in a proper individual OOP and strict UI separation to have 'nearly' one code base.
If you then pass your milestones, everybody will be happy to switch to your platform, if it's still the most performant solution.

In the meantime perhaps it is a good idea to write individual core classes and functions without any 3rd-party frameworks- other then transpilers like Type Script, Babel etc., to provide compatibility to every possible platform vendor.

@harangue
harangue commented Jan 13, 2017 edited

@NathanaelA Thanks for the thorough explanation. The Windows Runtime framework actually already exists in JS. Microsoft doesn't seem to have it publicly available as a package or anything, but the complete typings are available so that would be pretty simple to use. Then it's just a matter of monkeypatching the various classes / namespaces / events and it'll feel just like you're using the native APIs.

This part of the framework to make this all work automatically; the best solution is to control the JS engine

I'm not sure I agree with that. Needing to patch and embed the engine probably results in a far bulkier build than something like this. Then again, I don't know that the messaging features built between webviews and native code are that robust on UWP.

But I also can't say that I'd have the time or experience to make this work myself, so I understand if it's not something the NativeScript core team is interested in doing. :)

@NathanaelA
Contributor

@harangue - I think there might be a misunderstanding in the technology stacks and how they work. Because the links you provide wouldn't work in a normal NativeScript app.

  1. PhoneGap/Cordova/Ionic, use a full browser engine to run, the controls run in a web view, everything runs from a browser. They add a communication channel to talk between the Browser to the native, and this communication layer is what runs the compiled plugins and allows them native access to the platform. However, any and ALL access you need to the native platform must be compiled in and built ahead of time as a plugin or part of the core app. The whole design is browser based; which is why you can NOT use most native android or ios plugins right in your view, only html technology based components (i.e. kendo, angular1, WinJS, etc) can be directly used.

  2. NativeScript/ReactNative basically use a Javascript engine to run your source code; but the view is actually a full native view (NO Browser, or browser dom); exactly as if you made it in xcode, swift or java. You can drop a nativescript app into any screen reader or use any standard tools and examine the entire layout in the normal Android or xcode tools. This is a significant difference between the two technologies. This also means that html based code is totally worthless, you can not use any web technologies in your app, without creating a webview control. So you can NOT do things like var x = window.createElement('canvas'); as their is no window or html elements at all. However, because React and NativeScript are using 100% native views; you have the ability to include any third party android or ios library you find, and the speed of the APP is incredibly faster by default

Now NativeScript goes one step beyond React, it allows me to actually talk to ANY native library or OS function from inside the JavaScript environment. So I can do: things like var dt = new java.util.date(); in the android runtime and access the actual OS date code; or var dt = new NSDate() on iOS. Those dt variables are actually accessing the real API on the device. I can I can use the Android or iOS docs and read how to use any native feature just like I was developing it in ObjC, Swift or Java. You will see in many of my pure JS plugins calls directly into the native api's of the platform.

This is where using a browser engine breaks down. If you try to include the actual full UWP API into JS; you have to create a full wrapper, things like:
var com = { microsoft: { windows: {open: function() { marshallCallToOS("com.microsoft.open", arguments); }}};
Then in my JavaScript program I could do "com.windows.open();" and it wouldn't throw an error. But without those full wrappers that manually marshall the code over the bridge; any call I tried to make that I can do in a normal UWP platforms against native api's would fail as by default none of those namespaces are in a browser at all.

The massiveness of this api: see: https://msdn.microsoft.com/library/windows/apps/bg124285.aspx is well massive. 😀 I mean event just look at just a small chunk (.net runtimes) of the api: https://msdn.microsoft.com/en-us/library/windows/apps/mt185501.aspx. That is somewhere over 40 separate namespaces that are valid in a UWP app from just the .net runtimes. Each namespace would need a full covering class with wrappers around values, callbacks, and functions to marshall from the browser to the native version of the function/value. Then on the other side of the bridge (i.e. the native side) it then has to call all those functions; track the values and return the results back through the bridge to your JS code. This work alone is a lot of work.

This is why I say trying to run this in a "browser" based engine is going to be very problematic. The amount of "Wrapping" libraries to product the ability to do native calls is massive.

The reason why NS uses a modified JSC or v8 engine, is because NativeScript has built into the engine that if it isn't a valid JS command or object, it then looks it up in the libraries. It then has built in marshalling, reference counting, linking variables and garbage collection so that the native side is GC'd when the JS side is GC'd. -- thinks like this is what allows NativeScript to support all the other non-nativescript native ios & android plugins without changes being made to them, and why trying to do this without controlling the engine makes it problematic (GC'ing JS w/o GC'ing the native side will give you memory leaks, but w/o knowing exactly what was GC'd in JS, doesn't really tell you what to GC on the NativeSide). There are MANY other cases where not having full control over the JS engine will cause other issues, beyond just the memory GC leak's example.

Now, I am NOT employeed by Telerik, and the teams working on these projects are really sharp. However I have dug in DEEP into the actual runtimes engines as I am the author of the AppProtection.net site. I had to patch my own code into the Nativescript and v8 and JSC engines to allow full seemless encryption of the app. My code is SIMPLE compared to what they had to do, and I wouldn't consider my code simple at all. ;-) So, the amount of work to fully get it working is a lot; which is why I suspect they will be working on it once they are happy that iOS and Android engine stuff can mostly just sit for a couple sprints. They service a lot of enterprise customers; so I know they know the value of adding it, but it is more a matter of when is the right time to work on it without leaving the rest of the project in a lurch...

@harangue
harangue commented Jan 13, 2017 edited

@NathanaelA This conversation is probably better suited for somewhere that isn't a big thread that lots of people are following, but I think you're underestimating my understanding of the underlying systems. WinRT is fully callable through JavaScript. Not in the browser, but using the aforemtioned typings as a basis one could transpile it quite easily to JS mocks which, using ES6 proxy, could be messaged to a UWP wrapper that converts them to native system calls. This makes the "massiveness" of the API moot.

Yeah, garbage collection is a challenge. We unfortunately haven't got weak references in JS just yet, but it's Stage 1 so this might actually happen sooner than we think. I'd personally be fine with destroying references in an ngOnDestroy lifecycle hook, but this wouldn't work as well for plugins. But between proxies and weak references, you have, IMO, enough meta programming info that you should never need to touch a VM.

Just my two cents.

@NathanaelA
Contributor

@harangue - your probably right about the conversation. Not sure where we should move it to, If you are on slack or the forums you can look me up or on either. ;-)

Proxies still unfortunately have a couple of serious (imho) holes in them. ;-( I am actually in the process of using them for a plugin where I need the ability to do some automatic proxing without the underlying code realizing that is what is going on. And I have found several places where a proxy does NOT work and it is unfortunately not in spec to work that way yet. (I ran into this a couple weeks ago, and iirc it had something to do with the new keyword on a proxied object). It didn't totally negate what I was going to do; but I have to build some objects traditionally and some proxied. This type of system would face the same issue; as there is a lot of places "new" would need to be used. (oh and proxied objects have a perf hit) -- But even assuming proxies worked 100%, the amount of work on the native side to track the created native variables/classes/refs, do the marshaling into JS those values that can be marshalled properly and keep all that in sync with the JS side is still a lot of code. This is part of the plumbing that has to be done no matter which way you go...

NativeScript actually does have WeakRef() and it is used through out the common-core-code, and many plugins. This is critical for GC to work efficiently between the JS layer and the native layer. When you are using a listview viewing images; without the GC working properly you will totally cause the device to run out of memory. This has cropped up several times as a bug report because of either a user error or in some cases a design flaw in the image control not synced properly to the native side so the native side wouldn't let go the memory even though the JS side was GC'd.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment