Reference Material Discussion Application Architecture Strategies

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Reference Material Discussion Application Architecture Strategies

Michael Doub
Is anyone aware of any reference material that discusses strategies for architecting your application with the livecode components and their implications with the standalone builder.   As an example, I think that most people understand the basic concept of building a splash screen as the main application and keeping the main logic into a separate stack.  Now actually making this happen in the standalone builder and understanding the implications is another thing.  By implications I mean, can I use this approach when building and IOS or Android application?   I think that the answer is No and Yes.

Another interesting topic is the use of stacks vs substacks and how to bundle them all together.  Best practices for where to keep images for all of the different screen densities.

I know there are quite a few books and sites that help people get started, but I think what I am looking for is more advanced.  It is more strategic and architectural.  Is seems that one almost needs to understand what the standalone builder is doing under the covers to decide on what strategy might be best in each target environment.

Right now I am writing a fairly complex mobile app that has the works, multiple stacks, substacks, libraries and I know about all of the bits and pieces, but how do you decide the best organization for actual deployment and dare I say maintainability.   Also since I have never actually launched an app publicly, I don’t know, what I don’t know about the issues ahead of me.

Does such reference material exist?  

Regards,
   Mike


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Reference Material Discussion Application Architecture Strategies

Wprothero
Michael,
Thank you for asking this question. There is certainly a need for this in the community. I am also new to livecode and am converting a rather large app from Director. I am building a cross platform app, and perhaps a mobile version later. Currently I am putting most of my code in the stack scripts of substacks, organized roughly by broad functionality. I started with external stacks that I loaded at runtime, but found it much easier to do script searches if they were substacks. All code is in stack scripts. If I need these pieces for other projects, I can always separate them. That's as far as I've gotten so far. I can imagine getting a large collection of substacks by the time the project is completed. So far all of my substack handlers are able to seamlessly call stack handlers in other substacks, which is nice. I wonder if there are consequences to this approach.

One of the big challenges is keeping track of all of the handlers and whether their location in the hierarchy requires special treatment (like a dispatch command). With all of my handlers in stack scripts, I don't have to do this.

I'd be very interested in hearing how others organize their projects.
 Bill

William Prothero
http://es.earthednet.org

> On Apr 19, 2014, at 2:04 PM, Michael Doub <[hidden email]> wrote:
>
> Is anyone aware of any reference material that discusses strategies for architecting your application with the livecode components and their implications with the

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Http://es.earthednet.org
Reply | Threaded
Open this post in threaded view
|

Re: Reference Material Discussion Application Architecture Strategies

Michael Doub
My coding style has evolved to trying to put code in Libraries, Stack and Cards.  I only put stubs that call other handlers in the objects themselves.  This is the code organization part.  

I was putting my library stacks in as substacks and when I started seeing the naming conflict messages I started looking into where these should go.   I always seemed to have problems with “start using” unless the stack was already in memory, so I still feel that I am missing something relating to the basics loading stacks.

Bill, are you building your stand alone yet?  This is where I really started to ask questions.  Why is there an option to move substacks into individual stacks?  When I made everything substacks I really didn’t think too much about the standalone builder.  Now that I have both I feel I need to understand what is going on and why.

-= Mike


On Apr 19, 2014, at 6:01 PM, Earthednet-wp <[hidden email]> wrote:

> Michael,
> Thank you for asking this question. There is certainly a need for this in the community. I am also new to livecode and am converting a rather large app from Director. I am building a cross platform app, and perhaps a mobile version later. Currently I am putting most of my code in the stack scripts of substacks, organized roughly by broad functionality. I started with external stacks that I loaded at runtime, but found it much easier to do script searches if they were substacks. All code is in stack scripts. If I need these pieces for other projects, I can always separate them. That's as far as I've gotten so far. I can imagine getting a large collection of substacks by the time the project is completed. So far all of my substack handlers are able to seamlessly call stack handlers in other substacks, which is nice. I wonder if there are consequences to this approach.
>
> One of the big challenges is keeping track of all of the handlers and whether their location in the hierarchy requires special treatment (like a dispatch command). With all of my handlers in stack scripts, I don't have to do this.
>
> I'd be very interested in hearing how others organize their projects.
> Bill
>
> William Prothero
> http://es.earthednet.org
>
>> On Apr 19, 2014, at 2:04 PM, Michael Doub <[hidden email]> wrote:
>>
>> Is anyone aware of any reference material that discusses strategies for architecting your application with the livecode components and their implications with the
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Reference Material Discussion Application Architecture Strategies

Wprothero
Mike,
I haven't tried to build a standalone yet. I'm not at my computer now, but my memory is that you have to "open" substacks, then do "start using". I have an item list of substacks and am planning to associate various library substacks with specific project modules, so I can manage memory. I also don't like putting scripts in objects, except when the object is central to the modele's function, like a map that displays data. But, it is convenient to put test scripts into buttons that can be deleted after everything is working.

