mobile apps - getting started

[Chris Sheffield]

Jacque,

Super helpful! Thank you for taking the time to respond. I'm looking forward to this project but right now it seems a little daunting. I'm glad to know that most code "just works".

Thanks again,
Chris


On Sep 30, 2011, at 2:22 PM, J. Landman Gay wrote:

> 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
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode