Preview of Resolution Independent Control library for RevMobile

[Thomas McGrath III]

My very first attempt was to include scalable images in my own custom groups and show the appropriate image on the right devices. But I experienced sluggishness in going from card to card and rotating interfaces. I did not delete the unused images once the device was know and that might have helped performance. So I dropped the approach to look for better ways.

In my first five or so apps I created the 'exact' layout and size of all of my custom controls in both their portrait and landscape modes on square cards and captured/stored that information pre-build. Then when launching on a device I loaded the appropriate set and its' landscape/portrait set. Two problems with that approach that I encountered: The first is that capturing 'all' properties is still not possible in the IDE in one simple command and the second is that any LC native controls will not draw at 2x size simply or reliably (You can fudge most properties but not all and I ended up creating custom versions of the native controls that I needed). Layout and size issues were also a problem when using native iOS controls with both custom and native LC controls with this approach.

This turned out to be a lot of work. So I decided to create substacks for each device/resolution combo - which is a lot less work in laying out controls but is more difficult in scripting. The native control issue is still there however. I managed a few apps this way and it was easier to get my mind around and for exact laying out of controls.

The last batch of apps I wrote (one of which I am showing at ISAAC here in Pittsburgh today) I decided to restrict the devices ti would run on and to create all custom controls and templates for those for pages in the app.

With the success of these last few apps I decided to build a set of custom templates for each and every type of 'view' that I tend to use in my apps and re-using them in all my future apps. This is a lot of upfront work but then when building an app I can just focus on the app itself and not the controls. But, this doesn't work for every situation and other methods are still needed.



-- Tom McGrath III
http://lazyriver.on-rev.com
3mcgrath at comcast.net

On Jul 29, 2012, at 7:13 PM, Monte Goulding wrote:

>> I haven't said much in this discussion because it's all such a mess I don't know where to start. But to be honest, I agree that scaling would be better in general than sets of presized images, since as you say, they'd all need scaling anyway on some devices.
> 
> Good point. I'll try to clarify my thoughts and perhaps start a new thread with a more appropriate subject.
>> 
>> But if someone does want to implement separate image sets, I think it could be done with what we have now, without needing an extra engine property. I even started down that road on my current mobile project, but gave it up because it was just too fiddly and unreliable.
> 
> I agree. The simplest way to handle this would be a library function. I rarely rely on the current directory being what it should be. I know I always reset it to the original after changing it for whatever reason but relying on everybody doing that seems a risk. I generally do something like the following because it works in development and standalone:
> 
> put the effective filename of this stack into tPath
> set the itemDel to "/"
> put "images/myimage.jpg" into item -1 of tPath
> 
> Now it would be really easy to write a function that returned a full image path given a relative path from the image folder. Assuming we know what density range we are running at we could easily add in the extra folder. Then what happens if the image isn't there. In java on android it searches up the density ranges for an image to scale down. If it doesn't find one it searches down for one to scale up. If we did that we would need to either scale the image before returning the path or return it with a scale difference from the environment. That all sounds complicated so it might be better to either not support that or just go with the live scaling thing.
> 
> Cheers
> 
> --
> M E R Goulding 
> Software development services
> Bespoke application development for vertical markets
> 
> mergExt - There's an external for that!
> 
> _______________________________________________
> 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