We're using DFP responsive ads but cannot figure out how to get it to show the largest size available that will fit. For example, if both leaderboard (728x90) and a super leaderboard (900x90) creatives exist, it should show the super leaderboard when the browser is wider than 900px (desktop), from 900px to 738px wide (tablet) it should show the leaderboard.
Existing mapping (I've left out the rest of the ad code for clarity):
var leaderboardMapping = [
[[900, 300], [[900,90],[728,90]]],
[[738, 300], [728,90]]
];
This always shows the leaderboard at tablet size, but the problem is, this will alternate between the leaderboard and super leaderboard at desktop size.
I've tried this to specify preference, but the second value of the same size seems to be ignored.
var leaderboardMapping = [
[[900, 300], [900,90]],
[[900, 300], [728,90]],
[[738, 300], [728,90]]
];
The only solution we have at the moment is to use DFPs device targeting for tablet, but that doesn't fit well with use of responsive design and will miss out on serving ads to desktop users with their browser < 900px wide.
We ended up with a solution that is not ideal but works for us so I thought it's worth sharing.
We still use the initial mapping
var leaderboardMapping = [
[[900, 300], [[900,90],[728,90]]],
[[738, 300], [728,90]]
];
In the line item we then use weighted creative rotations
Then set the larger creative (900x300) with the highest weight possible (100) and set the smaller creative (728x90) with the lowest weight possible (0.001).
If my maths are correct the smaller size will now only show 1 / 100,000 impressions. Not perfect but negligible for our circumstances.
For those coming along later and finding this post. This can now be done using Creative Targetting. You can assign targetting for the different ad sizes you provide, so an MPU (300x250) can be served on mobile only, while a Billboard can be served on Desktop and tablet. All within the same line item.
Related
when i use google sheet image function,
then i found image's resoltion lower.
so i test 3 case.
case1 : image function use, hosting site 1(not google)
case2 : image function use, hosting site 2(not google)
case3 : google sheet image insert(insert -> image)
and i found only case3, there isn't low resoultion problem.
how can i do?
*here google sheet url that i tested
https://docs.google.com/spreadsheets/d/1IB9yMDXFrSZDUPbIGFy92BUWszd1Qzx2kdJEuLMpBe8/edit?usp=sharing
there are modes
mode – [ OPTIONAL – 1 by default ] – The sizing mode for the image
1 resizes the image to fit inside the cell, maintaining aspect ratio.
2 stretches or compresses the image to fit inside the cell, ignoring aspect ratio.
3 leaves the image at original size, which may cause cropping.
4 allows the specification of a custom size.
in your case, you should be using:
=IMAGE(B2, 3)
but keep in mind that the original size is 1266×420
so to get the original it would be:
=IMAGE(B2, 4, 420, 1266)
your C2 cell dimensions are 572×200 so for such a small cell it's best to use a smaller source. you can use https://andrew.hedges.name/experiments/aspect_ratio/
and some online resizing tool like https://picresize.com/
https://i.imgur.com/ptwnpnG.png
=IMAGE(B2, 4, 189, 570)
I'm using multi images and counting font sizes using Display.getInstance().convertToPixels(sizeInMM), which on majority of devices works great. On old android tablet, if I set font size to 2.1mm, it actualy has that size. The problem is with newer small devices with retina display. 2.1mm font on iPhone 6 is only 1.9mm, which is not that bad, but on iPad mini with retina, it's only 1.1, which is pretty much unusable... How can I overcome that limitation?
I was thinking about adding some kind of correction to the conversion like:
if (isIOS() && isTablet()) {
return Display.getInstance().convertToPixels(sizeInMM * 2);
} else if (isIPhone6_OrHigher()) {
return Display.getInstance().convertToPixels(sizeInMM * 1.1);
} else if (...) {
...
}
But I think that's just not the way cn1 is designed. At least in doc, this is not recommended...
That's a pretty problematic scenario. Apple doesn't want us to detect iPad mini, some hacks exist and we considered using them to give a slightly different DPI for iPad mini but ultimately they are hacks so we decided to avoid that and treat it like an iPad which is what Apple "wants".
That sounds bad but it's generally a good practice, you are relying a bit too much on the accuracy of the sizes returned by convertToPixels which is a problem as these sizes are often reported incorrectly by devices especially on Android. This usually isn't a problem if elements are too big but as you discovered it is an issue when elements are too small which is why we usually aim at 2.5mm font size and use 2mm only for very small text.
Depending on which skin I use in the simulator, the result from the following method differs :
Display.getInstance().getDeviceDensity();
The results have nothing to do with the real device density since for a Xoom skin it outputs 30 (149 ppi in reality), for a an Iphone 6 it outputs 50 (329 in reality).
I noticed that because I need to translate char height measured in Gimp (72 dpi) into the device world so that it looks alike on an image.
Any help on that topic would be appreciated!
Cheers
The JavaDocs for getDeviceDensity state:
Returns one of the density variables appropriate for this device,
notice that density doesn't always correspond to resolution and an
implementation might decide to change the density based on DPI
constraints.
Returns:
one of the DENSITY constants of Display
The DENSITY constants refers to one of these.
Notice you can also use convertToPixels which is probably a far better API to use. The density API is mostly used to pick the right multi image and should rarely be used in user code.
The question isn't exactly concerned with touch develop rather just basic programming "structure" or syntax.
what I am trying to do is create a simple compass working on the phones heading capability. The heading capability just spits out degree readings to several (like 12) decimal places.
Anyway, even just letting the phone spit out the heading, eventually the phone will crash, why is that? Running out of memory?
The reason I came here is because of this:
I want to update the page with a photo of an associated rotation based on degree readout. I can't figure out how to do something like if 0 < x < 1 post this picture. Since the heading readout varies like 321.18364947363 and 321.10243635471
So currently I am testing this: several if / if else statements saying if heading output is 1 post picture with 1 degree rotation, 2 post picture with 2 degree rotation. This definitely and guaranteed crashes the phone. Why? Memory?
If you are a touch developer, would it be easier and more sane to simply take a round object, center it in relation to a square image and use it as a sprite or object which then you can dictate what angular velocity and position the object has without doing / using 360 individual images.
GAH! Damn character limits / thread format
this is what follows what I last wrote below for anyone that cares :
The concept seems simple enough but I am basically a programming noob, I was all over the place trying to learn Python, Java and C/C#/C++. ( I wrote this on my Windows Phone 8 but I was unable to copy the text ( GAY ) ) I am happy to have come across Touch Develop because it is better for me as a visual learner. (Thanks for the life story )right ? haha
The idea would have been to use this dumb pink against black giant compass with three headings / points of interests namely A fixed relative north, the heading and a position given by the person to be found's lat and long coordinates relative to the finder's phone's current location (lat and long ). This app in my mind would be used for party scenarios. I would have benefited from this app had the circumstances been right, I was lost at a party and I had to take a cab home for $110.00 because I didn't drive to that party.
I'm using PostGIS on ruby/rails, and have created a simple box-like polygon under which I wish to search for land parcels in a county. The st_overlaps tool has worked for this before and it has worked this time, sort of.
So I created the polygon to search for parcels (multi-polygons, as it turns out) underneath it
factory = RGeo::Cartesian.factory
coords = [[1554780, 1101102], [1561921, 1062647], [1634713, 1097531], [1630867, 1140657]]
points = coords.map { |pair| RGeo::WKRep::WKTParser.new.parse("POINT (#{pair.first} #{pair.last})") }
ring = factory.linear_ring(points)
polygon = factory.polygon(ring)
After running the active record call:
Parcel.where{st_overlaps(:parcel_multipolygon, polygon)}
I get 157 results. Far less than expected. I exported them a kml file using a custom script of mine. I will upload it soon for viewing.
What you'll see in that kml once loaded in Google Earth, is a parallelogram of pins marking parcels whose areas (polygons) are clearly saddling the outer ring of the parameter-polygon I created to search under. There are so many parcels along these invisible lines in such a clear, distinct shape, the fact that there are no pins in the middle of the shape clearly indicate that the search results were only at the overlappings of parcel multipolygons with the exterior edges (LinearRing) of the search polygon.
Based on my re-reading of the documentation for st_overlaps, I'm left puzzled as to what seems to be the problem here.
Here's a link to view the kmz export. (coordinates converted to geographic before export). You can view it in your browser. The search-polygon itself is not included, but its easy to see where its exterior ring is
https://docs.google.com/file/d/0B5inC0VAuhH1TXdTbWQ2RngxZk0/edit?usp=sharing
I think it is behaving as expected. St_overlaps will give features that actually lie on top of each other. If you want all features inside the polygon try ST_Intersects.