Go to card [with effects] is slow on Android

Charles E Buchwald charles at buchwald.ca
Mon Jan 27 13:23:40 EST 2014


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 <scott at tactilemedia.com> 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" <roger.e.eller at sealedair.com> 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 <scott at tactilemedia.com>
>> 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
>> 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
>> 
> 
> 
> 
> _______________________________________________
> 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

--
Charles E. Buchwald
charles at buchwald.ca




More information about the use-livecode mailing list