Rollo62

No, its not worse. Its just stabilizing on a floating level

Its hard to say, usually I would propose to update to 10.4. Because you work on Android, and this fixes the required API-Level 29 stuff, if you only want to work on older API Level 26 (which cannot get into PlayStore probably), then Rx10.3.3 should be fine. But in general the latest version is always best, when it comes to mobile. If its only the \bin\KeyTool.exe. issue, maybe first you try to fix that, sounds doable, or re-install the Rx10.3.2 incl. all Android SDK.

Ok, all the files seems to be younger (around 22.07.20) than the last patch (around 15.07.20), only this one ir older bin/Windows/lldb/embt_formatters.py Thats the log: bin64/vcl270.bpl bin/bccaarm.exe bin/bcciosarm.exe bin/bcciosarm64.exe bin/compclang33.dll bin/gdbdebugcore270.bpl bin/vcl270.bpl bin/vcl270.jdbg bin/win64debugide270.bpl bin/Windows/lldb/embt_formatters.py bin/Windows/lldb/liblldb.dll bin/Windows/lldb/lldb-mi.exe lib/android/debug/librtlhelper.a lib/android/release/librtlhelper.a lib/win32/debug/de/vcl.lib lib/win32/debug/fr/vcl.lib lib/win32/debug/ja/vcl.lib lib/win32/debug/Vcl.Grids.dcu lib/win32/debug/vcl.lib lib/win32/release/de/vcl.lib lib/win32/release/fr/vcl.lib lib/win32/release/ja/vcl.lib lib/win32/release/Vcl.Grids.dcu lib/win32/release/vcl.lib lib/win64/debug/de/vcl.a lib/win64/debug/fr/vcl.a lib/win64/debug/ja/vcl.a lib/win64/debug/vcl.a lib/win64/debug/Vcl.Grids.dcu lib/win64/release/de/vcl.a lib/win64/release/fr/vcl.a lib/win64/release/ja/vcl.a lib/win64/release/vcl.a lib/win64/release/Vcl.Grids.dcu source/vcl/Vcl.Grids.pas

What shall I say, the 5th attempt via GetIt works finally. Again I've lost nearly 1h with all that sh.... Please don't do that all the time to me, Embarcadero. Its so much annoying, you won't believe it.

You probably have installed a wrong JDK version, or updated that, in Rx10.3.3 it should be jdk1.8.0_60 . Maybe you can switch Rx10.3.3 already to the new AdoptOpenJDK, but I'm not sure if that only works from Rx10.4 on. But usually it should be possible, if you adjust all the JDK paths in the SDK Manager of the IDE.

The backup files are there, in a separate folder, and also the file dates were changed as described in Marco Cantu's Blog. Only verifying the file dates has to be so ne manual, which is a little unprofessional .

The programmers ethics ... you can find here

Right, I also use NaN a lot, to make sure that float numbers are not valid.

Then you better catch exceptions and log them in a "invalid data" file or DB. To allow to find them manual rework them later, that would prevent that you are loosing any important information.

I would think that especially with external data, you can never be 100% sure that all works fine. You made a contract to the data known at that certain time, but you cannot predict the future. Maybe your customer changes the contract without noticing you. I think also that the programmer should handle that as careful as possible, but in reality you will always see unexpected data and behaviour. UnitTests might help a lot, also to identify known "wrong data", but who can predict the unkown ? In some cases the system can handle the unexpected gracefully, in some systems you will find hard crashs. To throw an exception in these cases at least may help to prevent further damage. To cover everything in try - finally, and to ignore exceptions is maybe not the best choice to ensure a good data quality. That way nobody gets aware of such (hopefully rare) cases.

