One of the problems with native maps is that they work very differently between the device and the simulator. This is because we use
MapComponent on the simulator and as a fallback on the devices where Google Maps isn’t available. We just committed a new mode for maps that allows you to use the Google HTML maps as the fallback instead of the
This is faster, has better support from Google and is more similar to the way maps work on the physical device because the browser component is also a peer component so similar restrictions will apply. This is off by default since the HTML maps require a key and right now we didn’t finish mapping all the components. This also needs some server functionality so I’m not sure when this will land in the actual extension but it’s already there is you build from source. We’ll post more about this when we do an official refresh of the extension.
Z-Ordering in Peer Components
We did a lot of work getting z-ordering in Android a while back and then dropped the ball on it by postponing the rest of the work to 3.7 at the last minute. For those of you who don’t remember peer components are native OS widgets like video, browser, native maps etc.
This change allows us to draw on top of them and place components on top of them so we can create pretty rich applications from subtitling a video to augmented reality apps would be (relatively) easy with such a change. Without this change you would need native code to do this…
It will also make apps that rely heavily on Native Maps far easier to write with far better results.
Z-ordering is a big change and just didn’t fit into the schedule, however we didn’t abandon this effort and Steve just committed a major overhaul of our peer handling in the simulator/desktop port which will allow z-ordering on those platforms.
iOS will probably be more challenging but we hope to do it sooner rather than later so we will have plenty of time to test before 3.7 lands.
We’re working on some big changes for the
Properties API. We added a new
MapProperty option which is effectively a property that functions as a
java.util.Map equivalent similar to the existing
ListProperty. We also added properties to represent primitive or numeric types e.g. instead of writing:
public final Property<Integer,MyObject> myNumber = new Property<>("myNumber");
We would now write:
public final IntProperty<MyObject> myNumber = new IntProperty<>("myNumber");
The main motivation for this is erasure. Parsing code that accesses
myNumber wouldn’t know the generic type since that is removed during compilation. However, we can know the type of
IntProperty & thus implicitly convert numeric types during parsing. This isn’t as “generic” but since
NumericProperty is a common base class for all number properties and derives from
Property we can write common code relatively easily.
NumericProperty also introduces support for non-nullable elements in this case which will fail if you try to set a null value and thus work better with auto-boxed values.