Rollo62

Could the "features files" have something to do with it ? https://en.delphipraxis.net/topic/1351-fmx-macos-missing-image-sqlite3-when-running-on-macos-sierra/?do=findComment&comment=11335 The answer was for Macos setting, but as fas as I understand will the featured files adding necessary librarties to all platforms when needed. The hint that Sqlite "featured files" option is needed is still not present at Docwiki, but you can fint the option in the deployment manager.

I have no FireDAC.inc on hand right now, what did you change there ? Is there a link to libibtogo, or is it possible that you have added libibtogo. to the deployment somehow ?

Not sure what exactly you are looking for, but wouldn't it be an option to register a custom, "secret" clipboard format, maybe with encrypted data ? https://blog.dummzeuch.de/2018/12/18/register-an-use-a-custom-clipboard-format-in-delphi/

Anything useful for you here ?

Hi there, I took some time to check with 32/64-Bit on older devices, and found that Bluetooth was not running on my old Nexus 7. The Nexus 7 (on Android 6.0.1) is a real 32-Bit device, so I searched into the wrong direction. The real reason was that Location was not enabled (while location permission was granted, as it should). I didn't find much useful answer, only this note. The rule seems to be: you have to set at least coarse location permission on Android 6.0.1 (32-Bit) you have to enable location sensor additionally How about behaviour in other versions < or > Android 6.0.1 ? This is a little disturbing fact to me, since I always considered that Bluetooth need the coarse Location permission only because of BLE is able to retrieve its own location info in its own network, like Beacon technology (my personal assumption). Now it seems that really physically location sensor must be running in the Phone/Tablet too (why). Usually I have this active anyway in my test devices, so I never been falling into such trap before, so I learned something new today. I wonder if this is caused by the old Android 6.0.1 only, which had many BLE issues, or if this is a general requirement in any OS version ? Maybe there is some deeper documentation what explains this odd behaviour.

Thanks Dave, that looks like the "explanation". Very good to know this note from Android. Makes not much sense to me either, so we have to believe that this is an important step in security. Unfortunately I cannot explain such info to my customers, so I stick to my own version: that BLE might span up its own "location" network via Beacons. At least my customers could follow and understand such explanation as reason for location permission.

Yes, but location "permisson" is different to location "permission + location really enabled". When the user starts with location permission, and then switch off after location, BLE will stop. There are several ways to retrieve location: via GPS sensor, via WiFi triangulation, via Bluetooth Beacon, etc. So why should Bluetooth require GPS sensor ? I must check my permission system, maybe I requested coarse AND fine location, I will check if thast makes the difference. Probably I mixed up some configurations from different projects.

Yes, permission is required, that is clear. But it seems that additionally location in the phone (GPS sensor) must be also enabled to use Bluetooth, thats my point. I just checked with more modern Phones. Yes, Location needs permission AND location needs to be enabled in the Galaxy S9+ phone (Android 9). Thats strange, because I remember that it was not always needed to enable location, to use Bluetooth, anyway I'm not 100% sure about that. So I have to check with different phones how things behave.

Do you have sources of 3rd party, to find out if there is an endless loop somewhere. I would always try to find that root cause first, before trying to kill running threads. To kill a thread is also not a good idea IMHO.

Probably this is true for simple apps, but howto compare more complex apps. Do you have a good source for larger examples, which includes all possible aspects, like DB, networking, styling, using native sensors, location, etc. ? I often find even native programmers struggling with these (same) stuff in XCode and Android Studio, as we do in FMX.

You may need to give Android a little time after setting one command, before it will be able to give back a result. Also you should always ensure to touch such commands and results into the UI thread, as these responses came from extenral devices, and may drop in at any (asynchronous) time. The whole Bluetooth system is quite tricky, and has various smaller or larger pitfalls on different platforms.

#meetoo