It's a constant battle to keep reorganizing code for re-use. First implementation is usually a mess, then the next step that requires me to use that code requires refactoring, etc, etc, but in the end there are fewer bugs and it's easier to use.

I am loving lc's arrays. I'm also just starting to use groups and finding them also convenient and easy to use. Some of the ui objects are awesome. I just discovered the tabbed object. It saves a lot of time, as does the datagrid.

Good luck,
Bill

William Prothero
http://es.earthednet.org

> On Apr 20, 2014, at 9:35 AM, Michael Doub <[hidden email]> wrote:
>
> My coding style has evolved to trying to put code in Libraries, Stack and Cards.  I only put stubs that call other handlers in the objects themselves.  This is the code organization part.  
>
> I was putting my library stacks in as substacks and when I started seeing the naming conflict messages I started looking into where these should go.   I always seemed to have problems with “start using” unless the stack was already in memory, so I still feel that I am missing something relating to the basics loading stacks.
>
> Bill, are you building your stand alone yet?  This is where I really started to ask questions.  Why is there an option to move substacks into individual stacks?  When I made everything substacks I really didn’t think too much about the standalone builder.  Now that I have both I feel I need to understand what is going on and why.
>
> -= Mike
>
>
>>

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Http://es.earthednet.org
Reply | Threaded
Open this post in threaded view
|

Re: Reference Material Discussion Application Architecture Strategies

Wprothero
In reply to this post by Michael Doub
Michael:
I was wrong. All I have to do to activate a substack is just
         start using stack theLibStackName
Bill

[hidden email]
http://es.earthednet.org

On Apr 20, 2014, at 9:35 AM, Michael Doub <[hidden email]> wrote:

> My coding style has evolved to trying to put code in Libraries, Stack and Cards.  I only put stubs that call other handlers in the objects themselves.  This is the code organization part.  
>
> I was putting my library stacks in as substacks and when I started seeing the naming conflict messages I started looking into where these should go.   I always seemed to have problems with “start using” unless the stack was already in memory, so I still feel that I am missing something relating to the basics loading stacks.
>
> Bill, are you building your stand alone yet?  This is where I really started to ask questions.  Why is there an option to move substacks into individual stacks?  When I made everything substacks I really didn’t think too much about the standalone builder.  Now that I have both I feel I need to understand what is going on and why.
>
> -= Mike
>
>
> On Apr 19, 2014, at 6:01 PM, Earthednet-wp <[hidden email]> wrote:
>
>> Michael,
>> Thank you for asking this question. There is certainly a need for this in the community. I am also new to livecode and am converting a rather large app from Director. I am building a cross platform app, and perhaps a mobile version later. Currently I am putting most of my code in the stack scripts of substacks, organized roughly by broad functionality. I started with external stacks that I loaded at runtime, but found it much easier to do script searches if they were substacks. All code is in stack scripts. If I need these pieces for other projects, I can always separate them. That's as far as I've gotten so far. I can imagine getting a large collection of substacks by the time the project is completed. So far all of my substack handlers are able to seamlessly call stack handlers in other substacks, which is nice. I wonder if there are consequences to this approach.
>>
>> One of the big challenges is keeping track of all of the handlers and whether their location in the hierarchy requires special treatment (like a dispatch command). With all of my handlers in stack scripts, I don't have to do this.
>>
>> I'd be very interested in hearing how others organize their projects.
>> Bill
>>
>> William Prothero
>> http://es.earthednet.org
>>
>>> On Apr 19, 2014, at 2:04 PM, Michael Doub <[hidden email]> wrote:
>>>
>>> Is anyone aware of any reference material that discusses strategies for architecting your application with the livecode components and their implications with the
>>
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Http://es.earthednet.org
Reply | Threaded
Open this post in threaded view
|

Re: Reference Material Discussion Application Architecture Strategies

Alejandro Tejada
Does exists a tutorial explaining How To implement MVC
using LiveCode?

http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

Al
Reply | Threaded
Open this post in threaded view
|

Re: Reference Material Discussion Application Architecture Strategies

Andrew Kluthe-2
Andre Garzia did a talk on it at runrev live last year didn't he? I
remember watching it and starting to reorganize one of my applications the
next day. Basically, treat ui stacks as view, put all your business logic
that can be separated into library stacks and use a pub-sub to lessen the
burden. It made a lot more sense as far as maintainability goes for me.




On Wed, Apr 23, 2014 at 3:17 PM, Alejandro Tejada <[hidden email]>wrote:

> Does exists a tutorial explaining How To implement MVC
> using LiveCode?
>
> http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
>
> Al
>
>
>
> --
> View this message in context:
> http://runtime-revolution.278305.n4.nabble.com/Reference-Material-Discussion-Application-Architecture-Strategies-tp4678454p4678593.html
> Sent from the Revolution - User mailing list archive at Nabble.com.
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



--
Regards,

Andrew Kluthe
[hidden email]
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode