Multi-platform development

[Richard Gaskin]

Bob Warren wrote:

 > Hi Alex,
 >
 > The lack of response to your question shows, I think, that multi-
 > platform apps in LiveCode, for both desktop and mobile, are really
 > hard to achieve.

In all fairness, his post was unattended for just 22 hours.

I pondered replying myself yesterday when I first saw it, but it is 
indeed a tricky goal, something very few people in all the world even 
attempt, in any language.

While it's true that Ubuntu and more recently Microsoft have begun 
exploring convergence strategies for a single adaptable, scalable set of 
UI conventions across all device types, the reality is that to date 
neither has been enormously successful (though the night is young, and 
the research and APIs still in early days).

Apple still has the belief that every category of devices require their 
own unique OS, with their own interaction models and supporting APIs.

Consider the tablet:  its screen size is the same as a laptop, so while 
a phone is a radically different beast we might expect a tablet and a 
laptop to be able to share a single UI.

And in some cases they can, but not well on most systems other than 
Gnome-based Linux distros because most have much smaller controls 
completely unsuitable for use with both a pointer and a finger.

You've extended Alex' original question into the realm of the browser 
here, in a way I believe can be very helpful:

 > I would love to be able to do this in LC because I love the language,
 > but the only practical way I have found so far is to write browser
 > apps in JQuery.

This is a useful consideration, because there's much we developers of 
native apps can learn from the web world driven today by responsive 
design, making a single style sheet that adapts the UI for any size 
screen and accounts for the very different interaction modes of pointer 
and finger.

Some complain that learning web development is hard because it requires 
attaining competency with three different subsystems:  HTML, CSS, and 
JavaScript.

But I believe this is a feature, not a bug.

When building native apps, decades of software engineering "best 
practices" have long encouraged us to do the same: separate data, 
layout, and code as much as practical, so changes to one have minimal 
affect on the others.

If we apply what we've learned from web development to making 
multi-device apps in LiveCode, our app's core business logic can be well 
factored into libraries and behaviors, with data brought into the app 
and saved outside of the app, and layout containing so little code those 
stack files are almost as slender as a Cocoa NIB file.

I'm only just starting to build mobile apps in earnest, but I've been 
making multi-platform desktop apps in LC since the '90s, before LiveCode 
or even RunRev existed.   Even when working in the more self-same world 
of the desktop, accommodating user expectations on both Mac and Windows 
has never been trivial.  LiveCode makes it about as easy as it can be, 
but the differences are not small and require some thinking to handle well.

Extending that to include iOS and Android as well is accomplishable, but 
no more simple than accommodating OS X vs Windows.  It requires spending 
time reading the HIGs for each platform, being willing to move things 
around as users are accustomed to on each, and making that as simple as 
practical by centralizing code away from the UI.

Now that I'm building multi-device-type apps, for myself I find it 
easier to make separate layouts for phone and desktop, allowing each to 
take best advantage of what the device and its input models offer.

I tend to build things with reusable behavior-driven groups, which 
allows me to have a toolbar common to iOS and Android but placed at the 
top for Android and the bottom for iOS, as each HIG suggests.

The toolbar for desktop not only has more space but more importantly 
supports in some cases different tasks, because the device type serves a 
different set of use cases.

The card controls the layout of the groups within it, so a different 
card for mobile, tablet, and desktop lets me optimize the layout for 
what the user could expect to do for each, and since the underlying 
business logic is the same for all very little of my central libraries 
are affected by whichever UI happens to be in use at a given moment.

There are many ways to solve such problems, and the way I find useful 
for me in making productivity apps will no doubt differ from others, and 
certainly differ a lot from those making games where the UI and UX are 
very, very different.

But in all cases I believe two things:

1. Making software is by its nature inherently complex, requiring
    study and more than a little typing.  LiveCode makes it far
    less difficult than most tools, but I doubt making good software
    can ever be truly "simple".

2. We can learn from the world of responsive web design to reinforce
    best practices with native app development: factoring code, data,
    and UI to minimize interactions between them and thereby maximizing
    flexibility across device types.

-- 
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
____________________________________________________________________
Ambassador at FourthWorld.com http://www.FourthWorld.com


 >
 > 
--------------------------------------------------------------------------
 >
 > Alex Tweedly wrote:
 >
 >
 > I'm considering developing a multi-platform app; i.e. ont where the
 > same app runs on both "desktop" and mobile.
 >
 > On the 'desktop' platforms it will use 'standard' menus, and that will
 > be the main "command" access (along with an optional toolbar, most
 > likely, but the toolbar will give access to a limited number of most
 > often used commands/features, rather than to "everything).
 >
 > But, on mobile, there are no "standard menus", and although they are
 > appearing on a few apps (as homegrown menus), they aren't the usual
 > convention on mobile devices. So, I will have a combination of icons,
 > buttons, etc. on the mobile platforms.
 >
 > I suspect that means I'm in the same boat as many other people have
 > already been in, and I'd like to benefit from your experience.
 >
 > If you have developed an app running on both desktop and mobile:
 >
 > 1. did you follow this same split on how your main command structure
 > was invoked ?
 >
 > 2. how did you manage this ?
 >      a. really one app with per-platform customization
 >      b. two (or more) apps with as large a percentage as possible put
 > into library stacks (or similar) as possible, with separate menu-based
 > vs button-based apps.
 >      c. something else that you could readily explain
 >
 > Many thanks
 > Alex.