This question is locked. New answers and comments are not allowed.
Hi Valio,
this is the reply to your answer to my question in the latest NativeScript webinar.
It would be cool to be able to design view controllers in Xcode in the StoryBoard editor and used them in a NativeScript application.
Other than having a quick way to design the UI of an app, we can exploit feature like Autolayout and constrains when for example when we change the device orientation.
I didn't test it year, but having access to native iOS APIs from NativeScript, I could load a ViewController from a StoryBoard using the corresponding APIs in nativescript of this Objective-C code:
UIStoryboard *mainStoryboard = [UIStoryboard storyboardWithName:@"Main" bundle:nil];
ViewController *vc = [mainStoryboard instantiateViewControllerWithIdentifier:@"ViewController"];
and then attach to a NativeScript page, is that possible?
In objective-C I can also access also the related view and all its children (buttons, labels, tableviews, etc etc) and have access to them programmatically.
However, as far as I have understood, to manipulate any native UI elements, NativeScript creates the so-called proxies, where changing proxies properties will be reflected in native UI.
So my question: can we create NS proxies programmatically and attach them to any native UI elements coming from storyboards?
Would this be possible in the future or can you suggest me another approach to access UI elements properties?
this is the reply to your answer to my question in the latest NativeScript webinar.
It would be cool to be able to design view controllers in Xcode in the StoryBoard editor and used them in a NativeScript application.
Other than having a quick way to design the UI of an app, we can exploit feature like Autolayout and constrains when for example when we change the device orientation.
I didn't test it year, but having access to native iOS APIs from NativeScript, I could load a ViewController from a StoryBoard using the corresponding APIs in nativescript of this Objective-C code:
UIStoryboard *mainStoryboard = [UIStoryboard storyboardWithName:@"Main" bundle:nil];
ViewController *vc = [mainStoryboard instantiateViewControllerWithIdentifier:@"ViewController"];
and then attach to a NativeScript page, is that possible?
In objective-C I can also access also the related view and all its children (buttons, labels, tableviews, etc etc) and have access to them programmatically.
However, as far as I have understood, to manipulate any native UI elements, NativeScript creates the so-called proxies, where changing proxies properties will be reflected in native UI.
So my question: can we create NS proxies programmatically and attach them to any native UI elements coming from storyboards?
Would this be possible in the future or can you suggest me another approach to access UI elements properties?
3 Answers, 1 is accepted
0
Valio
Top achievements
Rank 1
Rank 1
answered on 12 Dec 2014, 09:45 AM
Hi Antonio,
if you go down that road you should design platform specific, separate UI for iOS and Android. You will not be able to reuse the code between the platforms.
And just to confirm:
--
However, as far as I have understood, to manipulate any native UI elements, NativeScript creates the so-called proxies, where changing proxies properties will be reflected in native UI.
--
Yes - this is exactly what happens under the hood. You are using our cross-platform abstractions and under the hood we are creating native UI elements.
Now on your next question:
--
So my question: can we create NS proxies programmatically and attach them to any native UI elements coming from storyboards?
Would this be possible in the future or can you suggest me another approach to access UI elements properties?
--
This is exactly what happens when you add a 3rd party native reference. We are reading the APIs in the native library and dynamicaly are creating the JavaScript APIs which you can use. So, this means that, if you create a native library, then you can expose public API which you want to access from JavaScript. If you want to access specific UI elements from that library, just make sure that you have a public API for that. It is a very simple thing - whatever you need to access from the Javascript layer, just make it public in the native API.
In our cross platform implementation of the Button for example there is an "iOS" property which gives you access to NSButton properties which you can access directly.
I hope all this makes sense. Please let me know if you want additional explanation.
I have a question for you? What is the reason that you want to create the UI in XCode? Do you want to reuse existing ObjC code or there is another reason behind this request?
Thanks!
--valio
if you go down that road you should design platform specific, separate UI for iOS and Android. You will not be able to reuse the code between the platforms.
And just to confirm:
--
However, as far as I have understood, to manipulate any native UI elements, NativeScript creates the so-called proxies, where changing proxies properties will be reflected in native UI.
--
Yes - this is exactly what happens under the hood. You are using our cross-platform abstractions and under the hood we are creating native UI elements.
Now on your next question:
--
So my question: can we create NS proxies programmatically and attach them to any native UI elements coming from storyboards?
Would this be possible in the future or can you suggest me another approach to access UI elements properties?
--
This is exactly what happens when you add a 3rd party native reference. We are reading the APIs in the native library and dynamicaly are creating the JavaScript APIs which you can use. So, this means that, if you create a native library, then you can expose public API which you want to access from JavaScript. If you want to access specific UI elements from that library, just make sure that you have a public API for that. It is a very simple thing - whatever you need to access from the Javascript layer, just make it public in the native API.
In our cross platform implementation of the Button for example there is an "iOS" property which gives you access to NSButton properties which you can access directly.
I hope all this makes sense. Please let me know if you want additional explanation.
I have a question for you? What is the reason that you want to create the UI in XCode? Do you want to reuse existing ObjC code or there is another reason behind this request?
Thanks!
--valio
0
Antonio
Top achievements
Rank 1
Rank 1
answered on 12 Dec 2014, 10:05 AM
Hi Valio,
thank you for replying me back.
I am aware that what I am trying to achieve is not cross-platform compatible, but sometimes it happens that the same app could have a totally different layout for the same view, and I prefer to have separate code for them. I could then reuse some shared business logic from the controllers of the Android and iOS views (I am a Titanium developer and this is an option in Alloy).
To answer your question: I am a fun of GUI builders, especially for quick prototypes. Moreover, I talk with the perspective of a mobile app instructor (I run training classes on iOS and Titanium, and I am evaluating NativeScript now :). People learning a new platform likes more a drag and drop approach seeing a live preview of the app they are building.
I know that many developers prefer to build the UI in code, but there is nothing wrong loading the UI from binary files (that's how it works on iOS) and sometimes could be faster than building it in code.
I don't have any specific Objective-C code, and my idea would be to have a general library able to load any ViewControllers from any Storyboard or XIB, and not for a specific case. Not sure if your suggestion requires to build a native 3rd party reference for every storyboard.
Anyway I will experiment a bit with the platform trying to follow the approach you have suggested and update with my feedback.
thank you
Antonio
thank you for replying me back.
I am aware that what I am trying to achieve is not cross-platform compatible, but sometimes it happens that the same app could have a totally different layout for the same view, and I prefer to have separate code for them. I could then reuse some shared business logic from the controllers of the Android and iOS views (I am a Titanium developer and this is an option in Alloy).
To answer your question: I am a fun of GUI builders, especially for quick prototypes. Moreover, I talk with the perspective of a mobile app instructor (I run training classes on iOS and Titanium, and I am evaluating NativeScript now :). People learning a new platform likes more a drag and drop approach seeing a live preview of the app they are building.
I know that many developers prefer to build the UI in code, but there is nothing wrong loading the UI from binary files (that's how it works on iOS) and sometimes could be faster than building it in code.
I don't have any specific Objective-C code, and my idea would be to have a general library able to load any ViewControllers from any Storyboard or XIB, and not for a specific case. Not sure if your suggestion requires to build a native 3rd party reference for every storyboard.
Anyway I will experiment a bit with the platform trying to follow the approach you have suggested and update with my feedback.
thank you
Antonio
0
Valio
Top achievements
Rank 1
Rank 1
answered on 12 Dec 2014, 01:00 PM
Hi Antonio,
What you are saying makes perfect sense and the good news is that it fits very well in our thinking too. There are still some things missing from the platforms to enable this scenario out of the box, but we are working on them.
Please work closely with me when you get to try the things out. I'm sure you will hit rocks right now and I can help you move forward. This is the whole purpose of having an Insiders group right? :)
Best,
Valio
What you are saying makes perfect sense and the good news is that it fits very well in our thinking too. There are still some things missing from the platforms to enable this scenario out of the box, but we are working on them.
Please work closely with me when you get to try the things out. I'm sure you will hit rocks right now and I can help you move forward. This is the whole purpose of having an Insiders group right? :)
Best,
Valio