Rollo62

Don't mess with youself too much, if Microsoft shows not any attempt to make these controls practically more usable since the last 20+ years, why should we do ? I must really say that meanwhile I hate to fix all the quirks in OS, IDE, tools, libraries, etc. Enough to do with my own, selfmade errors

I just tried to add ALLOW_BACKGROUND_PERMISSION, which shows ALWAYS as option, as it should. But still I need externally to change the Android options ONCE, only then access is granted. I think I should forget that for a while, I hope my customers will understand that this is an Android issue. Would be great if this is somewhere documented, so that I can proove this behaviour to angry customers. I think 'm getting too old for this shit, the last months I was only catching several issues in various systems. Not that I could really work on my own projects, as I should, but wasting my time finding workarounds for things that should be running. T356_AndBleTest_4Step.zip

Since I suspected that Android needs some more time, I also checked a 3-step process. Where I need 3x press the button 1. location, 2. bluetooth, 3. discover, to avoid too fast calling the API. What I can tell is that it makes no difference. T356_AndBleTest_3Step.zip

@Dave Nottage Curious me has tested the 2-step process too, first ask for LOCATION, and then ask for BLUETOOTH permission. But no luck, still need to change in Android system to ALWAYS, see enclosed project. Seems I have to blame Android for this, or is there any workaround ? I hope that DelphiMT has a good explanation. T356_AndBleTest_2Step.zip

@Dave Nottage Here is a stripped down sample, with its foto story ... Hope you can spot an issue here. When pressing first time, it enables BLE Pressing 2nd time asks for permission, as it should ... Of course I give permission "WHEN IN USE", Then its discovering, but NOTHING found (I can retry as often as I want) Its NOT a permission problem, Android shows while app is running that "WHEN IN USE" is fine If I change this to "ALWAYS" Then the app is still running (no restart), and I can discover now perfectly Can you spot an issue, I'm afraid this could be an Android issue ? I re-order the requests, as @DelphiMT propose, already in this sample. What I didn't checked is to ask for permission in two steps, probably that helps: 1. Ask for Location 2. Ask for Bluetooth Is that they way how it should work (but it was workong fine before) ? T356_AndBleTest.zip

Yes, its saying like that in the specs, but I only get foreground access when additionally the background permission was given. That would explain the need to permit twice, since "WHEN IN USE" seems to be completely ignored, at least in my Samsung S9 Plus. @DelphiMT Thanks, looking forward to your explanatons regarding to this. Probably these Android quirks has something to do with adding the Covid-19 API in a hurry, which requires always background ?

I have made some more tests, with a pure Bluetooth DiscoverDevices search. It seems that Android requires always the ALLOW_BACKGROUND_LOCATION at Android 10 now, although I understand the documentation differently. https://developer.android.com/about/versions/10/privacy/changes The table should say that normal foreground only operation should be possible Now it isn't discovering any longer, I need to have ALLOW_BACKGROUND_LOCATION defined. While it didn't accept the forground immediately, even if background is set. In a minimal sample the manifest looks like this <?xml version="1.0" encoding="utf-8"?> <!-- BEGIN_INCLUDE(manifest) --> <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.embarcadero.T355_bleAdvData" android:versionCode="1" android:versionName="1.0.0" android:installLocation="auto"> <uses-sdk android:minSdkVersion="23" android:targetSdkVersion="29" /> <uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" /> <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" /> <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" /> <uses-permission android:name="android.permission.BLUETOOTH" /> <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" /> <uses-permission android:name="android.permission.CAMERA" /> <uses-permission android:name="android.permission.INTERNET" /> <uses-feature android:glEsVersion="0x00020000" android:required="True"/> <application android:persistent="False" android:restoreAnyVersion="False" android:label="T355_bleAdvData" android:debuggable="True" android:largeHeap="False" android:icon="@drawable/ic_launcher" android:theme="@style/AppTheme" android:hardwareAccelerated="true" android:resizeableActivity="false" android:requestLegacyExternalStorage="true"> <!-- Our activity is a subclass of the built-in NativeActivity framework class. This will take care of integrating with our NDK code. --> <activity android:name="com.embarcadero.firemonkey.FMXNativeActivity" android:label="T355_bleAdvData" android:configChanges="orientation|keyboard|keyboardHidden|screenSize" android:launchMode="singleTask"> <!-- Tell NativeActivity the name of our .so --> <meta-data android:name="android.app.lib_name" android:value="T355_bleAdvData" /> <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </activity> <receiver android:name="com.embarcadero.rtl.notifications.NotificationAlarm" /> </application> </manifest> <!-- END_INCLUDE(manifest) --> How to set up correctly foreground and background Bluetooth operation now, is this an Android bug, or am I missing something ?

Are looking after FMX ? You can use the Edit custom style, to prepare a customized version Or you can use OnApplyStyleLookup, where you can grab the single elements from above, e.g. by usng FindStyleResource('text') ... When you looking for VCL, probably you have to create you own custom component, or you simply use ' ' space, to get more distance tho the checkbox.

That shows the core differences in the different languages: C++ = pointer love Delphi = pointer hate But why: pointers are always, and will be always out there, till the end of days (at least when it comes to the bare metal).

Yes I was also missing that too, and even would like to customize the keyboard. Seems that this ends up in a lot of fumble jumble. https://medium.com/@ssaurel/learn-to-create-a-system-keyboard-on-android-95aca21b1e5f https://medium.com/@ssaurel/creating-an-in-app-keyboard-for-your-android-apps-a0a6c6e1e289 Not even checked for the iOS side. I hope that Embarcadero will work their fingers to the bone one day

Would choose FreeNullminator, ... hasta la vista .... Object

