Dalija Prasnikar

Is Delphi Rio broken? NO.... Why does my Android application, compiled with Delphi Rio, no longer work?

Define usable. Yes, I am aware that different people will have different needs and not all bugs affect all people. And while there is a number of bugs that are still not resolved, I haven't encountered any really showstopper Android issues with Tokyo or Rio, regardless of the update number. What might be greater problem in this case is general direction of removing ARC http://blog.marcocantu.com/blog/2018-october-Delphi-ARC-directions.html that would most likely happen in 10.4 release (as hinted in a linked blog post). If that happens that would be major change that could introduce bugs in both Delphi frameworks and your application code. While in the most part cross-platform code is also meant to run on non-ARC platforms, there are parts of the code specific for Android and/or iOS platforms where people were counting and using ARC. In any case, I assume that there will be open beta for 10.4 version, just like there was for 10.3, and that developers on active subscription will be able to participate and ship applications with that beta if needed. I know this is far from ideal scenario, but it is better that nothing.

No, they will not have less strict treatment. Google knows exactly how many applications are affected by this (they can easily analyze applications submitted to the Play Store), and with the exception of older Unity games, obviously there is not too many. Also, vast majority of Android applications don't have to worry about CPU support because they don't use (link) CPU specific code (libraries) and are written by toolsets that emit Android Dalvik byte code.

AFAIK you have to use your username instead of email, unless your email is also your username.

Dummy apps will not help in this case. Updates also have 64 bit requirement. At this point in time it is hard to say what is the right strategy, beyond making sure that you finish and polish your apps as much you can before the deadline. 10.4 is scheduled for mid 2019 so all should be good, but you never know.

@Rollo62 @Kryvich {$RTTI} directive has local scope. That means you cannot set it for whole project and have it applied on everything. If you want to remove advanced RTTI from RTL/VCL, you have to recompile RTL/VCL, which is what OP wants. As far as recompiling Rio RTL/VCL is concerned, I haven't tried to do it... so I don't know what are the problems and even less what would be solution.

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.