mobile apps - getting started
J. Landman Gay
jacque at hyperactivesw.com
Fri Sep 30 16:22:23 EDT 2011
On 9/30/11 1:25 PM, Chris Sheffield wrote:
> What I'd be most interested
> in hearing is what's the best way to do a cross platform mobile app?
> Two separate stacks for the interfaces, with common code libraries to
> perform the main functionality?
That's one way. I didn't choose it though, I use a preOpenCard handler
in each card to adjust the layout. An advantage is that you don't need
libraries necessarily, you can use the same code and the normal message
Another reason is that no matter what, there will be a user with a
resolution you haven't planned for. That means you need a layout script
anyway, even if you do use separate stacks, so for me it was easier to
just put it all in one stack. You'd also need a layout handler just to
accomodate device rotation (if you are going to support that) so you may
as well just bite the bullet and do the resizeStack thing from the
When writing resizeStack (layout) handlers, you'll almost always want to
use ratios to calculate positions and sizes. That way objects will
always fit. If you hard-code pixel locations, something will be wrong on
somebody's Android device, because they come in an infinite number of
resolutions. Right now iOS is pretty consistent, but if you're writing
for both platforms then you may as well do ratio calcs from the start,
which will work everywhere.
> Most controls will be skinned using custom
> images. Do the other features in MobGUI make it worth the price?
I'm not sure. My app also uses a custom skin so I didn't go the MobGUI
route. Actually, even though I've read through the docs, I'm not quite
sure what advantages MobGUI would provide if you aren't using native
> I may need to make use of a data grid at some point. Is the LC data
> grid compatible with mobile apps? Am I going to run into any problems
> with performance?
I'm not using one in my project but I know they are supported. There are
examples on the forum and, I think, in the RR lessons on how to get them
to scroll and operate smoothly. Probably someone else can answer this
part beter than me.
> Are there any other "gotchas"? Things I should be aware of up front
> before I get too far into this and wish I had done something
> differently? Is anyone else developing a cross-platform mobile app?
> What kinds of successes/failures have you experienced?
Like you, I'm developing for tablets only and I've found very few cases
where I need to branch the code based on platform. If you are okay with
basic sound playback, you can use the generic "play" command everywhere;
if you want more control on iOS then you can branch on that platform and
use the more advanced sound controls that allow you to queue sounds
and/or prepare them ahead of time to avoid lag. My sounds are short,
basic sound effects. I started out branching but have recently changed
to just the "play" command since I don't need queueing and it makes the
code base consistent.
Scrolling is beautiful on iOS, rotten on Android. There is no native
scroller on Android so you'll need to branch the code for that, and
write a script to fake it on Android. I've tried four different scripts,
none are smooth. If you don't have too many things to scroll, you can
make life easier by only putting nonscrolling objects/groups on a card.
That's not always possible. I was able to do it in one app, but not in
another. Scrolling a list on my low-tech cheapo Android tablet is very
jerky. Higher-powered Android devices would probably do better. If you
aren't going to do an Android build for a while, maybe LiveCode will
catch up by the time you're ready and this won't be an issue any more.
If you are going to show anything in a browser control, you'll need to
branch for that. iOS has an embedded one, Android needs to launch the
system browser. In practice they both end up working fairly similarly
because Android has a universal "back" button that returns you to the
app wherever you left off. Alternately you could call out to the system
browser on iOS, but if you do that your app will quit and lose its
place. It was easier for me to embed the browser on iOS than to keep
track of the app state and restore it on next launch.
Oh right, the hardware Back button. Android has one, iOS does not. I
show a Back button on the card for iOS, and don't show it on Android
where users are accustomed to using the hardware Back button. You'd be
okay showing a back button on both platforms, but for Android you
wouldn't want the icon to look like an iOS one.
If the stack is completely skinned this won't apply, but I do have one
field that shows a list of options that I try to make look semi-native.
I branch the code on preOpenCard, and make the field backcolor, hilite
color, and font appropriate for the OS. I also have one option that
needs a "more"/"continue" button, and I swap out the icon for that based
on the OS.
That's all I can think of off the top of my head. Most of your code will
be universal, it's pretty amazing. In fact, I started out wanting to do
an Android-only app because there aren't many of those yet. But on a
whim I built for iOS just to see what would happen, and found that there
were only a couple of things I needed to change. So my app is now headed
for both platforms eventually.
Jacqueline Landman Gay | jacque at hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
More information about the Use-livecode