This isn't so much about 'multi-platform' development but about designing apps for different interaction / display combinations.
I'd say the key thing is to separate your design into modelcontroller and view. In the ideal case a UI is a 'thin' layer on top of an API based model which encodes all the actual logic of the app. 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. Ideally this means that you can have different stacks (or cards even) specialised to different UI requirements (in terms of layout and interaction). If the only real code in the UI part for a particular target is pertinent to that target alone, adding new layouts is straightforward and you avoid bugs creeping in because of 'duplicated code' gremlins. Just my 2 pence, Mark. Sent from my iPhone > On 11 Jan 2016, at 16:06, Alex Tweedly <a...@tweedly.net> 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. > > _______________________________________________ > 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 _______________________________________________ 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
