Dalija Prasnikar

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.

Automatic invocation is the whole point of managed records. If they have constructors and destructors, you want them to run. Yes, you can do that manually, but then they would not be called managed records. If you don't want managed records, and you want to perform some initialization and finalization code manually, you can use plain record procedures. You don't need constructors and destructors in that case.

One of the problems with ARC enabled and having [unsafe] as default is that you cannot release object that has disabled reference counting. [unsafe] is only for marking additional references on objects whose memory is managed at some different place (reference). Of course, you can say that compiler would need some tweaking to allow destroying such objects, but it is very likely that at some point the whole construct would fall apart. I never gave mush thought to such "solution" because it seems pointless. Point is. ARC compiler was done right as far as its default behavior is concerned. There are few things around DisposeOf that could be polished, and some other minor bugs that are just bugs, not design flaws. ARC compiler fits the best into existing Delphi infrastructure and neatly fixes issues around object and interface references. Other solutions and workarounds will be poor substitutes and will not solve that duality problem. I wish I would be wrong on this one. I sincerely hope I am wrong and that there is another approach that will not be just a band aid, but full fledged solution.

But with normal var declarations you are forced to explicitly write the type for the variable. In this case, you can easily forget that you have to explicitly declare variable as interface and rely on type inference which will get it "wrong".

This is truly great and long missed feature. Truly great. But... I hate buts... there are things to watch out. Namely, type inference breaks reference counting. It is one of those don't mix objects and interfaces pitfalls. Should I say that this works perfectly on ARC compiler 🙂 If you have reference counted class, you cannot rely on type inference, you have to specify the interface type. // broken var Instance := TInterfacedObject.Create; // not broken var Instance: IInterface := TInterfacedObject.Create;

@Marco Cantu No matter how you turn it something is not quite right. I can certainly see why you made the choice you made. Both now, and back then when ARC was introduced. I hope that for the sake of present we (saying we because non-ARC is clearly what your customers want) didn't sacrifice the future.

@Sherlock If you get warnings, then this is kind of code that needs to be changed for ARC. But the change you do (depending on the actual code you need to change) will work across all compilers without warnings.

Just for the record, unless you have to change methods signatures - adding const param, and for some reason you need to keep old signature too, porting to ARC compiler itself does not require any IFDEFS. All needed changes are compatible with all compilers.

I found the report for Linux compiler that may have some impact on speed comparing to Windows (regardless of ARC) Linux x64 compiler produce very bloated code

1. Totally understandable. You cannot use ARC to its full potential and you are only paying the price. 2. I assume it was Linux vs Windows, It would be interesting to see how it compares with ARC removed. Comparing x86 with ARM is comparing apples with oranges - ARC or no ARC. AFAIK, LLVM backend has some influence on performance, too. There are some reports about inefficient code generation - something not ARC related. Performance mostly suffers because of existing code that is not written for ARC - unnecessary reference counting triggers are real performance killers. It is not fault of ARC per-se. 3. LOL - it is the same memory management model, (if you remove DisposeOf out of the picture) so pitfalls are exactly the same. Developing for ARC requires a bit different mindset.

I think most of EMBT customers will see that as a positive move. While I fully understand them, I am not so sure. More thoughts... ARC is dead, long live ARC