Controls on mobile apps - am I missing something?

[Mark Waddingham]

On 2016-07-01 11:49, Terence Heaford wrote:
> I think I understand, a native field for iOS (plus other mobile
> platforms) is a stretch goal.

Well, actually, the 'stretch goal' (like all of stretches for Infinite 
LiveCode) are fully documented examples how to 'do that kind of thing' 
with Infinite LiveCode - of course, you also get a well-written, fully 
functional feature too.

> I will have to roll my own in LCB (when available for this) or wait
> for LiveCode to require to do it via a stretch goal?

I'm minded of a well-known proverb:

    "Give a man a fish and you feed him for a day; teach a man to fish 
and you feed him for a lifetime"

Which isn't me trying to patronising or glib, but is a succinct way to 
express our approach with LCB. The logic being that the more that can be 
done without touching C++ at all, the more people will be able to make 
LiveCode 'do more'.

LiveCode Builder is not LiveCode Script, but it definitely sits in the 
same family. It is more strict, and has richer typing - which is 
precisely what you need when you want to write robust components which 
might need to hook in foreign APIs. Furthermore, as LCB evolves we'll 
add more ways you can extend LiveCode Script in more natural ways 
syntax-wise.

Our main focus right now (beyond continuing improvements to LiveCode 8 
as a whole) is getting Infinite LiveCode finished not only so that it 
opens up using Builder to a much wider audience, but also so the core 
dev team can use Builder to implement engine functionality. Not only 
should help speed up the pace of development for OS-related features, 
but also mean that the code for them is in a much more accessible form 
for contribution from third-parties.

The latter point here is particularly pertinent to the Infinite LiveCode 
campaign - the stretch goals are not 'just feature additions' they will 
be documented examples of how to use LiveCode Builder to implement those 
kinds of features.

To give an example, Monte recently posted this enhancement request:

     http://quality.livecode.com/show_bug.cgi?id=17874

Right now, this feature *could* be added as an external - the 
information about the 'focused screen' on both Mac and Windows is fully 
available without any state from the engine. However, writing an 
external (particularly a cross-platform one) takes quite a lot of time 
as you have to setup the projects, write the glue code, write the 
functionality and then compile and test the external.

In contrast, this ability can actually be written in LCB *right now* 
although it does require more technical understanding of how the OS APIs 
work on the specific platforms, and knowledge of lower-level language 
formalisms than is appropriate for the goals of the language. But then, 
that is the goal of Infinite LiveCode: to make it as simple as we can 
possibly make it to call foreign APIs.

The following took me about 20 mins end to end to write, and use in the 
IDE via the extension builder:

//////////

library com.livecode.examples.focused_screen

use com.livecode.foreign

type ObjcId is Pointer
type ObjcSel is Pointer

type ObjcClass is ObjcId

----------

foreign handler _objc_getClass(in pName as ZStringUTF8) returns ObjcId 
binds to "libobjc.dylib>objc_getClass"
foreign handler _sel_registerName(in pName as ZStringUTF8) returns 
ObjcSel binds to "libobjc.dylib>sel_registerName"
foreign handler _objc_msgSend_id_v(in pSelf as ObjcId, in pSel as 
ObjcSel) returns ObjcId binds to "libobjc.dylib>objc_msgSend"
foreign handler _objc_msgSend_int_id(in pSelf as ObjcId, in pSel as 
ObjcSel, in pArg as ObjcId) returns UIntSize binds to 
"libobjc.dylib>objc_msgSend"

----------

type NSArray is ObjcId
type NSScreen is ObjcId

handler NSScreenScreens() returns NSArray
    return _objc_msgSend_id_v(_objc_getClass("NSScreen"), 
_sel_registerName("screens"))
end handler

handler NSScreenMainScreen() returns NSScreen
    return _objc_msgSend_id_v(_objc_getClass("NSScreen"), 
_sel_registerName("mainScreen"))
end handler

handler NSArrayIndexOfObject(in pArray as NSArray, in pObject as ObjcId) 
returns Integer
    return _objc_msgSend_int_id(pArray, 
_sel_registerName("indexOfObject:"), pObject)
end handler

handler mac_focusedScreen() returns Integer
    return NSArrayIndexOfObject(NSScreenScreens(), NSScreenMainScreen()) 
+ 1
end handler

----------

public handler focusedScreen() returns Integer
    return mac_focusedScreen()
end handler

end library

//////////

I probably wouldn't have even got as far as setting up the Xcode project 
and the structure you need for C++ projects in that time - let alone 
write the C++ code, compile it, make it load into the IDE and test it. 
Then, if I wanted to add Windows, I'd have to setup a different project, 
split up the code so that it conditionally compiled based on platform 
and use two machines (VMs) to compile the external using different C++ 
IDEs. Adding Windows support in LCB, however, would be a case of adding 
the code to the same file and checking the platform to see which 
implementation to use (mac_focusedScreen() or win_focusedScreen()). 
Furthermore, I can do that on one machine, and just use a windows 
machine/VM to test that it works in the LiveCode IDE via the extension 
builder. (Also, critically I did to know how to program in C++ nor how 
to use C++ IDEs to do the above!).

So, anyway, I cannot answer you question on 'how long you might have to 
wait' for 'native controls' for Mac - all I can say is that with 
LiveCode Builder and Infinite LiveCode, you should have to wait a great 
deal less time than you would have done without them.

Warmest Regards,

Mark.

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps