Some design questions

[Monox18]

Hi all,

Following the "Code once deploy to billion devices" motto, I'm in need of some design answers:

1. What's the purpose of the native widgets? For example normal buttons deploy well to all devices, so why is there an Android, MAC and HTML5 native button?

2. Assuming using the native widgets I asked in the previous question, are better than the normal buttons, it means I will need to add more buttons, and handle them individually for the target device they will be deployed. So how do you approach here? having multiple buttons doing the same but some should be set visible off? destroyed? when an standalone is open. (If I open a mobile app, then it should delete all other non mobile objects? or just set visible to false?). Or what about having a master button and then other buttons behaving the same by setting the Behavior property?

Thanks!

[dunbarx]

Hi.

I don't build widgets, but check out this:
http://lessons.livecode.com/m/4603/l/73 ... ng-widgets

They are more than just self-contained gadgets like clocks or spinners. They are keys to other worlds.

Craig

[jacque]

Native buttons conform to the appearance of the OS so you don't have to create simulations yourself. To be true to the differences between iOS and Android, you'd need two different buttons anyway or else you'd need handlers that change a lot of properties to conform to the 0S specs. That's more important than you'd think, Apple rejects apps it doesn't think look right.

There are lots of ways to manage this. You could create two different groups (or even whole cards) and use the one that matches the OS. Or if there are only a few controls, just show/hide the correct ones. Or you could create the widgets on demand by script as appropriate.

However you do it, behaviors would be useful here so that you can reuse the same script no matter what widget is in use.

[ValiantCuriosity]

I may be way off base on this. Jackie is an expert. I'm a newbie to LC. However, I do have a few very esoteric apps in the Apple App Store. I've been creating them since 2012. They serve only a tiny community and I do them for fun.

I can tell you that the buttons in my current apps aren't standard Xcode iOS buttons. I *think* you might be able to get away designing your own buttons. IF you stick closely to the look and feel of iOS, you should be fine. Then, you could use the standard LC buttons. I'm doing this in my, as yet, feeble attempt to rewrite my apps. It is working well with help from this forum and a strong dose of reading through the docs. In my case, I'm copying the UI from my current apps. So far, it has been mostly pleasurable to use the widgets. I suspect the coding will be the big challenge for me.

Good Luck to you.
-Rachel

[richmond62]

Apple rejects apps it doesn't think look right.

If you want to climb into bed with a dictatorial regime you had
better make sure you are wearing the approved type of pyjamas.

[Monox18]

Thanks for the responses guys. So it seems that the widgets are mostly for being more efficient device specific and also ensuring the app meets the Look-and-feel guidelines of the OS. Also native controls might recieve more messages than the standard controls. In this case I'm talking only about Buttons and maybe considering using the native fields as well.

I find myself always creating everything in one card. Showing and hiding grouped controls. If I develop an app for Android, it means all the iOS and PC controls should be hidden. They still make the app bigger in size and do they still use or consume more memory or CPU? What I'm worried about is if it might be possible that having lots of hidden groups with controls could somehow decrease the app performance.

The most efficient way would be making an individual app file for each device using only the controls that are going to be used, but that defeats the purpose of "code once, deploy to multiple devices".

[jacque]

Performance won't be affected, LC mostly ignores hidden controls except for passing messages through them as needed via the message hierarchy. You won't have any problems, and the approach you suggest is very common.

The extra size of the controls themselves are minimal. If you plan to show megabytes of text or huge images, then store the content only once and populate the control on demand depending on the device in use. That said, unless the content is truly gigantic, you probably don't need to worry about it.

[Monox18]

Understood. Thank you jacque