Mark,

At first I wanted to object to the need for JPEG only for large images as all 
of the research that I have done (especially concerning transparency issues) 
has told me to never use JPEG (except for the web) in most of my apps but then 
I realized that I have not tested those same results for iOS and Android 
engines, so I will need to do those tests again to verify/reject my findings. 
That said, using 2048 png's with transparency layers on fourteen cards with 
special visual effects and playing song files on one channel and a voice over 
on another channel did not slow down either the logic code or the effects code. 
I created a Ken Burns effect in LC and it runs as smoothly with the larger 
images as it does with smaller variations. So I'm not sure what would 
constitute a stack being 'much larger' than it needs to be - in my first case 
it was the main stack that was large and now it is the images folder that is 
large - either way the download is going to be the same size and be too big for 
cellular download (which is why I believe Apple has that warning in the first 
place.) I would not think that 14 retina sized images on 14 different cards is 
too large for a mobile app and that instead they must be referenced and that 
that would be a requirement. Normally I think if it was like 50 images it 
should be referenced but not just 14. Most LC projects I have seen all use 
lower quality images or regular 1024 images enlarged for retina via code, but 
they are definitely not retina images.

All of that said, I think what you stated is spot on and should be included in 
a best practices type document somewhere for mobile development. Maybe with 
some recommendations for audio and compression comparisons.

Thanks,

Tom

-- Tom McGrath III
http://lazyriver.on-rev.com
mcgra...@mac.com

On Jun 5, 2013, at 5:21 AM, Mark Wilcox <m_p_wil...@yahoo.co.uk> wrote:

>>> I may be wrong about this (can anyone verify?), but if you're building for 
>>> iOS 5 or later, you should be perfectly safe selecting armv7 only and 
>>> building for that, since any devices capable of running iOS 5 and above are 
>>> armv7 devices only.
> 
> 
> Yes, this is correct and a good idea - the iPhone 3G was the last device to 
> have an ARMv6 processor and that can only run iOS 4.3 or earlier - that's why 
> Apple has dropped support for armv6 builds from the more recent Xcode 
> versions.
> 
> I expect (really hope) that LiveCode only duplicates the engine code within 
> the Universal binary and puts the main stack in a data section that is shared 
> by both code variants - if that's the case, this might only save you a few 
> megabytes of engine code, but you should do it anyway - iOS5+ with armv6 is 
> pure waste.
> 
> I'd not seen the main executable size issue before and a quick Google 
> suggests both this and the not yet mandatory PIE warning are new.  This is 
> either a subtle crackdown on low quality apps produced by tools other than 
> XCode or there are some new products or tools on the way which will care 
> about this in the future.  I'll bring it up on the engine forum.
> 
> As I understand it, only the main stack is actually bundled inside the 
> executable in a standalone, so a simple fix would be to create a launcher 
> stack as your main stack which simply loads the previous main stack which you 
> can include in the bundle separately.  However, creating apps much, much 
> larger than they need to be is not friendly to your users.  Large images 
> should be JPEG compressed - if they contain text that loses quality due to 
> JPEG compression then split the images up (or if it's all text, store it as 
> text not an image!).  Audio should also be in a suitable compressed format 
> (i.e. not WAV).
> 
> In this case it sounds like LiveCode 6's application browser might be handy 
> for finding out what's actually inside the stack easily, then removing all 
> the media and referencing it externally.  Otherwise it might be easier to 
> rebuild the stack by copying the scripts across into a new one that only 
> references external media from the start?
> 
> Mark
> 
> 
> ________________________________
> From: Chris Sheffield <cmsheffi...@icloud.com>
> To: How to use LiveCode <use-livecode@lists.runrev.com> 
> Sent: Monday, 3 June 2013, 20:54
> Subject: Re: First App rejected for odd reasons
> 
> 
> Another thought. In the standalone settings, are you building a universal 
> binary? I may be wrong about this (can anyone verify?), but if you're 
> building for iOS 5 or later, you should be perfectly safe selecting armv7 
> only and building for that, since any devices capable of running iOS 5 and 
> above are armv7 devices only. This may also reduce the size of your 
> executable.
> _______________________________________________
> 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

Reply via email to