I think it'd be a little too specialized for ClientBundle itself to support 
such a thing - that said, a custom *ClientBundleGenerator subclass could be 
used in conjunction with file naming conventions to work this out. The 
basic idea would need to be that each file has one of several suffixes, and 
that there is some bootstrap property (akin to user.agent and locale) to 
decide which suffix to have built in to that ClientBundle impl.

Or, take the approach of allowing standard resources as well as DPI 
specific resources, and define a new ImageResource type with a matching 
ResourceGenerator. Use the ImageResourceGenerator's locale specific wiring 
as a guide for picking out a dpi-specific file -- or if you aren't using 
the i18n features, use this locale _as_ your dpi.

But yes, my suggestion had been to create appearances - this would go 
beyond just images then, and allow you to have the rest of the control that 
android has, with defining new layouts, etc - phone vs tablet vs desktop 
probably need more than just different images, but in some cases, not a lot 
more.

On Thursday, April 19, 2012 12:45:48 PM UTC-5, Evan Ruff wrote:
>
> Colin,
>
> This seems to be similar to Jens suggestion. I just read over the 
> Appearance Pattern information and it seems like it would be quite a lot of 
> code for every Widget in the application. Are you suggesting that the 
> ImageBundle itself have an appearance abstraction, or that each Widget have 
> a HDPIAppearance, LDPIAppearance, etc?
>
> Thanks,
>
> E
>
> On Tuesday, April 17, 2012 4:40:35 PM UTC-4, Colin Alworth wrote:
>>
>> It could be possible to wrap your ClientBundles in an appearance 
>> implementation, and use replace-with declarations on that, to check for dpi 
>> when the app starts up. Check out the notes on the appearance concept at 
>> http://code.google.com/p/google-web-toolkit/wiki/CellBackedWIdgets#Appearance_Pattern
>>
>> -Colin
>>
>> On Tuesday, April 17, 2012 4:49:25 AM UTC-5, Jens wrote:
>>>
>>> What about a custom property for deferred binding in a .gwt.xml file and 
>>> a small javascript that fills its value based on window.devicePixelRatio. 
>>> Older iOS devices have a ratio of 1 while the retina devices have a ratio 
>>> of 2 because each pixel is doubled. So you could define your own ratio 
>>> ranges and map them to property values like "ldpi", "mdpi", "hdpi".
>>>
>>> You could then create a Factory for your bundles and use deferred 
>>> binding to swap factories between devices based on their pixel density. I 
>>> dont think you can directly swap out ClientBundles as they are generated by 
>>> GWT.
>>>
>>>
>>> -- J.
>>>
>>>
>>> Am Dienstag, 17. April 2012 11:21:41 UTC+2 schrieb Evan Ruff:
>>>>
>>>> Hey guys,
>>>>
>>>> So I'm designing an application to be used on tablets and phones. With 
>>>> the introduction of the new iPad, my images are getting BIG. Real big. 
>>>> HUGE. They're so big at this point, that it's really unwieldy to download 
>>>> the ginormous ImageBundle; further, when scaled down in the browser, the 
>>>> images aren't presentable anymore on smaller devices.
>>>>
>>>> I was wondering if anyone had started developing a 
>>>> resolution dependent ImageBundle, where I could define screen densities 
>>>> and 
>>>> have corresponding packages, much like the Android concepts. If not, I 
>>>> believe that this would be a useful extension to the framework as things 
>>>> like PhoneGap, MobileObjects and mgwt are really starting to push GWT 
>>>> successfully on to the mobile devices. Could someone who has some 
>>>> familiarity with the ImageBundle source point me in the direction of the 
>>>> Linker for that class?
>>>>
>>>> Thanks,
>>>>
>>>> E
>>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/TUCQhjWww-AJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Reply via email to