iOS and Android Native Controls 'Layer'

[Nakia]

Hi,

One of the things I find hard to overcome is the fact that LC places Native iOS and Adroid controls on the top most layer when it creates them.
Would anyone else like the ability to specifiy the layer of the created control when it gets created?

Use Case,
I have a card with multiple iOS Native Input fields that extends beyond the length of the card. I have these created inside a iOS Scroller.
when the scroller scrolls and one of the iOS Fields breaches/touches the Nav Bar at the top of the screen it 'runs over the top' of it because it's the top most layer. (Gee I hope that made sense).
For now, I have dealt with this by simply setting the visible of the iOS Field to false when it touches the Nav Bar but its less than ideal.

I do realise I could use LC Fields and overcome this but I still think there is a use case here for being able to specifiy the creation layer on the Native Controls.

Thoughts....

[monte]

Do you mean mix native layers and LC layers... that would be a huge change.. every control would need to be a UIView. Setting the layer order of native controls above the stack view would be feasible. As would setting a clipping rect (basically an extra view that native views are contained in) for all native views so in your example your clipping rect would start at the bottom of the nav bar and make it look like the fields are going under it.

[Nakia]

Hi Monte,

To be honest Im not sure on 'How' it may be implemented but from your description I think I was imagining mixing Native and LV Layers which sounds like it may be a huge change that is probably not worth it.

Reading through your post though maybe a clipping rect may give the desired result?

Imagine this (kind of anothe use case)
There is a Native iOS Multiline fld with the middle loc at the point where the keyboard top sits when its open. Now I need to build one of the little bars that sit above the keyboard when its open with a done button on it (to close the keyboard) but this will be a LC object and because the Native object site above the LC Object it covers it up...

Again, I hope that makes sense and this is only an idea.

[monte]

I think the clipping rect would cover the use case well enough unless you wanted shadows etc to cover the native views or objects to be on top of the whole view... like a button on top of a browser view... that won't happen unless its a native button.

[Nakia]

Imagine this (kind of anothe use case)
There is a Native iOS Multiline fld with the middle loc at the point where the keyboard top sits when its open. Now I need to build one of the little bars that sit above the keyboard when its open with a done button on it (to close the keyboard) but this will be a LC object and because the Native object site above the LC Object it covers it up...

Again, I hope that makes sense and this is only an idea.

[monte]

In that case can't you set the rect of the native field to ensure it doesn't cover?

[Nakia]

Yeah there is no reason why I couldn't I suppose...

[LCMark]

@Nakia: The idea of being able to interleave native and LiveCode controls (layers) is definitely something we want to be able to do - after all it would mean that native UI controls could be used interchangeably with LiveCode controls.

As @monte says it does require an evolution of the architecture we currently have. At the view of a Stack sits in a UIView (or Android equivalent) with all the native layers stacked above it. However, the plans we have along these lines is to generalize the mechanism used for 'acceleratedRendering' mode. This mode works by treating sequences of static layers as a single dynamic layer, and dynamic layers as distinct. If you imagine a new 'native' type layer then a similar idea can be used, the engine would interleave the native Views (layers) with a single LiveCode-controlled native View (layer) which would be where all the LiveCode controls between the native layers would be rendered.

Of course, this is still something which is a while away, so any ideas/additions to how to improve the current situation for different use-cases are more than welcome.

[Nakia]

It sounds like the long term plans are great.
As I mentioned before I am not at a level to understand the under the hood portion of livecode.

An example of my use case can be seen in the below link.
http://youtu.be/pL1MSyD59JU

Are there maybe options to have a definable parameter for when then keyboard opens
To include or not include a UIAccessoryView that sits on the same layer as the keyboard (above the Native objects)

[monte]

Ooo.. are you talking about a native view object?

[Nakia]

When I say 'Native Object' I was referring to the iOS Native Objects (multiline and single line input fields)..
The use case I was trying to describe above isnt a problem when using the LC Objects.

Currently when the keyboard opens it appears to sit on a layer above both the LC Objects and the Native Objects...

[LCMark]

Ooo.. are you talking about a native view object?

If this was directed at me then... Not exactly... I was referring to adding the ability (internally) to be able to create a native layer, just as controls create dynamic/static layers at the moment (when acceleratedRendering is on, the rendering hierarchy is for all intents and purposes separate from the control hierarchy - they are parallel data structures). This would mean a control could (rather than creating a layer to rasterize itself into) create a native view and still have it layer exactly the same as it were a LiveCode control (with some restrictions on things like blendMode / effects).

[monte]

Yes I was directing it at you. That sounds like a native view object to me... or at least a way for a control to present a native view. Some easy way to add native widgets and have them feel like LC controls would be lovely