Hi Scott and Roger, I've done this with an iPad app that was sort of magazine like. I grouped a bunch of graphics in line horizontally on one card, and used a mobile scroller to handle paging between them. The scrolling was beautiful, and since it was a relatively simple app used as a museum interactive, it wasn't that much of a pain to set up.
It worked well, except that I ran into the card size limit. That is, there is a limit to the pixel width of the stuff on the card... I think it's 32,000 px but I'd have to look it up or check my notes. I wasn't using retina size graphics, which would have made the situation worse. The width of my total number of pages exceeded the limit, so I ended up with an awkward "click this button for more" in the middle of the scrolling to jump to a second card and set of images/pages. Years ago, working on a game in SuperCard, I used a scheme that dynamically loaded the content for the next and previous cards/pages/images. I'm kind of thinking that something like that could work here... just haven't tried it yet. Maybe it could be a way to get around the limit. Cheers, - Charles On 26 Jan 2014, at 3:04 PM, Scott Rossi <[email protected]> wrote: > Hi Roger: > > Unfortunately, the built-in transitions always seem laggy. I don't know > for sure what's going on under the hood (bonnet?) but I imagine LC is > essentially creating screenshots of the current screen and destination > screen before executing the transition, and then generating the transition > effect with those images. Combine this with the fact that most mobile > screen transitions are controlled by a swipe gesture where you can > partially swipe halfway across the screen, stop, and swipe back -- and > you'll quickly see that you can't recreate native transition behavior > using LC's built-in effects. > > The limitations of built-in effects are compounded by the fact that only > one transition can occur at a time, while both iOS and Android often do > multiple transitions in multiple regions of the screen simultaneously. > > Native mobile scrollers seem to operate in a similar fashion (using a > capture of the region to scrolled), but appear to be more optimized. One > way (and it's likely an unrealistic way) to get closer to a more native > user experience would be to build all the screens of your app as subgroups > of one master group on a single card, with each subgroup spaced out the > width of the screen, add a horizontal native scroller, and use the paging > behavior of the native scroller to navigate between groups. > > Of course, this is probably a solution for folks with strong thresholds > for pain and still plenty of hair on their heads. Memory could be an > issue (both machine and human). > > If somebody has a better solution for getting good native screen > transitions, I would love to see it. :-) > > > Regards, > > Scott Rossi > Creative Director > Tactile Media, UX/UI Design > > > > > On 1/26/14 8:19 AM, "Roger Eller" <[email protected]> wrote: > >> Scott and Jacque, >> >> I have combined parts of both of your advisements, plus one from the >> MobGUI >> forum. I didn't mention that my buttons are "Option groups" (acting as >> buttons), so I replaced the hilite part with: >> >> send "mouseDown" to group "Option1" -- only changes which option in a >> cluster is selected >> >> Overall, it feels a bit faster than before, but still laggy compared to >> other apps I've downloaded from the Google Play Store. Thank you for the >> tips! >> >> ~Roger >> >> >> On Sun, Jan 26, 2014 at 2:42 AM, Scott Rossi <[email protected]> >> wrote: >> >>> Hi Roger: >>> >>> One place to start might be the click. Why do you have a click >>> occurring? >>> >>> Regards, >>> >>> Scott Rossi >>> Creative Director >>> Tactile Media, UX/UI Design >> _______________________________________________ >> use-livecode mailing list >> [email protected] >> Please visit this url to subscribe, unsubscribe and manage your >> subscription preferences: >> http://lists.runrev.com/mailman/listinfo/use-livecode >> > > > > _______________________________________________ > use-livecode mailing list > [email protected] > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode -- Charles E. Buchwald [email protected] _______________________________________________ use-livecode mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
