Dalija Prasnikar

40 minutes ago, John Kouraklis said:

i will try to load the symbols but I am annoyed...don't get why I need to debug the IDE...

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/

2 minutes ago, Cristian Peța said:

@Dalija Prasnikar in the "Platform Status" says that it's Android 5 (API 21)

http://docwiki.embarcadero.com/PlatformStatus/en/Main_Page

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.

11 hours ago, Dave Nottage said:

It will be an issue if the Android tools don't support it, and nothing EMBT can do anything about.

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.

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.

1 hour ago, Markus Kinzler said:

@Rudy Velthuis I think you misunderstood me. My concern are only about the automatic invocation.

 

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.

3 hours ago, Cristian Peța said:

I don't understand what would be wrong to enable ARC for objects and to consider [unsafe] as default. It will not brake old code. And using [safe] or [arc] we can have automatic memory management. At least for simple scenarios.

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.

1 hour ago, Johan Bontes said:

This was already the case with normal var declarations. Obviously if you want the var to be a different type than the R-value then you'll have to declare that type.

 

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.

52 minutes ago, Richard_Stevens said:

Thumbs up from me. We have a couple of VCL products that make heavy use of relatively complex, object-based libraries that we debated moving onto mobile - but were put off by the rats nest of potential issues and number of IFDEFS it would have needed. If in 12-18 months' time we can re-use those libraries more or less "as is" then that will be great.

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

2 hours ago, Lars Fosdal said:

I welcomed ARC in principle, but there were three key problems for me:
1. Having two different memory management models in our code base was not an option
2. ARC carried an unexpectedly high performance penalty 
3. The pitfalls of ARC were as many and as complex as for the classic reference count problems.

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.

4 hours ago, Marco Cantu said:

Honestly interested in feedback, suggestions and ideas. Less in "I told you" comments... 

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