TLDR; Thats probably a little outdated. I meant the official docwiki, which is showing all necessary steps. http://docwiki.embarcadero.com/RADStudio/Rio/en/IOS_Mobile_Application_Development Edit: Especially interesting for the mobile development is the platform status, regarding OS versions and simulators http://docwiki.embarcadero.com/PlatformStatus/en/Main_Page

You need a Mac or MacInCLoud, as said above, as well as an Apple developer account, etc. See the descriptions in the DocWiki, this is very good to start with. Because XCode needs to compile and sign the package, there is no other way (or maybe by Hackintosh, but I would not trust that this is reliable).

@Sherlock You typed a ms faster @limelect There should be also an option to get used phones for testing, at quite reasonable prices. iPhone 6S is a good one, still quite current.

Depends what you want to do, I would recommend to have at least >= iOS11, don't know what phone that is right now (maybe iPhone 5).

I would recommend to use a real device as well, because the simulators are normally much different, especially if you go deeper into the mobile functionality. Even if the latest simulators would be supported by Delphi. You shouldn't be too much suprised if your app is running well in a simulator but might crash in the real world. Maybe the simulator is still OK if you only do some very basic and standard controls and nothing else.

Have you checked Spring4D ?

Have you considered to call several EXE files in the umbrella app ? They seem not be related much yet, so that could be a way to be faster.

Wow, Ok you have a bigger task to do then. I am lucky not to need to keep on old Delphi, I try always move further to the latest Rx version. Anyway, your project sounds like a task for big GIT scenario with clever CI. Good luck.

Hi there, since Apple forces all apps to supports IPadOS13, and I know what issues iOS13 already has caused, I would like to know what other desasters might come soon. From this list, maybe some major changes are listed, maybe there are already experiences from using certain API's ? Generally I hope that the basic API's are more or less untouched, and that not too many side-requirements are needed, but as far as I know will Apple stop uploads for apps not supporting iPadOS13 from 04/2020 on. Are there already good or bad news on the horizon ?

I was hesitating much before I started using them, because of issues in the past. Now they work fine for me in FMX (I don't use them much in VCL still). But I use them to separate UI, and I still avoid to make frames "component-like", to introduce them in the components toolbar. IMHO this cause all the main problems I have seen in VCL, so no "drag-n-drop", but well defined creatin in Code, like you said. Then I got no problems at all. I also have a second set where I used TForms instead TFrames, but since TForms are more heavy I prefer to use TFrames now. Only TForms may have other advantages, like Styling support, but also the TFrames can do that, as long as the main form has this defined. So its very open, I think you can use what you like, even Andrea Magni's great TFrameStand contains now a TFormStand component.

Maybe sometimes I avoid copy-and-paste. Just checking the form and dfm/fmx code, and manually change from TForm to TFrame is more reliable. Of coarse you need some more settings then after, but with copy-and-paste you loose a lot of relations in the code. But if you like to keep TForm instead of TFrame, you could also keep that, and load a Form in the MainForm. The advantage is mainly to be able to check and reset project settings fastly, while the forms/frames act only as separate views. That is more and more imporant, since so many changes occurs in platforms and in every new release, so its better to start new release on a fresh .dproj base. The separation helps (at least me) to more simply de-couple and test the views separately, as well as to re-use them in other projects. Nowadays I even start simple tests in same way, so that I'M able, after successful test, just to copy my "view" into another project, so to be able to contol some sub-features, or I can easily replace one implementation with another. But that of coarse needs more changes than only the separation of the main form ...

Not sure if that will help you, but meanwhile I changed all my main forms into bare containers with one carrier layout, with no logic inside. The real views I load as TFrame or TForm into that container then. This way its much easier for me to manage several versions of .dproj, especially with different platforms and all their special requirements in the projects. That means creating a new, clean and empty project file now is simple now, and I just need to add one uses entry to point to the real main form in use.

Didn't you choose to install Java JDK during RadStudio WebInstaller ?