Nativescript: Content-scaled image manipulation

[jlooper]

Currently, to support content scaling, the developer is obliged to create three images, like img.png, [email protected], and [email protected] in a gradation of sizes to be handled by small, medium, and hi-res screens. NativeScript is great about taking the images that you add to your app and placing them in the proper folders for iOS. For Android, I believe we have to rename them move them manually, as described here: http://nativescript.github.io/quick-start/#chapter2.4.

This seems pretty labor-intensive. Could NativeScript's build process take a large image, scale it down 2x and 1x, and add them to the proper folders automatically for iOS and Android? It seems like we're almost there, we just need to tweak the build process.

We think this will help onboard web developers, who don't love manually rescaling images and pasting them everywhere :)

[tjvantoll]

+1

When you want to show an image in an app, to me there are two ways to go about that:

• 1) You want to take advantage of the extra pixel density and create different images for different device types—aka your [email protected] is not just a straight resize of [email protected].
• 2) You want to show the same image on devices of all pixel densities.

What's currently implemented in {N}, and what we have documented here, is great for scenario #1.

For for scenario #2, which I would guess is far more common, having to create 6 images—AppResources/iOS/img.png, AppResources/iOS/[email protected], AppResources/iOS/[email protected], App_Resources/Android/drawable-hdpi/img.png, App_Resources/Android/drawable-mdpi/img.png, and App_Resources/Android/drawable-ldpi/img.png—is indeed labor intensive as @jlooper says. It'd be great if the NativeScript CLI (or the modules, if possible), provided some solution for images to look great from a single source.

[valentinstoychev]

Isn't #2 ugly? Why no use automation to create the images and use #1?

[emiloberg]

Reason to do it the #1 way is simple:

Example: High pixel density screens allows us to create high def images with lots of fine details, however, when that image is displayed on a lower pixel density screen it might become kinda ugly. Therefor we need to remove/rework some of the details for lower density screens.

But, what we need is a way to do both #1 and #2.

[jlooper]

Personally I wouldn't worry about #2, as it's not the normal 'mobile' way to develop - we are used to making two or three versions of our images to satisfy iPhone4 as well as hi-res iPads. I'd just love to have {N} have a built-in way to content scale. It would give us a leg up on the competition. For example, the Appcelerator docs tell you flat out to optimize your own images:

http://docs.appcelerator.com/platform/latest/#!/guide/Image_Best_Practices-section-30082525_ImageBestPractices-Optimizingimages

If we can't help with the actual optimization, what if we allowed users to put the three scaled images into a location and then {N} build process places them, renamed appropriately, into the right folder for the platform?

[tjvantoll]

@jlooper and I talked this over. Our ideal structure is something like what's shown below. There'd be some special folder where you put all of your app's images in (app/images or whatever), using some convention to designate three different pixel densities.

    images
        1x
            logo.png
        2x
            logo.png
        3x
            logo.png

The NativeScript CLI could take all images, and move them to the appropriate places in App_Resources. For instance with the above example, app/images/base/3x/logo.png would move to App_Resources/iOS/[email protected] and App_Resources/Android/drawable-hdpi/logo.png. This provides a solution to #2.

If the user only provides a 3x image, in theory, the CLI should automatically be able to generate the 1x and 2x versions automatically. This extra bit of logic would provide a solution to #1.

Obviously implementing this would be a bit of work, and there are potentially some performance implications, but if you read through what you currently have to do to use correctly scaled images, I do think it's a bit much, and it'd be nice to have something easier to use longterm.

[emiloberg]

I'm touching scope creep here but a nice addition would be to be able to supply SVGs which gets converted to pngs (of all sizes). Pretty much what I'm doing in this gulp script.

But as said, scope creep and maybe not at top of the priority list.

[ligaz]

Hey guys,

Have you played with appbuilder resource create command? Do you think if we extend its usage to support arbitrary images (not only icons and splashes) is the way to go?

[jlooper]

late to reply, but if we could run our images through some builder and scale everything, renamed appropriately, and stuck in the right folder, my life would be complete :)

[enchev]

Hey folks,

Do you think we still need this?

[tjvantoll]

@enchev: I initially supported doing this, and still think something like this might be nice. But since this issue was first created the Brosteins built http://nsimage.brosteins.com/, and that tool simplifies the manual work to create these images considerably.

So, my vote is to close this unless there’s additional community demand, especially as there have been zero comments in the last eight months.

[enchev]

Thanks @tjvantoll! I'll close it for now.

[julien1619]

Hi! I'm starting to develop a new project using NativeScript and I didn't find any way to automate the images generation process. So I've created a hook that you can install in your project and it will automatically generate all needed images.

https://www.npmjs.com/package/nativescript-images-generator-hook

I'm sharing it here because I think it could be very useful.

[NathanaelA]

@julien1619 - Good work, are you aware the TNS command line offers some image generation (resources generate splashes and resources generate icons). In addition; the website (disclaimer: site is mine) http://images.nativescript.rocks also offers much more advanced image generation. :grinning:

[julien1619]

@NathanaelA Thanks! Yes I saw these solutions but I needed a way to automate the full process so using a webservice was not an option. Moreover, with this hook you have to commit only one high-res image per resource, the other ones are generated during the build process directly inside the right platform folder.

[NathanaelA]

@julien1619; I guess our work flows much be completely different. I prefer to upload the single high res image and then just unzip the resulting folder into the app_resources folder and be done with it. I don't need to regenerate my images after doing it the first time. :grinning:

But thanks, for creating a hook method I'm sure their are others that have the same work flow as you, so this should now allow both to be handled. :grinning:

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.