Dalija Prasnikar

You can file report at Quality Portal When you create new issue select "Documentation Bug" under "Issue Type"

If I had a dime for every time some "simple test code" ended in production... 😋

I am sure your users will appreciate reading default exception message they cannot comprehend. Of course, "There was an error" is not proper error message - but that is different discussion topic.

Yes, of course. The only time you don't want destructor to run is when you didn't write one and your record does not contain any managed fields that need finalization.

This can be a number of things including certificates. From my experience, the fastest way to fix this is creating empty application in Xcode with same bundle ID and run it with debugging on the device through Xcode. Xcode will automatically resolve all the issues. After that, restart PAServer and run your Delphi app.

Just released Mac Mini 2018 versions are all Intel based. No worries for now. But 2018 versions are far from cheap. 2014 are better choice for FMX.

Any 2014 Mac Mini will do. You can even use older ones, but they will be obsolete sooner. Since, Apple just updated Minis with brand new line, older models are having action sales https://www.amazon.com/Apple-1-4GHz-Silver-MGEM2LL-Version/dp/B00746X7G2

Maybe this can help https://stackoverflow.com/questions/41469082/open-gl-shader-with-2-textures

You are right... implicit variable hell There were some issues with scoping... so I went to check with simplest example... too simple I am afraid...

type TFoo = class(TInterfacedObject) public constructor Create; destructor Destroy; override; end; constructor TFoo.Create; begin inherited Create; Writeln('Foo Create'); end; destructor TFoo.Destroy; begin Writeln('Foo Destroy'); inherited; end; procedure Test; begin Writeln('procedure begin'); Writeln('before inner scope begin'); begin Writeln('after inner scope begin'); var ref: IInterface := TFoo.Create; Writeln('before inner scope end'); end; Writeln('after inner scope end'); Writeln('something'); Writeln('procedure end'); end; Results with following output procedure begin before inner scope begin after inner scope begin Foo Create before inner scope end Foo Destroy after inner scope end something procedure end

procedure Test; begin Writeln('Test started'); begin var obj := Shared.Make(TTestObj.Create)(); Writeln('obj = ', obj.ClassName); end; Writeln('End of nested scope'); Writeln('Test completed'); end; Test with above code, please. I am testing with plain TInterfacedObject and it works as expected...

You are wrong... object is destroyed at the end of the inner scope... but your output 'End of nested scope' is still executed within inner scope.

Because, in its infinite wisdom, IDE decided you need to brush up your debugging skills 😎

If anyone is interested to know current API distribution Google maintains Distribution dashboard (updated weekly) at https://developer.android.com/about/dashboards/

Documentation is wrong. Actually, it is not... long story... Default value in Rio manifest is 19, but minimal supported version as in "tested with" is 21. This is form of API level deprecation on Embarcadero side. Applications should run on API 19 (and lower, you have to manually edit manifest to support those), but if there are issues (and those issues are caused by API level lower than 21) Embarcadero can decide not to fix those issues.

There are two API levels in manifest (actually, there is another one, but not important) - minSdkVersion and targetSdkVesrion minSdkVersion marks minimum API required by application and it will not run on Android devices with API lower than specified targetSdkVersion marks highest supported API level by application - that means Android will not use any compatibility mode when running on devices with specified or lower API. If you run application on device with higher API level, OS will use compatibility mode for newly introduced API features. Tokyo 10.2.3 (and previous versions) by default had both API levels set to 14. Rio 10.3 changed that and minimum API level is now 19 and target is 26. That means devices with Android version lover that 19 will no longer be able to run applications built with Rio. Conclusion: Delphi application compiled with Rio can by default run on any device with API 19 or higher.

AFAIK, everything in Android is directly configurable. Android tools don't need to support Java 9, but they should work if Java 9 is installed along side with Java 8

Could you please report your issue with Java 9 to Quality Portal. Having different Java versions should not be an issue.

Please fix IDE bugs! We have new icons Please fix IDE bugs! There is barely working dark theme Please fix IDE bugs!!! Now light IDE theme is broken too. I don't mind UI improvements, but IMO this were the wrong ones. I should probably say - I would not have anything against visual UI changes as long as they work properly. Visual changes are (should be) easier to implement than fixing some deeper IDE issues. But, currently IDE is falling apart left and right. Just because it looks better (depending on how you define better - my eyes cannot stand bluish theme for more than 10 minutes) it does not mean that it works better or is more usable.

For me Tokyo works fine with JDK 1.8_60, but I don't have Java 9 installed, so I don't know whether this could be the problem or not.

Sorry. There was some other thing but I don't remember exactly. One thing that also does sound strange in your config is that you have selected platform-28 and it says Android SDK 25..x.x

Change the JDK paths back to 1.8 in Delphi Android SDK settings under Java tab. (Last screenshot)

This is due to inner TList structural changes. FItems were moved from TList<T> into ListHelper class and its type has been changed into a pointer. AFAIK this issue (limited debugging) has been reported, but report is not yet publicly available

As far as Beta bug reporting is concerned there are few things to know. 1. Not all bugs reported during Beta test are resolved during Beta test period. 2. Beta test bugs are tracked separately from main RSP tracker. 3. Beta test bugs that are still not resolved are moved to main RSP tracker project. 4. Moving issues to public tracker requires some administrative work - it is not just simple move all procedure - and it takes some time. At this moment unresolved Rio beta test issues are still not publicly available.

Delphi in VM and Android debugging don't work well together. Actually, I never managed to debug Android from VM. If not in VM debugging on Android works fine, most of the time.