Depends maybe in what industry you are, as a Kiosk system this is probably OK (but far too expensive from my point of view). In real industrial control systems you are right, its not accepted at all, neither is the RasPi. But at least there were some RasPi more "ruggadized" in the market, which could be used for that. In regards of safety I think none of the above will be really acceptable nowadays, I had done industrial controls in the past also by PC technology, but this won't get through a normal risk-analysis anymore. Especially the larger the machines get you want to control.

@aehimself Right, and regarding consideration for an app like NAS, Smarthome, IoT broker/server or many others. There are so many perfect ARM based, Linux based solutions out there, that Delphi never could catch up IMHO. Take a simple, basic Synology NAS, which comes with all apps from NAS, PHP to Node.js even on the smallest footprint. I'm so sorry to say, but this Tiny PC's are not Delphi's strengths at all, so I would not consider them for anything which is not veeery special. Maybe this can change with the Linux option one day, but surely we will never see such many perfect, rich apps like in the PHP and Node.js world.

I like tiny computers too, but I would check for a NUC-sized to Mini-PC sized PC, with reasonable performance. If I ever need a tiny computer like that, its probably something like a RasPi. All these TinyPC I have seen so far were too expensive and not well supported.

I have seen the "exclude users" warning only from Android, are you sure this is in iOS too ? Would be interesting to see this warning on iOS exactly. With Android you simple confirm: yes, I have to exclude some ancient users (those from ancient Android 4,5,6,..).

@Sherlock Thanks for pointing to this. I noticed first time that the ZeroMQ should be in, but in my GetIt I cannot find this. If ZeroMQ is hidden somewhere, can this be used for C++ only (what I assume) ? Maybe someone has experience with ZeroMQ under Delphi already, and where can I find ZeroMQ in GetIt ? I know the Grijjy implementation, but seems not to be supported for Rx10.4 yet.

I think that Apple is just phasing out 32-Bit, there is no more need to support 32-Bit any longer. All old phone owners should order a new one (Apples view). If you want to update 32-Bit versions for older OS, maybe you can keep one Rx10.3.3 in a virtual machine, as long as this might work, to be able to upload such apps. Never tried, but maybe a pure 32-Bit IPA for older OS can be still uploaded via transporter somehow, but I doubt it. Here could be some insights, howto try this via command line tool. If still possible, you could have two VM, one for 32-Bit Apps, one for 64-Bit Apps. Maybe to support 32-Bit is pointless, as you could find here.

Didn't that re-install Dave and I described above worked out for you ? Maybe its better re-start IDE too. That solved the case for me, linker error was gone.

@Dave Nottage Thanks, that was a little unclear howto make such updates. So this seems to un-install and re-install the TeeChart. The linker error was gone afterwards, I could'nt check TeeChart versions before/after, but it looks as if the latest version was downloaded. I was forced to do that by the Patch Tool.

I had the same when testing my projects with 10.4. But it turned out that I forgot to clean and build a designtime package, which used an already changed unit. Since I don't use too many designtime packages, this was easy overseen, and I wish there could be some reliable "out-of-date" warning. Sometimes the llnker makes a warning, sometimes not. So far I seldom see such mis-aligned breakpoints, and usually cleaning up all DCU's help to fix it. I also recomment, like Dave, to install into a new VM. Since I did this, some years ago, I seldom have such weird failures I can see here in the blog. I think worst idea is to install two versions side by siide, there are simply too many positions where things may go wrong. Usually I have two different VM (VM10.3.3; VM10.4), which I can use even in parallel if I ever need that.

Is that helpful somehow ? Not sure if this is still actual. Or the commercial TMS CLoud Pack. But I would always check if this is still currently working, the cloud APIs change too frequently.

Exactly, to find something is not very reliable or convenient, with Rx10.4 LSP this is getting somewhat better in the right direction, but not perfect. Maybe Uwes MMX-Tool fills that gap, but I'm still learning howto use it at best. Still I'll do a lot of intensive "search and replace" with external tools, which gave me much better feeling of reliability.

I've just run the patch, here a list of whats going on: Before install I had TChart and all Features I installed via welcome page this seems to be just a shortcut to the GeitManager Got the first message Yes, I want ... Then I've got a fullscreen terminal, which is odd. because I cannot see a hanging message-box request, it was behind the terminal. After pressing OK, it moved on Seems to de-install all features I've had installed before even Interbase and all SDK's ... Then its restarting the IDE Of course something is missing now, need attention later ... Then the features components 2nd page were all removed (as they were uninstalled), I had to enable them. Even the samples. Installing the components ... tea time ... Re-Installing also loads the TeeChart, I hope this is the new version then. I will see later in my tests. Finally after install Teechart is back I can compile Android, so also the SDK seems to be back, but I'm unsure if all Android-Components wer initialized. The welcome page still shows a patch, it seems to be an error in "patch installed" detection I re-enabled my TChart usage in a project, and compile the project for test. I found a few issues then: 1. The message box was hiding behind the full-screen terminal 2. All features were disabled and de-installed, even the samples. This is maybe for safety, but I think this could be optimized. 3. When IDE ist startin, to re-install, it noted about missing BPL Surely this could be optimized too, to set the IDE into a kind "installer mode" before, ignoring missing BPL. Then only show message after 2nd start, if still anything is missing. 4. Patch "installed" detection doesn't work reliably

So howto get TeeChart back ? Did I understand right that this works with Manage platforms, and uncheck/check the TeeChart checkbox, to uninstall/reinstall TeeChart ? My point is that I don't want to re-install the whole IDE at the moment, since I'm fighting to get things stable again. I've deactivated the TChart in my app for testing purposes.

Thanks Uwe. I also will follow the good advice to backup the system, especially because the name of the "patch" doesn't sound too reliable to me.