On 2016-01-20 16:53, Bob Sneidar wrote:
On Jan 12, 2016, at 11:26 , Mark Waddingham
<m...@livecode.com<mailto:m...@livecode.com>> wrote:
Simple things like not putting code in a mouseUp, but instead just get
it to call an action function in the core part of the application
(independent of UI) help immensely.
This makes me a little sad, because one of the great things about LC
in my opinion is the modularity of the code. Going to an object's
script and seeing exactly what the object does, as opposed to having a
single large (and unweildy I might add) script is very attractive to
me.
My comment there was perhaps a little 'glib' and perhaps not quite
representative of what I was suggesting.
In general there is always a line (which sometimes can be very difficult
to find!) between code which drives a UI, and code which drives the
application logic. So a sensible way to write an application which has
to have multiple distinct UIs is to find that line and make sure the UI
calls actions which perform the application's actual function. (Think
command-line application being driven by a frontend UI - something which
MetaCard was used widely for in the UNIX world from its original
inception).
For example, many document-centric apps will have a 'Save' function. On
Mac this is typically 'just' in the File menu. However, on Windows it is
usual to have it both in the File menu *and* as a button on a document's
toolbar. If the code for the 'save' action is not factored out you end
up with duplicated code - so it is quite natural to move this code
'down' into core logic. If you do that for anything which can be taken
out of a UI context you quickly end up with a architecture where the UI
of your app is separated from the action thus making (in theory at
least) adding variants of the UI easy.
Of course, good UIs are not easy to write - personally I generally find
it much easier to define the core application model than I do to write
the UI sitting on top of it. However, this is where LiveCode (and
similar things) excel due to their visual and 'immediate' nature - you
can iterate UIs rapidly, particularly if you don't have to worry about
'breaking' the core application logic, something which splitting things
up into UI + Logic helps with.
So, I perhaps should have been more specific - code that deals with the
UI should probably be 'closest to use' for all the places it should be
used, whereas code which deals with core application logic is probably
best 'pushed down' into a core library or set of libraries.
Of course, in the end, it all does largely depend on the application,
how well the programmer understands the problem he/she are trying to
solve in the first instance and how much time you have to solve it!
I also understand the advantage of a centralized library of functions
and I am not argueing against that, but I like the LC (and originally
HC) model. In fact the computing world thought this was such a neat
concept that OOP was born.
Well, I think OOP predates HyperCard by a significant margin. Simula was
perhaps the first 'object oriented' language (although it did
inheritence in reverse to current languages) - a superset of Algol, it
appeared in 1965.
SmallTalk, one of the first 'purely object oriented' languages appeared
in 1972.
HyperCard didn't appear until 1986.
So it seems that one objective might favor one approach, and another
objective a different one. This is exactly why designing for multiple
OSes, while certain techniques can get you a long way there, might
eventually be unattainable.
It would be possible to do a reasonably good job of abstracting some of
the UI patterns people use today so that they specialize appropriately.
For example, on an iPad you tend to use 'Split View' controllers which
are similar to having a content view with a 'menu' callout button on
iPhones. Conceptually (if you ignore the actual layout / rendering)
these are almost the same - it is just the rendering and interaction
which are different.
Warmest Regards,
Mark.
--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
