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 | jac...@hyperactivesw.com > HyperActive Software | http://www.hyperactivesw.com > > _______________________________________________ > 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
