Chris Pim

The TBannerAd component creates a native control. Because of the way FireMonkey renders everything to a canvas, native components will always render on top of FireMonkey components. It’s a side-effect of the way it works. The way I got round this is to hide and show the banner component when in other screens (e.g. tabs of a page control or frames which display as screens depending on your UI architecture), so it doesn’t get it the way when I don’t want it to. I also suggest including a bottom padding to your multi view menus to push the contents above the banner. I hope this helps

That’s a shame but useful to know. Hopefully we won’t need any hacks!

I wondered the same thing but I guess as the NDA exclusion only mentions allowing Android updates from 10.4 beta not iOS, you’d still be better using 10.3.2 for iOS, Windows and Mac builds while they get 10.4 released if you’re already using 10.3 anyway. 10.3.1 is really buggy so if 10.3.2 is more stable then it may be worth upgrading.

Very true, yet I still have hope that EMB get a 10.4 beta out soon so we can have a proper solution rather than a risky hack!

Reassuring words from EMB about it already being underway. Summer is a long season so hopefully the 10.4 beta program will start sooner rather than later!

Has anyone heard any more about this yet? The dreaded 1st August deadline is 3 weeks away after which we won't be able to give our Android users app updates should we need to. If things are running according to the last roadmap at EMB, then they're behind and haven't even released 10.3.2 yet let alone the sorely needed 10.4 which is supposed to contain the Android 64 bit work. I'm getting very worried that we might not be able to support our Android users for 3 months while they get a 10.4 beta out. We have 220,000 of them and the thought of not being able to get even an emergency bug fix to them should we need to terrifies me! Surely EMB must be taking this deadline seriously?

It may seem so, but that’s not true - they just weren’t fixed before the release...

I have strange problem occurring when parsing a JSON string on iOS using the System.JSON library in Berlin. I call TJSONObject.ParseJSONValue() to get a value from the start of a JSON string which has worked fine if I run under Windows. As soon as I run under iOS, the same JSON string causes a null pointer exception. When debugging through, the null pointer is the TJSONObject class itself which is odd as ParseJSONValue() is a class function so don’t know why that would ever happen. I suspect this isn’t really the case and is just what the debugger is interpreting (the iOS debugger in Berlin isn’t great). I suspect the JSON string is too large for the parser as it’s a huge string. My question is whether anyone is aware of a size limit for parsing a JSON string or whether there’s a known issue in the Berlin JSON libraries which might cause this? Unfortunately I can’t provide a sample JSON string as it’s a client’s backup data but hopefully someone will be able to help.

It looks like the issue was due to a nil character at the end of the string I was parsing, rather than a string length issue. Thanks for your help Markus!