LiveCode Forums.

Just starting out with LiveCode.

It seems easier, at least at this point, to have some different cards for desktop/mobile to make things look best on each platform. If I had different cards for, say, mobile and desktop, would it make sense to put most of the code at the Stack level and leverage the message chain, having the stack examine the handler call to see where it came from and dispatch accordingly? This way as you add cards/etc for different layouts you wouldn't have to duplicate code everywhere.... Or is it more of a standard practice to put it all down at the object or card level, and duplicate it as you duplicate cards?

Not an easy question to answer in a generic way. But in general, I'd say DRY (Don't Repeat Yourself), so the duplication thing would be a last resort.

If I understand what you're trying to do, you shouldn't need to "examine the handler call to see where it came from". That's part of the message path.
In most cases you can use "the target" to find the object that initiated the request.
You can also usually use "this card" to get a reference for the current card, etc.

Does that help any?

Thanks, I think that does help. And yes, generically it is hard to answer. I will have to wait until I get a few more projects going before I can separate the specific of this one app to how it really is fleshed out in a generic way. Part of me also doesn't like having lots of little bits of code all buried down at, say, the button level, but on the other side of that coin I see how while developing clicking on a button to handle the code is appealing. Maybe it is there somewhere/somehow, but having a code navigator to see where all the code bits are, hierarchically from stack down to lowest objects, would be cool.

You might want to look at the idea of behavior objects as well.

The way I usually approach this situation is to put my code at the most-constrained level (button, field, etc) until I see the need to use it in more than one place.
Then I'll refactor by moving the code down to the card level, and down to the stack level if necessary.
Or possibly create a behavior button and link the objects to that.
But that's as close to a design pattern as I can get at that generic level : start local and gradually get less local.