mobile apps - getting started

[J. Landman Gay]

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 
hierarchy.

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 
beginning.

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 
controls.

> 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