Right, GIT works serverless as well. It can be used in very many ways. Moreover to all whats said before: GIT can be integrated with the Delphi IDE (but I don't use that at the moment, but wanted to try out).

But better use GIT then, this also runs standalone just copying 1:1 on a network folder. Same Features, same EXE, makes it easy to scale up .

Yes, they have a PatchTool included, which could verify its own work. Why are so obvious features always missing, to find the failure in the picture by ourself ?

I reworked my projects back to 10.3.3 (API-26) again, so they all went fine there. Today I was looking if an update of API-29 might exist, which helps to fix this issue. Unfortunately it seems that SDK Platform 29 Rev.4 is the most current one, which is already installed. In the Android site I cannot see anything newer than this, only when moving to some beta (which I don't want). I checked also the behaviour with the new Patch 2, which makes no difference (as expected), the issue seems to be related to the API-29 really. Without an newer SDK Platform version available, I'm afraid that I cannot fix this by simple SDK update. So I have to dig a little deeper. Android seems to have changed location and permission heavily in API-29.

I just try out the Patch 2: From the description: This let me consider if one or a few files are good enough to check, or do I better have to check all replaced files. Isn't it if one file is replaced then all of them shall be OK ? If any double on this, e.g. by hanging files in a crashed IDE, then better re-boot the PC before Patch-2, and avoid starting the IDE before the patch. Has anybody find issues with not correctly replaced files ? Edit: For example after the Patch 2 "Lib\Android\xxxx\librtlhelper.a" seems to have changed timestamp from May to June, but is identical file. Is that good or bad And all the Include files seems replaced, but identical files left is old, right is replaced b< Patch 2

What about CDATA Enterprise Connectors, its not for free either ?

Sorry Mahdi Safsafi, I think this is same issue as above. This very same text line is from 1995 too, please update that as well to a more modern version.

Oh man, this is still the very same text from 1995. Embarcadero has to update that, please file a QP report.

@Dave Nottage Right, but meanwhile I think the culprit is Android-29 API (Rx10.4), while Android-26 API (Rx10.3.3) works still fine. That would be no big issue, if not Android would reject the old API-26 in 15 days. In the last test I put projects, for Rx10.4 and Rx10.3.3 to test, just see the behaviour of 10.4 when requesting ALWAYS. Maybe its only an issue with my test phone here (Samsung S9 Plus), but I have similar feedbacks from other customers too recently. I will try to switch back to Rx10.3.3 now, to prepare a last API-26 update before August, so that I have more time to find a workaround.

Yes well. But isn't it more close to that ? https://www.youtube.com/watch?v=JQ8jGqdE2iw

@Günther Schoch Well, I love risky business. <OT>dreaming> I hope that will pay off one day </OT>

I see that from two sides. VCL-Side Is quite mature, bugfixes and new features OK, but who REALLY needs that ? No time pressure, low investment is maybe argueable. FMX-Side: Is under high pressure from more and more platforms (including Windows-10). Much more buggy than VCL, less mature, needs a lot of care in the future. Always time pressure, by Android/iOS time schedules, high investment is needed to cover all that. From the VCL-Side I feel quite relaxed, here and there a new language feature will do the job. Nothing is really missing here for my daily work. From the FMX-Side I can spot a massive under-investment. I regularily check the changes and additions to the feature API or mobile platforms. No or very little investment i to new API's and API changes there, only when its absolutely necessay. Why don't we have full API support for the platforms already, or at least 80% ? Why not simply put a task-force to translate all platforms API into Delphi, where mostly this would be routine work for mobile experts ? For example, why is not yet the cool AR/VR added, why did sensor-date had (maybe still have), why is camera still so slow, why not yet full Maps support, why not included full SSL-solution, ... ? Ok, there are solutions like TMSMaps, but why should I use them when Maps already were in the package. Thats what I always also have seen in VCL very sadly, why are many basic components so poorly and minimal designed, not meeting a minimum requirement in real world, just good for demo purposes. I want to use a Delphi FMX-Function, and want forget about the issues and problems behind. Embarcadero should flatten our way, and fix Location, Sensors, Permissions, etc. etc., so that the developers can use and rely on any function. Still there is too much special-knowledge needed, to get a many things running. I'm a lazy developer, want to use API's that do what they promise, don't need to know all details behind. The FMX-Side would be the right place to turn Embarcadero's future, if they could profile themself well as all platforms solution. In marketing yes they do already, but in realiity many of the promises were missing, and I can see not much work on this. A good indicator are also the demos and samples, which were revolutionary at those days, but getting lame and non-functional nowadays. Why is no ony improving, cleanup these features and add new demos permanently, because this is the main entrance for new customers too. I hope everybody understands, that when newbies checking an IDE where 50% of interesting demos don't work, they immediately take a step back and look elsewhere ( at least I do that with new technologies ). If everything works as expected, and without a lot of fumbling around, then the newbies will be catched more easy. These are only a few points where I would like to see a lot more investment. Still I hope for the time factor, so that it might get better in the near future, but for me an IDE which can support platforms out-of-the box should have a good weight in the market. For me mobile, cloud is clearly the future, combining with front- and backend desktop this is a killer feature. There are other nice boys in town, but they all have their pros- and cons as well, and IMHO RadStudio does not so bad in comparison. For the goal to achieve less "investment" gaps, I would like to see a much faster system of updates, patches and hotfixes, to keep us developers up running with high and accelerated pace against all other solutions.

This seems to be a longer story, so I checked the same under Rx10.3.3: works fine, under Rx10.3.3 has above issues. My android configurations (should be IDE pre-installed both for 10.4 and 10.3.3) So I will check possible Android updates now, with the hope that newer API versions has fixes this. Not sure if an API update solves or make it worse, so I'm afraid I have to check carefully, but I can only check tomorrow. You can find the next Test_007 enclosed, with separate projects for 10.3.3 and 10.4, which were newly creted projects. Update: I'm afraid no Update is here really available, but I will check more deeply tomorrow. At least I cannot see any updates related to API 29 when searching here, maybe I pressed the wrong buttons .... T356_AndBleTest_007.zip

I did some more tests, see enclosed. Test5 = with ALLOW_BACKGROUND_PERMISSION in Manifest Test6 = without ALLOW_BACKGROUND_PERMISSION in Manifest Doesn't make any difference, I always need to change permission extenally ONE time back-and-forth, before I get results from Bluetooth scan. Strange. T356_AndBleTest_5_6.zip

Ok then, maybe this overview is a little misleading, I thought its true for all the components and protocols inside.